[9fans] Evolving rio / GUI development

[9fans] Evolving rio / GUI development

[g01495]

9fans,

I have some questions and some points -- I am interested in the
general consensus regarding interfaces to computers in general and how
Plan 9 fits into this.

There currently exists a large contrast in the way interfaces are
presented on different operating systems.  "modern" operating systems
such as GNU/Linux, Windows, MacOS provide an interface largely
disconnected from the underlying operating system.  They also put a
great deal of effort into cosmetic changes, and are beginning to use
hardware acceleration of the GUI using OpenGL framebuffer cards.
Ideas like three dimensional interfaces are counterproductive as the
paradigm can't be applied to the current technology.

rio on the other hand provides a minimal interface to the applications
on the system.  I believe this is the right thing to do, but I believe
some things are missing.

The idea of an interface itself is very complicated and difficult to
develop.  The general idea hasn't really changed in decades.

I find rio very usable, but I also find I spend alot of my time "using
rio".  When I say this I mean moving windows, organizing the screen,
hiding windows, resizing things.

Where will rio (or it's successors) end up going?

What does everybody else think about this?

Re: [9fans] Evolving rio / GUI development

[Russ Cox]

> I find rio very usable, but I also find I spend alot of my time "using
> rio".  When I say this I mean moving windows, organizing the screen,
> hiding windows, resizing things.

This is interesting.  Why don't you find yourself spending a lot
of time using the other window managers?

I wonder if it is similar to the reason people find themselves
spending a lot of time using the mouse but not the keyboard:
the mouse is easier to use so your brain is free to do other
things like wonder when you'll be done.

(Argument about mice vs. keyboards can go to /dev/null.
We've already been through that multiple times.  Here's one:
http://lists.cse.psu.edu/archives/9fans/2002-April/016946.html)

Russ

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Fans,

g01495> I find rio very usable, but I also find I spend alot of my time "using
g01495> rio".  When I say this I mean moving windows, organizing the screen,
g01495> hiding windows, resizing things.
I use riostart to setup my workspace (other word in English to say this?)
1. acme -l $home/acme.dump
2. stats -lm
3. clock
4. taskbar
And I can use this four(!) window for full work. If I need shell
window I just right click on my taskbar, work on it and then kill
it... As I see people who develop winwatch and rio never manage many
window too.

g01495> They also put a great deal of effort into cosmetic changes, and are beginning to use
g01495> hardware acceleration of the GUI using OpenGL framebuffer cards.
How much people work on Plan 9? Who can do this (and who have time for
this)?

g01495> The idea of an interface itself is very complicated and difficult to
g01495> develop.  The general idea hasn't really changed in decades.
What you can suggest? Use 3D desktop? In 2D display?

RC> This is interesting.  Why don't you find yourself spending a lot
RC> of time using the other window managers?
Because other more advanced (more friendly to user).

RC> I wonder if it is similar to the reason people find themselves
RC> spending a lot of time using the mouse but not the keyboard:
RC> the mouse is easier to use so your brain is free to do other
RC> things like wonder when you'll be done.
With 99% accuracy may say: people who read this, usually use keyboard ;-)

RC> (Argument about mice vs. keyboards can go to /dev/null.
RC> We've already been through that multiple times.  Here's one:
RC> http://lists.cse.psu.edu/archives/9fans/2002-April/016946.html)
I found keyboard very useful, but when I can (like in OS Windows ) all
task do with keyboard or mouse it's great, but when some task I do by
keyboard and some only by mouse it's very hard (example: hiding
window)... At least we need something like Atl-TAB to change active
window by keyboard...

SS> I beleive a lot depends upon what resolution you run the display at,
SS> I run at 1080x1024 which is just enough. 1024x768 on my laptop is painfull
SS> Ideally I would run at 1600 odd but my monitor just isn't sharp enough.
What need to do people who have only 800x600?

AM> i rarely manage rio either. i do much more 'managing' of windows
AM> inside acme, where there are some strides made with automatic cursor
AM> placement and windows resize. i suggest you look there for
AM> inspiration.
Interesting idea! If acme can handle Image it can be used for more
things... why it don't do it?

Other thing which I wont add to this post:
We need port of libtk or equivalent for Plan 9 (previously to say "we
have libcontrol" firstly try use it).
When we have complete GUI we can faster develop application!
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[McLone]

On Wed, 16 Feb 2005 21:15:57 +0200, Sergey Reva <rs_rlab@mail.ru> wrote:
> How much people work on Plan 9? Who can do this (and who have time for
just look on Freedesktop's cairo -> glitz -> (debrix|xserver) -> DRI
and u'll understand.
Sure they [still] have monolithic tree, XAA drivers and such.... but
i'm telling it's not easy to do now, at least from HW support PoV.

> RC> This is interesting.  Why don't you find yourself spending a lot
> RC> of time using the other window managers?
> Because other more advanced (more friendly to user).
complicated configs != user-friendly
simple/mainstream ones ~= unuseable IMO

> SS> Ideally I would run at 1600 odd but my monitor just isn't sharp enough.
> What need to do people who have only 800x600?
w00t? 800x600 nowadays?
* You must be kiddin'. Even used cards/CRTs can do 1024x768x75+hz!
* Turn it on, work couple'o'hours, then report. [different OSes]

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

>> Because other more advanced (more friendly to user).
M> complicated configs != user-friendly
Most of modern GUI have gui configurator

>> SS> Ideally I would run at 1600 odd but my monitor just isn't sharp enough.
>> What need to do people who have only 800x600?
M> w00t? 800x600 nowadays?
M> * You must be kiddin'. Even used cards/CRTs can do 1024x768x75+hz!
M> * Turn it on, work couple'o'hours, then report. [different OSes]
Now I work at 1024x768@85Hz (CRT 17"), and my hardware can do more.
I got this hardware only in 2004... It's still many users who can work only at
800x600 in 14"-15". But may be you right - we need look to future...

KO> Young and talented programmer can try this, however, it must be painful
KO> and brain consuming thing I think.
Many programmers can do this, but after his work we get many
incompatible GUI's, as result we got manu programs, may be good but
uses different gui library...
I see this in Linux. I have three variant of any program (mean gui
program): one for KDE, one for Gnome and one which not use this library... (maybe i mistake somewhere?)
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> I see this in Linux. I have three variant of any program (mean gui
> program): one for KDE, one for Gnome and one which not use this library... (maybe i mistake somewhere?)

To me these things look like same, but just variants.

Kenji

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

So what we do now?
How it need look this new gui?
As library or as server?
Skined or most simple and fast?
Control library + window maker or all in one?
Or just improve libcontrol and stop on this...

--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> So what we do now?
> How it need look this new gui?
> As library or as server?
> Skined or most simple and fast?
> Control library + window maker or all in one?
> Or just improve libcontrol and stop on this...
>

how about no new gui
the old one ain't smellin' yet

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

On Thu, 17 Feb 2005, Tiit Lankots wrote:

> how about no new gui
> the old one ain't smellin' yet

well, you folks all seem to be able to fit all your windows tiled. I just
plain can't. I've to two 21" LCDs and with the CAD systems etc. I use
there's no room at all to tile everything. It just doesn't work, hence my
need for multiple desktops and other such things.

With multiple desktops, as much as I like rio, I find it easier to use
flwm and swap around with CTRL-F[1234] etc.

So, yes, rio is a fine and wonderful thing, but I don't buy it as the
be-all and end-all of window managers.

YMMV is always the case.

ron

Re: [9fans] Evolving rio / GUI development

[boyd, rounin]

> YMMV is always the case.

hide & /dev/label

;)
--
MGRS 31U DQ 52572 12604

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> YMMV is always the case.

My (somewhat sarcastic) comment was more referring to the probability
that no excellent new idea will likely be unraveled here, so
nothing will be (re-)implemented, either. Plan 9 has a strong intrinsic
opposition to change; this is mostly good beacuse of obvious
reasons. But some experimentation would'nt hurt. I just can't see the
mechanism of this happening, short of reimplementing the whole shebang.

Re: [9fans] Evolving rio / GUI development

[Russ Cox]

> My (somewhat sarcastic) comment was more referring to the probability
> that no excellent new idea will likely be unraveled here, so
> nothing will be (re-)implemented, either. Plan 9 has a strong intrinsic
> opposition to change; this is mostly good beacuse of obvious
> reasons. But some experimentation would'nt hurt. I just can't see the
> mechanism of this happening, short of reimplementing the whole shebang.

The mechanism is, and always is, someone writes code.
Of course, that's not nearly so easy as whining on 9fans.

Russ

[9fans] writing code

[rog]

> The mechanism is, and always is, someone writes code.

maybe this is unrealistic, but i'd like to see more "encouragement on
principle".  that is, if someone suggests something, it'd be nice if
people (particular labs or ex-labs people) would chip in and say "yes,
it's a good idea in principle; i'd like to see something like that"
(or perhaps "yes, but it should be done in this way", or "bad idea,
philosophically misguided").

if there were various projects around that had been given the
thumbs-up on principle (pending actual implementation), perhaps more
people might be inclined to get their hands dirty and write some code
towards those ends.

instead, i feel that people face the prospect of spending weeks
writing code, only to be told at the end that the whole aim of their
effort was misguided; or, worse, that the work was indeed misguided, but
it gets included anyway on the grounds of inclusiveness, diluting the
excellence of the whole system.

of course, it's perfectly possible to take the view that plan 9 is
perfect; that beyond minor bug fixes, new hardware ports and device
drivers and more applications, plan 9 is as good as it could be.

if that's the consensus view, then fine, i can live with that.

but personally, i think that there *are* places where plan 9 doesn't
perhaps do as well as it could, and fixing some of those might require
the rethinking of some core parts of the system.

maybe the first thing to do is to try and get some consensus as to
where the weaknesses of the system are.  the kind of things that might
be put in the BUGS section of intro(1), if there was one.

to start with, perhaps we could suggest areas in plan 9 which we think could use
some work, in the broadest terms possible, avoiding specific solutions;
then we could try to work towards specific projects aimed at addressing
those areas. people could give their views on each issue, e.g.

	a) this isn't a problem, it's meant to be this way.
	b) yes this is a problem; i've no idea what to do about it though.
	c) yes, this is a problem, but i don't think there's a decent solution possible.
	d) yes, this is a problem, and here's a possible solution.
	e) yes, this is a problem, but the right solution is too hard.
	f) you're coming at this from the wrong angle.
	g) you're making a mountain out of a molehill.
	h) i don't care in the slightest about this issue.
	i) i don't know what the hell you're on about.

here are a few for starters:

	isochronous/streaming data transfer over 9p:

		9p is slow over wide area networks when streaming
		data, due to the ping-pong nature of the data
		transfer.  can anything be done to help solve this?

	distributed authentication:

		the plan 9 authentication model relies on having an
		on-line authentication server.  as firewalls and
		mobile devices continue to proliferate, might it be
		worthwhile adding support for a peer-to-peer model be
		more appropriate?

	graphics:

		high-bandwidth bitmap access is slow.  additionally,
		even the existing hardware acceleration could be
		leveraged more than it is (if any portion of a window
		is obscured, then no h/w acceleration is used for that
		window).  is it conceivable to have a system where all
		graphics operations are accelerated (as apple are
		apparently to be doing with their next system), or
		does the current architecture preclude this?

	graphics primitives:

		graphics drawn with the existing non-bitblt primitives
		is not great (e.g.  lots of jaggies on diagonal
		lines).  could implementing subpixel rendering help
		matters here?

	how can i continue to do work when a server goes down?

		aan can deal with a broken network connection, but say
		someone reboots the fileserver?  is there any way we
		can incorporate some redundancy into the system, or
		make it easier for a applications to recover?

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005 rog@vitanuova.com wrote:

> here are a few for starters:


hmm,.


how about:

a plan 9 laptop is about as secure as dos 1.0


I mean, turn it on, pick a random user name which is likely to work, and
you're in with no password or anything. Am I the only one who thinks this
is not so terrific?

Or am I missing something.

ron

Re: [9fans] writing code

[Russ Cox]

> a plan 9 laptop is about as secure as dos 1.0
>
> I mean, turn it on, pick a random user name which is likely to work, and
> you're in with no password or anything. Am I the only one who thinks this
> is not so terrific?

[answer 1]
i think it's realistic.  a boot cd would get you the same access.
if you get physical machine access, you win.  typing a password
to authenticate to the local system gives you the feeling of
security, not actual security.

[answer 2]
you could just run the screen locker that rob wrote in termrc.

[answer 3]
plan 9 is intended to be used as a networked system.  laptops
are second-class citizens.

russ

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005, Russ Cox wrote:

> [answer 3]
> plan 9 is intended to be used as a networked system.  laptops
> are second-class citizens.
>

hmm, this just sounds like another argument against using plan 9.

ron

Re: [9fans] writing code

[lucio]

>> [answer 3]
>> plan 9 is intended to be used as a networked system.  laptops
>> are second-class citizens.
>>
>
> hmm, this just sounds like another argument against using plan 9.

Not really.  Laptops are a poor solution to the problem of information
ownership and, on the reverse side, information sharing.  So is the
disked workstation; for that matter, the entire "personal computer"
idea.  Plan 9 does not propose to solve the problem, but addresses it
much better than all other conventional approaches.

You've forgotten the sanity in the early Plan 9 papers and have (no
offence intended) been swept along by the commoditisation of computing
resources.  Consider the COO of laptops, specially when lost or
stolen, then replace the laptop with an authentication device that
gives you access to any computing terminal anywhere, where Plan 9
provides the computing and file services your access device
authenticates you to.  Even Microsoft Passport aspired to such a
model, but they could not pull off what Plan 9 does by default.

++L

PS: the above may be a little murky, but I need to beat a dealine and
Ron's remark deserve a more positive reply.  I'm sure Ron will catch
my meaning.

Re: [9fans] writing code

[rog]

lucio:
> Not really.  Laptops are a poor solution to the problem of information
> ownership and, on the reverse side, information sharing.  So is the
> disked workstation; for that matter, the entire "personal computer"
> idea.  Plan 9 does not propose to solve the problem, but addresses it
> much better than all other conventional approaches.

i'm not sure i agree.  if you can always contact your authentication
and file servers, the current plan 9 model works fine, but i think the
idea of universal global interconnect isn't realistic.  firewalls are
ubiquitous.  network coverage is patchy (and probably always will be).

i think it makes sense to carry your personal information near your
person, even if you only carry a key that enables you to access your
personal data on other systems.

paul:
> Useful would be an encrypted file system on my laptop with a USB-dongle
> auth server providing the key; something like a gumstix
> (www.gumstix.org) could run an auth server pretty easily.

this would be a way forward.  if your fs is encrypted, it doesn't
matter who has hardware access to your machine, as long as only you
have the key.  the important thing is to make the boot process itself
secure, so that nobody else can step in and subvert your key entry.

russ:
> i don't know what peer-to-peer means, but if we moved to
> a public key model (which was the reason presotto created p9any)
> and had the auth server just be a repository for public keys
> (signed by bootes), then any amount of caching could happen.

i'd like to see an authentication model along SDSI/SPKI lines, where
entities can authenticate directly with one another without
necessarily needing to talk to a third party auth server.  the inferno
model does this currently, but you can only authenticate with parties
in the same domain.  charles has done some work in this area for
Inferno.  it's highly applicable to plan 9 too.

this way, me and my laptop are at the centre of my world.  i can talk
to anyone, and name chaining and SPKI tag rules mean that i can make
useful deductions about what i should do on their behalf, even if
their public key isn't known to me.

i'd like to see the distinction between cpu server and terminal
disappear.

Re: [9fans] writing code

[Paul Lalonde]

On 18-Feb-05, at 10:22 AM, rog@vitanuova.com wrote:
> this would be a way forward.  if your fs is encrypted, it doesn't
> matter who has hardware access to your machine, as long as only you
> have the key.  the important thing is to make the boot process itself
> secure, so that nobody else can step in and subvert your key entry.
>
This is why I'd like to see the key served from a smart dongle - A more
secure handshake model can be used, and the dongle typically lives
separated from the data.  In my case I already carry a USB-flash device
with my keys (physical ones), and I'm much less likely to lose my
laptop and my keys.  If only I could lock my laptop data with the USB
provided key.  Now that cheap programmable dongles exist, this should
be easy - the hardest part for Plan9 looks to be the USB stack...

Paul

Re: [9fans] writing code

[rog]

> This is why I'd like to see the key served from a smart dongle - A more
> secure handshake model can be used, and the dongle typically lives
> separated from the data.

i agree a smart dongle is a good idea, but mainly because
it can subvert dictionary attacks if someone gets direct
access to the disk.

if someone jumps in before you in the boot process,
they can still ask your dongle for the relevant information
to enable them to decrypt the data, so a secure boot is
still necessary.

Re: [9fans] Second class citizenship (Was: writing code)

[Lucio De Re]

rog@vitanuova.com wrote:

>i'm not sure i agree.  if you can always contact your authentication
>and file servers, the current plan 9 model works fine, but i think the
>idea of universal global interconnect isn't realistic.  firewalls are
>ubiquitous.  network coverage is patchy (and probably always will be).
>
>
>
As I see it, network coverage has no alternative but to improve.  In my
opinion, there is growing pressure for mobile telephony networks to
become more and more reliable and pervasiveness is already great and can
only be extended.  I speak from Africa, where cell phones have (I could
be wrong, but I think it's true) overtaken landlines.

I agree that firewalls and other obstacles exist, but they serve a need
that Plan 9 already addresses in a much more sensible fashion.  In other
words, laptops are misused and the alternatives exist (I presume Plan 9
is one, Inferno another, there may be more) and will eventually be
discovered.  Call me an optimist, but all it takes is for some
influential personality to discover a better way to do things and the
entire fashion swings.

For example, Mark Shuttleworth used to carry extremely valuable
information in his laptop (I'm not sure I should reveal exactly what).
Were he to discover a more secure way of doing the same today, he is
sufficiently influential in South Africa to set at least a local trend.
Here, between GPRS and G3, 'Net access over mobile phones is pretty
good, at a premium.  Certainly within the financial reach of a Mark
Shuttleworth.

++L

Re: [9fans] Second class citizenship (Was: writing code)

[boyd, rounin]

> As I see it, network coverage has no alternative but to improve.

GSM can improve to the point of being unusable.  the mobile is
constantly looking for the 30 strongest BTS's [cells] (some of
this BTS/MTS stuff is cached in the SIM) and i've seen a case
where it could see so many BTS's that it just didn't work.  i
was on a hill that overlooked a town.  up on the hill [home]
my mobile didn't work, but in town it did.

this is all emperical data and a theory, but i had a coupla
months to puzzle over it.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Second class citizenship (Was: writing code)

[Lucio De Re]

boyd, rounin wrote:

>> As I see it, network coverage has no alternative but to improve.
>
>
> GSM can improve to the point of being unusable.  the mobile is
> constantly looking for the 30 strongest BTS's [cells] (some of
> this BTS/MTS stuff is cached in the SIM) and i've seen a case
> where it could see so many BTS's that it just didn't work.  i
> was on a hill that overlooked a town.  up on the hill [home]
> my mobile didn't work, but in town it did.
>
Granted.  But I can't believe that that the network operators would
intentionally cripple their network.  Despite rog's reservations, I
believe connectivity will improve.  It is harder to have faith in it
being the desired brand of connectivity, but VOIP shows that ingenuity
overcomes the most severe restrictions.

++L

Re: [9fans] Second class citizenship (Was: writing code)

[boyd, rounin]

> Granted.  But I can't believe that that the network operators would
> intentionally cripple their network.

my theory is that few people think or provide for end cases,
whether it's one function or a system.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Second class citizenship (Was: writing code)

[Joel Salomon]

On Sun, 20 Feb 2005 19:37:09 +0100, boyd, rounin <boyd@insultant.net> wrote:
> my theory is that few people think or provide for end cases,
> whether it's one function or a system.
> 

This sounded so crazy, I asked the professor who's teaching wireless
communications here at Cooper. His reply:
> > Professor:
> > Just got this on the 9fans list, and I had to ask—is the scenario Boyd
> > describes at all possible/probable?
> > 
> > --Joel
> > ---------- Forwarded message ----------
> > From: boyd, rounin <boyd@insultant.net> etc.
> > 
> it's very possible; these protocols are very touchy and you could very well
> end up in ridiculous situations as they describe; i don't know enough about
> the particulars of GSM per se to know if this PARTICULAR problem sounds
> plausible or likely with many carriers but this is certainly typical of the
> strange things that can happen
> 
> ff
> 

Well, now there's at least *one* future EE that *will* watch out for
this nonsense...

--Joel

Re: [9fans] Second class citizenship (Was: writing code)

[lucio]

> my theory is that few people think or provide for end cases,
> whether it's one function or a system.

Sounds like a good principle.  Don't rely on end cases, you may not be
catered for.  But usually there is enough space further from the
edges, if you're savvy.  Vint Cerf et al certainly figured that one
out OK. Although it may need repeating in the not too distant future.

There Plan 9 has the edge with a nice, simple protocol.  But maybe we
ought to look at the edge cases here too, make sure they are accounted
for.

++L

Re: [9fans] Second class citizenship (Was: writing code)

[Bruce Ellis]

Gotta check those off-by-zero errors.  Check the fortune file.

brucee

On Mon, 21 Feb 2005 06:30:13 +0200, lucio@proxima.alt.za
<lucio@proxima.alt.za> wrote:
> > my theory is that few people think or provide for end cases,
> > whether it's one function or a system.
>
> Sounds like a good principle.  Don't rely on end cases, you may not be
> catered for.  But usually there is enough space further from the
> edges, if you're savvy.  Vint Cerf et al certainly figured that one
> out OK. Although it may need repeating in the not too distant future.
>
> There Plan 9 has the edge with a nice, simple protocol.  But maybe we
> ought to look at the edge cases here too, make sure they are accounted
> for.
>
> ++L
>
>

Re: [9fans] Second class citizenship (Was: writing code)

[rog]

> Call me an optimist, but all it takes is for some influential
> personality to discover a better way to do things and the entire
> fashion swings.

you're an optimist!  (a new technology has to be compatible with the
old at some level otherwise it can't gain its initial toehold).

i'm not convinced that plan 9 does away with the need for firewalls.
and certainly many companies are not going to be getting rid of their
firewalls in a hurry.

when i'm visiting such a company and want to rendezvous with someone
else via the local network, i should be able to do so securely
without needing a connection to the outside world.

Re: [9fans] Second class citizenship (Was: writing code)

[Ronald G. Minnich]

On Sun, 20 Feb 2005, Lucio De Re wrote:

> I agree that firewalls and other obstacles exist, but they serve a need
> that Plan 9 already addresses in a much more sensible fashion.  In other
> words, laptops are misused and the alternatives exist (I presume Plan 9
> is one, Inferno another, there may be more) and will eventually be
> discovered.  Call me an optimist, but all it takes is for some
> influential personality to discover a better way to do things and the
> entire fashion swings.

you're missing the cases where for non-technical reasons you need to use a
laptop but it CAN NOT be connected to any network for, say, the time you
are in a certain building or at a certain site.

ron

Re: [9fans] Second class citizenship (Was: writing code)

[lucio]

> you're missing the cases where for non-technical reasons you need to use a
> laptop but it CAN NOT be connected to any network for, say, the time you
> are in a certain building or at a certain site.

But my point was that this is an artefact of current trends, not a
necessary condition.  It's not as if laptops have always been part of
the computing landscape.  If it's data you want, a USB drive is
usually adequate, if it's computing cycles, you ought to be platform
agnostic the way Plan 9 is.

And, yes, I accept that the above is simplistic, but I submit it's not
unrealistic.

++L

Re: [9fans] Second class citizenship (Was: writing code)

[Ronald G. Minnich]

On Tue, 22 Feb 2005 lucio@proxima.alt.za wrote:

> But my point was that this is an artefact of current trends, not a
> necessary condition.

no. It's a requirement for many secure environments, for one thing. That's
why it is not a technical issue.

ron

Re: [9fans] writing code

[Kenji Okamoto]

> i'd like to see the distinction between cpu server and terminal
> disappear.

Then, what is the difference between your new scheme and the
present day unix scheme?

I don't really understand your motivation to make it real...
You mean all of direct democracy?

Kenji

Re: [9fans] writing code

[Tiit Lankots]

>> i'd like to see the distinction between cpu server and terminal
>> disappear.
>
> Then, what is the difference between your new scheme and the
> present day unix scheme?
>
> I don't really understand your motivation to make it real...
> You mean all of direct democracy?

Complete hegemony, for one. When every terminal is a (potential)
cpu server - depending on its owner's whim - there will be a
plethora of resources, just waiting to be used. It's somewhat like
what P2P is to FTP.

Re: [9fans] writing code

[Kenji Okamoto]

> Complete hegemony, for one. When every terminal is a (potential)
> cpu server - depending on its owner's whim - there will be a
> plethora of resources, just waiting to be used. It's somewhat like
> what P2P is to FTP.

So, the unix caused chaos to maintain its system, that's the one of
the most main motivation to produce Plan 9 system, I think.

Kenji

Re: [9fans] writing code

[Tiit Lankots]

> So, the unix caused chaos to maintain its system, that's the one of
> the most main motivation to produce Plan 9 system, I think.

It will be a completely different thing, locally- (vs centrally) organised  
system.

Re: [9fans] writing code

[rog]

> So, the unix caused chaos to maintain its system, that's the one of
> the most main motivation to produce Plan 9 system, I think.

a centrally administered authentication system should be possible, but
i don't think it should be mandatory.

is it perhaps the case that unix is chaos mainly because there's no
coherent idea of identity?  what does a numeric user id mean?  what,
for that matter, does a user name mean?  maybe this is where the ideas
in SDSI/SPKI can help (see http://www.faqs.org/rfcs/rfc2693.html).

Re: [9fans] writing code

[Kenji Okamoto]

> coherent idea of identity?  what does a numeric user id mean?  what,
> for that matter, does a user name mean?  maybe this is where the ideas
> in SDSI/SPKI can help (see http://www.faqs.org/rfcs/rfc2693.html).

Sorry of mt delay to respond this, rog.
I have not enough time to read that RFC.

Now, I got what you were saying, however, I suppose it beyonds the
original scope of Plan 9 which was designed for.   She is (has been) for
a somewhat closed affiliations such as a laboratory or a, say, departmetnt.
However, you are aiming to expand it to wider system in the sense of
location or network topology.   In this case, I agree the original design
of Plan 9 may not fit to its need, as if Unix was so to Plan 9.

Then, my view of your proposal is that you'd better to design another
system than Plan 9, or you have to change it for that purpose, however,
is it really possible without causing complexity as such we've seen in the
developement of unices?   I have no idea for it.

Kenji

Re: [9fans] writing code

[Richard Miller]

> When every terminal is a (potential)
> cpu server

Here's the rc script I use when I want my (laptop) terminal to act
as a cpu (and drawterm) server.  Of course it could be generalised
to add more services.

#!/bin/rc
rfork ne
auth/keyfs -p $home/lib/keys
aux/listen1 -t tcp!*!ticket /bin/auth/authsrv &
service=cpu aux/listen1 tcp!*!cpu /bin/cpu -O &
service=cpu aux/listen1 tcp!*!ncpu /bin/cpu -R &

Re: [9fans] writing code

[Steve Simon]

> Complete hegemony, for one. When every terminal is a (potential)
> cpu server - depending on its owner's whim - there will be a
> plethora of resources, just waiting to be used. It's somewhat like
> what P2P is to FTP.

I like this model, but I think we would need to be able to specify
a namespace based on authdom, and a cpu % - Fair Share Scheduler anyone?

Then here is the problem of resource discovery...

-Steve

Re: [9fans] writing code

[Ronald G. Minnich]

On Fri, 18 Feb 2005 lucio@proxima.alt.za wrote:

> PS: the above may be a little murky, but I need to beat a dealine and
> Ron's remark deserve a more positive reply.  I'm sure Ron will catch my
> meaning.

I catch your meaning, and I agree that I'm probably wrong.

But I still worry about the disconnected laptop case, because I take my
laptop to many places where network access is just not possible, and then
bring it out again. So my network access in the laptop case is available
maybe 20% of my working day and will always remain so.

Ah well, too little time to write this in a comprehensible way, I take
your meaning and Russ's meaning and the meaning of the other good notes
that got sent to me w.r.t. this issue.

ron

Re: [9fans] writing code

[Paul Lalonde]

Not to mention that laptops are an important class of networked
devices.  I rarely wind up with my laptop more than a few hours away
from its next connection, and spend most of my days with my laptop
wirelessly connected.
My laptop isn't second class - it has become my principal machine.
Useful would be an encrypted file system on my laptop with a USB-dongle
auth server providing the key; something like a gumstix
(www.gumstix.org) could run an auth server pretty easily.

Paul

On 17-Feb-05, at 8:48 PM, Ronald G. Minnich wrote:

>
>
> On Thu, 17 Feb 2005, Russ Cox wrote:
>
>> [answer 3]
>> plan 9 is intended to be used as a networked system.  laptops
>> are second-class citizens.
>>
>
> hmm, this just sounds like another argument against using plan 9.
>
> ron
>

Re: [9fans] writing code

[andrey mirtchovski]

i believe russ meant that on Plan 9 networks laptops are just
keyboard/mouse/display interfaces and should never serve as standalone
systems.  they're meant to connect to a physically secure fs/auth
servers, not serve those files themselves.

clients, not servers.  hence the second-rate citizenship.  i move my
laptop from home to school every day.  it serves as a terminal to
plan9.ucalgary.ca and the only plan9-related things it has are a
couple of partitions -- 9fat and cfs (cache).  none of my files are
stored on it (except whatever is in cfs).  it's as secure as anything
else.

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005, andrey mirtchovski wrote:

> clients, not servers.  hence the second-rate citizenship.  i move my
> laptop from home to school every day.  it serves as a terminal to
> plan9.ucalgary.ca and the only plan9-related things it has are a couple
> of partitions -- 9fat and cfs (cache).  none of my files are stored on
> it (except whatever is in cfs).  it's as secure as anything else.


it's a fine model, it's just not a universal model. I'm not convinced. But
I'm wrong lots of times, so I'll leave it at that.

ron

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005, Russ Cox wrote:

> [answer 1]
> i think it's realistic.  a boot cd would get you the same access.
> if you get physical machine access, you win.  typing a password
> to authenticate to the local system gives you the feeling of
> security, not actual security.

yes, if I get physical acccess, I win. I'll just tear the thing to bits
and boot it with an ICE :-) I don't even care if I mark up the pretty
plastic.

And if you get access, you'll probably hit the jackpot much more than I
will, and you probably won't even need to use a screwdriver.  But if most
schmoozes get physical access, they don't win. Most criminals being stupid
schmoozes, I'm ok with protecting against them and not against the KGB.

Everybody who has a null root password, based on the physical access
argument, raise their hand.

I don't buy this argument.

> [answer 2]
> you could just run the screen locker that rob wrote in termrc.

makes sense to me. So why don't we do it?

ron

Re: [9fans] writing code

[Tim Newsham]

>> I mean, turn it on, pick a random user name which is likely to work, and
>> you're in with no password or anything. Am I the only one who thinks this
>> is not so terrific?
>
> [answer 1]
> i think it's realistic.  a boot cd would get you the same access.
> if you get physical machine access, you win.  typing a password
> to authenticate to the local system gives you the feeling of
> security, not actual security.

To prevent this you either need to prevent someone from booting
(ie. bios password and hope they dont go through the trouble
of yanking the drive or resetting the bios) or you need to
protect the disk (after all thats probably what they want to
get at after they log in, not network access or the gui).
Something like:

    http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

would address this nicely.  For those who don't want to chase
down the paper, it's an encrypted disk format used by the
FreeBSD group.

Tim N.

Re: [9fans] writing code

[David Leimbach]

> To prevent this you either need to prevent someone from booting
> (ie. bios password and hope they dont go through the trouble
> of yanking the drive or resetting the bios) or you need to
> protect the disk (after all thats probably what they want to
> get at after they log in, not network access or the gui).
> Something like:
>
>     http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
>
> would address this nicely.  For those who don't want to chase
> down the paper, it's an encrypted disk format used by the
> FreeBSD group.
>

Isn't it actually a block-level encryption rather than a filesystem
implementation?

Dave
> Tim N.
>

Re: [9fans] writing code

[Christopher Nielsen]

On Fri, Feb 18, 2005 at 11:49:43AM -0800, David Leimbach wrote:
> > To prevent this you either need to prevent someone from booting
> > (ie. bios password and hope they dont go through the trouble
> > of yanking the drive or resetting the bios) or you need to
> > protect the disk (after all thats probably what they want to
> > get at after they log in, not network access or the gui).
> > Something like:
> >
> >     http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
> >
> > would address this nicely.  For those who don't want to chase
> > down the paper, it's an encrypted disk format used by the
> > FreeBSD group.
> >
>
> Isn't it actually a block-level encryption rather than a filesystem
> implementation?

yes. that's exactly what it is. how is that not useful in this
case?

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] writing code

[rog]

> http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

looks like a project!

Re: [9fans] writing code

[Christopher Nielsen]

On Fri, Feb 18, 2005 at 09:36:18PM +0000, rog@vitanuova.com wrote:
> > http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
>
> looks like a project!

yes, it is, and as i said in a previous message, it is a
project i am working on. if others wish to pitch in, i am
more than happy to accept help, and phk has offered
code review assistance, as well; phk would really like
to see gbde implemented on other platforms.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] writing code

[David Leimbach]

On Fri, 18 Feb 2005 11:59:50 -0800, Christopher Nielsen
<cnielsen@pobox.com> wrote:
> On Fri, Feb 18, 2005 at 11:49:43AM -0800, David Leimbach wrote:
> > > To prevent this you either need to prevent someone from booting
> > > (ie. bios password and hope they dont go through the trouble
> > > of yanking the drive or resetting the bios) or you need to
> > > protect the disk (after all thats probably what they want to
> > > get at after they log in, not network access or the gui).
> > > Something like:
> > >
> > >     http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
> > >
> > > would address this nicely.  For those who don't want to chase
> > > down the paper, it's an encrypted disk format used by the
> > > FreeBSD group.
> > >
> >
> > Isn't it actually a block-level encryption rather than a filesystem
> > implementation?
>
> yes. that's exactly what it is. how is that not useful in this
> case?
>
>

Why would you assume that I'd think it's not useful?

Re: [9fans] writing code

[Bruce Ellis]

oz-inferno has an encrypted filesystem (based on flashfs).
the configuration and other local private stuff is intended
to live on a usb-flash thingy (along with the executable
and boot crap).  i hope to release some of this stuff when
i get some time off doing real work.

brucee

On Sat, 19 Feb 2005 01:15:59 -0800, David Leimbach <leimy2k@gmail.com> wrote:
> On Fri, 18 Feb 2005 11:59:50 -0800, Christopher Nielsen
> <cnielsen@pobox.com> wrote:
> > On Fri, Feb 18, 2005 at 11:49:43AM -0800, David Leimbach wrote:
> > > > To prevent this you either need to prevent someone from booting
> > > > (ie. bios password and hope they dont go through the trouble
> > > > of yanking the drive or resetting the bios) or you need to
> > > > protect the disk (after all thats probably what they want to
> > > > get at after they log in, not network access or the gui).
> > > > Something like:
> > > >
> > > >     http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
> > > >
> > > > would address this nicely.  For those who don't want to chase
> > > > down the paper, it's an encrypted disk format used by the
> > > > FreeBSD group.
> > > >
> > >
> > > Isn't it actually a block-level encryption rather than a filesystem
> > > implementation?
> >
> > yes. that's exactly what it is. how is that not useful in this
> > case?
> >
> >
>
> Why would you assume that I'd think it's not useful?
>

Re: [9fans] writing code

[Ralph Corderoy]

Tim Newsham wrote:
> > i think it's realistic.  a boot cd would get you the same access.
> > if you get physical machine access, you win.  typing a password to
> > authenticate to the local system gives you the feeling of security,
> > not actual security.
> 
> To prevent this you either need to prevent someone from booting (ie.
> bios password and hope they dont go through the trouble of yanking the
> drive or resetting the bios) or you need to protect the disk (after
> all thats probably what they want to get at after they log in, not
> network access or the gui).

The ATA spec. has passwords that are stored in the hard drive unit.  The
password must be given before the drive will respond with anything
useful.  It isn't a BIOS password so moving the drive doesn't help.
Forgetting the password is a pain;  there's a `master' one known to the
manufacturer but that just lets you re-format the drive if you can
persuade them, e.g. Dell, to give it to you.

Cheers,


Ralph.

Re: [9fans] writing code

[Charles Forsyth]

>>could implementing subpixel rendering help matters here?

that one's easy: no.
something else might, though.

Re: [9fans] writing code

[rog]

> >>could implementing subpixel rendering help matters here?
>
> that one's easy: no.
> something else might, though.

maybe i got the terminology wrong.

i wasn't referring to that LCD hack, if that's what you're thinking of,
but of being able to specify finer resolutions for (say) the
endpoints of lines than single pixels, and perhaps
have the primitives use alpha blending (i.e. non boolean mask)
to achieve a decent result.

some already allow the former, internally (e.g. _memfillpolysc).

Re: [9fans] writing code

[Christopher Nielsen]

On Thu, Feb 17, 2005 at 10:21:19PM +0000, rog@vitanuova.com wrote:
>
> of course, it's perfectly possible to take the view that plan 9 is
> perfect; that beyond minor bug fixes, new hardware ports and device
> drivers and more applications, plan 9 is as good as it could be.
>
> if that's the consensus view, then fine, i can live with that.
>
> but personally, i think that there *are* places where plan 9 doesn't
> perhaps do as well as it could, and fixing some of those might require
> the rethinking of some core parts of the system.

we talked about some of this at the OSDI BoF. there are places
where plan 9 can be improved. i have a list of projects that
i ammend every time i come across something that i think would
be good to have or should be improved.

i talked to russ about his idea of turning the kernel into an
efficient 9p mux and making everything talk 9p. i think that
is an interesting idea. a link to his initial thoughts on it
is here:
http://groups-beta.google.com/group/comp.os.plan9/msg/3bcdde3580d62263

i've talked to presotto about implementing something like sfs.
http://www.fs.net/sfswww/

i've started working on an implementation of gbde as an extension
of devfs. don't hold your breath on when it will be done. really
busy with paying work these days.
http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

so there are plenty of good project ideas. i don't announce
mine because i don't want there to be any expectations that
i am going to produce them in a timely fashion. unfortunately,
plan 9 is a hobby for me. if i had a way to pay the bills and
improve plan 9, i'd certainly do it.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] writing code

[boyd, rounin]

i'd like to see a fix for:

     i8259.c:  print("i8259enable: irq %d shared but not level\n", irq);

i'd have a hack if i had the controller's doc and declaration from a psych that i wouldn't lose my sanity ...
--
MGRS 31U DQ 52572 12604

Re: [9fans] writing code

[jmk]

On Thu Feb 17 18:03:41 EST 2005, boyd@insultant.net wrote:
> i'd like to see a fix for:
>
>      i8259.c:  print("i8259enable: irq %d shared but not level\n", irq);
>
> i'd have a hack if i had the controller's doc and declaration from a psych that i wouldn't lose my sanity ...
> --
> MGRS 31U DQ 52572 12604
>

it's not the 8259 that's the problem, your bios isn't telling the
truth about the interrupt setup. i explained it to you.
i gave you the hack. you didn't reply as to whether it worked.

Re: [9fans] writing code

[boyd, rounin]

> it's not the 8259 that's the problem, your bios isn't telling the
> truth about the interrupt setup. i explained it to you.
> i gave you the hack. you didn't reply as to whether it worked.

ok, i stand corrected.

pretty sure i applied it and got no joy.  that mail got lost in a
head crash -- don't ask.
--
MGRS 31U DQ 52572 12604

Re: [9fans] writing code

[Ronald G. Minnich]

On Thu, 17 Feb 2005, Christopher Nielsen wrote:

> i talked to russ about his idea of turning the kernel into an
> efficient 9p mux and making everything talk 9p.

That, to me, is the really exciting idea.

ron

Re: [9fans] writing code

[rog]

> > i talked to russ about his idea of turning the kernel into an
> > efficient 9p mux and making everything talk 9p.
>
> That, to me, is the really exciting idea.

what does it get you?

Re: [9fans] writing code

[Christopher Nielsen]

On Thu, Feb 17, 2005 at 11:07:01PM +0000, rog@vitanuova.com wrote:
> > > i talked to russ about his idea of turning the kernel into an
> > > efficient 9p mux and making everything talk 9p.
> >
> > That, to me, is the really exciting idea.
>
> what does it get you?

did you read russ' original post?

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] writing code

[rog]

> did you read russ' original post?

yes.  i was left wondering "why?"  though.

it's seems a bit like choosing a different fixed point for a recursive
function (though i'm probably abusing terminology again here!).
the work's got to be done somehow, and changing how the multiplexing
is done doesn't really change the fact that the multiplexing has to be
done somehow - it's just an internal architecture issue.

i don't see what problem it was trying to address.

hence my question to you.

Re: [9fans] writing code

[Russ Cox]

it presents a clean 9p interface to user space.

On Thu, 17 Feb 2005 23:33:47 +0000, rog@vitanuova.com <rog@vitanuova.com> wrote:
> > did you read russ' original post?
>
> yes.  i was left wondering "why?"  though.
>
> it's seems a bit like choosing a different fixed point for a recursive
> function (though i'm probably abusing terminology again here!).
> the work's got to be done somehow, and changing how the multiplexing
> is done doesn't really change the fact that the multiplexing has to be
> done somehow - it's just an internal architecture issue.
>
> i don't see what problem it was trying to address.
>
> hence my question to you.
>
>

Re: [9fans] writing code

[Steve Simon]

I think the idea of a list of "accepted" problem areas
and thoughts on differnt strategys is a good idea, in
the same way as the tip O' the day list is a good idea.

My contribution is actually an indirest reference to the discussion
on the 9grid list about cross domain authentiction IE:

I want to allow YOU to be able use some of my cpu cycles and to be able to
see a limited namespace on THIS machine using THAT authentication server
to prove your credentials.

I am willing to write the code but its still a ways down the list.

If anyone wants another good reason for such a discussion,
9fans has been far too quiet of late ☺

-Steve

Re: [9fans] writing code

[Russ Cox]

> > The mechanism is, and always is, someone writes code.
>
> maybe this is unrealistic, but i'd like to see more "encouragement on
> principle".  that is, if someone suggests something, it'd be nice if
> people (particular labs or ex-labs people) would chip in and say "yes,
> it's a good idea in principle; i'd like to see something like that"
> (or perhaps "yes, but it should be done in this way", or "bad idea,
> philosophically misguided").

i'm all for encouragement on principle, but the thread i was replying
to had gotten beyond that point.  it started out with an interesting
question -- what to do beyond rio -- but devolved into religion about
why rio should be more like what's on unix/mac/windows without
pointing out a single problem that would solve.

i think there are plenty of interesting answers to the original question.
acme is one.  but "be more like other systems" is never an interesting
answer.

ultimately, it always comes down to code.  we can talk all we want
but at the end of the day the only real proof that something is a
good idea is to implement it, try it, and see.  andrey and i have
been talking about an implementation of alt-tab for the plan9port rio
that i think will feel quite rio-like (except for the whole typing thing),
but we won't know if it's actually reasonable until we write it.

> if there were various projects around that had been given the
> thumbs-up on principle (pending actual implementation), perhaps more
> people might be inclined to get their hands dirty and write some code
> towards those ends.

that would be great.  nothing in the rio thread resembled a project.

> instead, i feel that people face the prospect of spending weeks
> writing code, only to be told at the end that the whole aim of their
> effort was misguided; or, worse, that the work was indeed misguided, but
> it gets included anyway on the grounds of inclusiveness, diluting the
> excellence of the whole system.

i can see that, but it's hard to say ahead of time that something isn't
misguided.  i think what happens most of the time is someone writes
something to solve a problem that they have, and if it's generally
useful, it makes its way in.  a good example is aquarela.  but there
are problems that have been solved and not rolled in -- ron is working
on better clustering support, but i doubt that will be polished enough
to be mainstream for a while yet.  tim has got the ultrasparc almost
working.  all of these people wrote the code because it solved a problem
they had, so it was useful to do regardless of whether it gets picked up.

it's also hard to say something's not misguided until you try it.
(it's often easy to say it *is* misguided, but that's not the
encouragement you were looking for).  there's always a risk
that it might turn out not to be a good idea, or to need another
go around.  even the things that are successful often need
extra go-arounds:  even central pieces such as the file server, 9P, and
the graphics system have gone through at least three major revisions each.

i agree that it would be great to have a list of interesting problems
to solve, but i'm not sure we could actually figure out beforehand
which solutions are the best ones or even which are complete flops.
but you're right -- we can at least identify the problems.

russ

Re: [9fans] writing code

[C H Forsyth]

>>i agree that it would be great to have a list of interesting problems
>>to solve, but i'm not sure we could actually figure out beforehand
>>which solutions are the best ones or even which are complete flops.

i think that might be taken as a definition of an `interesting problem'
(or more accurately, an `interesting solution' to a perceived problem).
a friend of mine worked for a time for a famous computer scientist,
who produced many interesting ideas.  paraphrasing a bit,
my friend said that half-way through an implementation,
there were usually two results: ``this is brilliant!'', or
``why am i here??''.  he said it was rarely possible even to
guess which would result beforehand.

Re: [9fans] writing code

[boyd, rounin]

> there were usually two results: ``this is brilliant!'', or
> ``why am i here??''.

an additional phrase often uttered is ''that's funny ...'' when
some new insight is stumbled upon.
--
MGRS 31U DQ 52572 12604

Re: [9fans] writing code

[Russ Cox]

>         isochronous/streaming data transfer over 9p:
>
>                 9p is slow over wide area networks when streaming
>                 data, due to the ping-pong nature of the data
>                 transfer.  can anything be done to help solve this?

sure.  you could imagine adding a stream message to
start some number of reads, but maybe it's enough to
define that streaming style servers allow the client to
queue multiple read messages and respond in order.

you can already do that for file transfers by using the
offset field appropriately.

it's less clear what the kernel interface for streaming
would look like.

>         distributed authentication:
>
>                 the plan 9 authentication model relies on having an
>                 on-line authentication server.  as firewalls and
>                 mobile devices continue to proliferate, might it be
>                 worthwhile adding support for a peer-to-peer model be
>                 more appropriate?

i don't know what peer-to-peer means, but if we moved to
a public key model (which was the reason presotto created p9any)
and had the auth server just be a repository for public keys
(signed by bootes), then any amount of caching could happen.

>         graphics:
>
>                 high-bandwidth bitmap access is slow.  additionally,
>                 even the existing hardware acceleration could be
>                 leveraged more than it is (if any portion of a window
>                 is obscured, then no h/w acceleration is used for that
>                 window).  is it conceivable to have a system where all
>                 graphics operations are accelerated (as apple are
>                 apparently to be doing with their next system), or
>                 does the current architecture preclude this?

you don't need to accelerate everything, just the common stuff.
the obscured window case you describe is an important one
that should be handled better.  i'd love to see that happen.
it's not so much the lack of acceleration as the copying to
backing store and back.

i'm less excited by high-bandwidth bitmap access, but it still
shouldn't be hard.  rob took rio out of the loop for exactly this
reason -- talking to a local /dev/draw is just a single copy of the
data from user space to the frame buffer.  what's needed is a
driving application.

>         graphics primitives:
>
>                 graphics drawn with the existing non-bitblt primitives
>                 is not great (e.g.  lots of jaggies on diagonal
>                 lines).  could implementing subpixel rendering help
>                 matters here?

it should be straightforward to adapt the line drawing algorithm
to put down alpha-blended grey.  that would be nice.

>         how can i continue to do work when a server goes down?
>
>                 aan can deal with a broken network connection, but say
>                 someone reboots the fileserver?  is there any way we
>                 can incorporate some redundancy into the system, or
>                 make it easier for a applications to recover?

there have been at least two attempts to do this.  the early
brazil kernels maintained state in the Chans and tried to reestablish
them, but my understanding is that the code never really worked
right, and eventually it got taken out.  i wrote a user-level file
server for 9P1 that redialed as necessary to keep the connection
running without any help from the kernel.  it worked very well
but i never updated it for 9P2000.  it's not a big program.

russ

Re: [9fans] writing code

[rog]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

> sure.  you could imagine adding a stream message to
> start some number of reads, but maybe it's enough to
> define that streaming style servers allow the client to
> queue multiple read messages and respond in order.
>
> you can already do that for file transfers by using the
> offset field appropriately.

i tried that, and it didn't seem to speed things up much.  regardless
of the number of concurrent reads, it was still much slower than
streaming TCP.

i couldn't say why though - i just measured it across a slow
trans-atlantic connection.

if you want to experiment, i've attached a version of the Inferno
cp(1) called "streamcp" that uses this technique to try to speed up
file transfer; it allows you to specify the number of concurrent reads
and writes.

perhaps someone that knows something about TCP might be able to say
why this technique can't use more of the available bandwidth?  it'd be
great if it could...

[-- Attachment #2: streamcp.b.gz --]
[-- Type: application/octet-stream, Size: 2281 bytes --]

Re: [9fans] writing code

[rog]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

> sure.  you could imagine adding a stream message to
> start some number of reads, but maybe it's enough to
> define that streaming style servers allow the client to
> queue multiple read messages and respond in order.
>
> you can already do that for file transfers by using the
> offset field appropriately.

i tried that, and it didn't seem to speed things up much.  regardless
of the number of concurrent reads, it was still much slower than
streaming TCP.

i couldn't say why though - i just measured it across a slow
trans-atlantic connection.

if you want to experiment, i've attached a version of the Inferno
cp(1) called "streamcp" that uses this technique to try to speed up
file transfer; it allows you to specify the number of concurrent reads
and writes.

perhaps someone that knows something about TCP might be able to say
why this technique can't use more of the available bandwidth?  it'd be
great if it could...

[-- Attachment #2: streamcp.b.gz --]
[-- Type: application/octet-stream, Size: 2281 bytes --]

Re: [9fans] writing code

[rog]

> it should be straightforward to adapt the line drawing algorithm
> to put down alpha-blended grey.  that would be nice.

given that a pixel with alpha notionally represents a partially filled
area, might it would make sense to change the interface so that you
can specify lengths smaller than integer pixels?  if you're using
alpha blending, a line that's half a pixel in radius is quite a
reasonable thing, for example.

> you don't need to accelerate everything, just the common stuff.
> the obscured window case you describe is an important one
> that should be handled better.  i'd love to see that happen.
> it's not so much the lack of acceleration as the copying to
> backing store and back.

i think it has to copy to backing store.  i think maybe the underlying
problem is that the backing store is in main memory, not video memory.

given that video cards these days tend to have lots of memory, maybe
it would be possible to allocate some off-screen images in video
memory, thus making them accessible to current acceleration routines.
i know virtually nothing about vid cards, so this might easily be
impossible; just a thought.

from a plan 9 point of view, maybe one could make the unused portion
of the vid memory another memory pool from which memdraw could choose
to allocate?

> there have been at least two attempts to do this.  the early
> brazil kernels maintained state in the Chans and tried to reestablish
> them, but my understanding is that the code never really worked
> right, and eventually it got taken out.  i wrote a user-level file
> server for 9P1 that redialed as necessary to keep the connection
> running without any help from the kernel.  it worked very well
> but i never updated it for 9P2000.  it's not a big program.

i've got an inferno program that does something similar.  the problem
i have with it is to do with non-idempotent 9p requests.  e.g.  i send
a Tcreate and the server goes down.  has the file been created or not?
should the intermediate agent resend the request or not after it has
connected.

as far as i can see, you can't do this in general without some kind of
application knowledge.  but maybe there's a cunning way of doing it.

the first classic example i encountered of this was when i sent a
"reboot" message through such a connection.  the kernel rebooted
immediately (not sending the reply), and as soon as the server came
back up again, it resent the request, causing another reboot, and on
and on...


oh yes, here's another one for the pot:
change screen resolution dynamically.

Re: [9fans] writing code

[Russ Cox]

> the first classic example i encountered of this was when i sent a
> "reboot" message through such a connection.  the kernel rebooted
> immediately (not sending the reply), and as soon as the server came
> back up again, it resent the request, causing another reboot, and on
> and on.

works as documented!  ;-)

> oh yes, here's another one for the pot:
> change screen resolution dynamically.

i made this work once, but in the aborted
plan9port for windows.  it's not too hard.
if someone wants to go after it i can dig up
the code i was using.

russ

Re: [9fans] writing code

[Russ Cox]

For those who are interested in making plan9port
work under Windows, I put out the code from my last
attempt, pieces of which should be salvageable for
use.  Also in there is my /dev/draw that copes with
screen resizes.

See http://swtch.com/usr/local/plan9/9pm/README.

Russ

Re: [9fans] writing code

[Charles Forsyth]

>>given that a pixel with alpha notionally represents a partially filled
>>area, might it would make sense to change the interface so that you

it's really transparency (or opacity), not partial filling (of an area).
the whole area is filled, but with something more or less transparent/opaque.

Re: [9fans] writing code

[rog]

> it's really transparency (or opacity), not partial filling (of an area).
> the whole area is filled, but with something more or less transparent/opaque.

from the porter-duff paper:
: If α(a) and α(b) represent subpixel areas covered by opaque geometric
: objects, the overlap of objects within the pixel is quite arbitrary.
: We know that object A divides the pixel into two subpixel areas of
: ratio α(a):1-α(a).  We know that object B divides the pixel into two
: subpixel areas of ratio α(b):α(1-b).  The result of the assumption is
: the same arithmetic as with semi-transparent objects and is summarised
: in the following table:

Re: [9fans] writing code

[Charles Forsyth]

there's a qualifying conditional at the start of that sentence
and as with a few early papers it's a rather complex description
for something that becomes less elaborate with a more abstract interpretation,
even when the computations are exactly the same!

Re: [9fans] writing code

[rog]

> there's a qualifying conditional at the start of that sentence
> and as with a few early papers it's a rather complex description
> for something that becomes less elaborate with a more abstract interpretation,
> even when the computations are exactly the same!

actually, the next paragraph seems to unqualify the conditional:

: The assumption is quite good for most mattes, though it can be
: improved if we know that the coverage seldom overlaps (adjacent
: segments of a continuous line) or always overlaps (repeated
: application of a picture).  For ease in presentation throughout this
: paper, let us make this assumption and consider the alpha values as
: representing subpixel coverage of opaque objects.

i'd have thought this was rather a useful way of looking at things
when we're talking about graphics primitives which might allow
sub-pixel positioning of anchor points, but currently do not.

Re: [9fans] writing code

[McLone]

On Fri, 18 Feb 2005 18:52:51 +0000, rog@vitanuova.com <rog@vitanuova.com> wrote:
> maybe one could make the unused portion of the vid memory
> another memory pool from which memdraw could choose to allocate?
i even saw that one somewhere in linux patches, so it can be done.
One can have memory disk in videoram, IIRC

p.s. i strongly dislike linux's code - that one was really ugly.
--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[Fco. J. Ballesteros]

> Plan 9 has a strong intrinsic
> opposition to change; this is mostly good beacuse of obvious
> reasons. But some experimentation would'nt hurt. I just can't see the

Then just go ahead and experiment!

These days we run what we call Plan B. That's an experiment
on Plan 9, the system behaves differently and we're learning
what we like of the system, and what we do not. In particular,
what we like is that the system mounts resources automatically
and that it makes it easy to adapt to changes. What we don't like
is mostly that during the auth stage, a missbehaving fileserver may
lock your system.

Before this, we experimented with redirfs, which was a previous attempt
to do this at user-level, and it didn't quite work, because not all files
were automatically mounted and failover could fail :-), doing this in the
kernel has simplified things a lot.

Regarding the UIs,
we have what we call omero (another experiment), it's a mixture of
a window-toolkit and a file server, that handles all the graphics by
its own. The application creates files to build its UI, and the fs takes
care of the mouse and everything else. This allows you to replicate
and move around UI components without placing the burden in the
application.

During the construction of omero we tried two nice experiments, one
was mouse cooked mode, which I now consider as a mistake, after
experimenting with it. The other, which I consider a big success, is
defining the left control, start-button, left-alt as mouse 1, 2, and 3 buttons.
We use the menu for composing (old alt), and capslock as control.
This made it very nice to use 3-button interfaces (like acme and omero)
in laptops.

Probably sometime this year we'll consider both the system and omero
stable enough to try and talk about how to bring this stuff into Plan 9, if
anyone cares. Even if others consider that it's not worth placing this
kind of stuff in Plan 9, some things might still be useful, like the mouse
buttons thing.

My point is that experimentation is a good thing, so go ahead. Of course
it's perfectly nice for others to say `we won't use the resulting code', but
that's why it's an experiment, isnt it? It may also be that those that
refuse to use the resulting code might teach you a better way of doing it,
which is even better.

good luck

PS: Sorry about the long mail :-)

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> Then just go ahead and experiment!

Perfectly sound advice, given an ideal universe. Alas, in a realistic
universe, there
	a) are only 24 hrs in a day, of wich I'd like at least 8 use for sleep;
	b) is a little 3 year old girl I can't tell
	"sorry honey, no playing as of today, daddy likes plan 9 more now"

I envy peope who actually have time to spare.

P.S. Sorry for the rant. Feel free to disregard.

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> Regarding the UIs,
> we have what we call omero (another experiment), it's a mixture of
> a window-toolkit and a file server, that handles all the graphics by
> its own. The application creates files to build its UI, and the fs takes
> care of the mouse and everything else. This allows you to replicate
> and move around UI components without placing the burden in the
> application.

How do you think that recent GUI programming style is too difficult
to understand for non-computer science students.   We need GUI
only for user interface, and it should be very easy to deal with, and
can be used from all of the languages without special enbedded portion
of those tools.

Once upon a time, programming was a fan for many scientists because
it was not so difficult.    They have to just care of the precisenenss of
their own parts.   Now a days, I think most of them are buying some
commercial products and students don't know how to make it from
scratch.   It will soon make this world darker I fear.

Does your Plan B help such?

Kenji

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

GUI is a term invented by people who sell them.

i was very impressed in the mid 80's that my secretary
at the labs totally embraced the mux/jim jerq that was
put in front of her (maybe it was 56xx).

(mux/mpx -> rio, jim -> sam).

i knew the lads were on to a good thing.  I think seeing
a face when e-mail arrived made the entire building more
efficient.  e-mail was more efficient than a phone call.
i don't think i ever called a co-worker in those days
except for a "I'm really hungry, you said dinner was on".

20 years on i am using programs which i know are
technically very goood and useful (i'll quote adobe audition).

ok, i'll rant on.  HST is gone so someone has to do it.

audtion is quite useable - i've been doing a soundtrack with it,
but open it up and you have half a dozen mysterious windows
and even more click on menus up the top, many options
being sub-menus and so forth.

now if it was written in a different thread of software development
then it would be a small window in rio with a small menu to
open/save/etc.  great, i choose "wave" from the menu and get to
sweep out a wave window.  just what i wanted. it has an
appropriate menu.  etc.  i choose "multitrack" i get something
more complex which will need very specific mouse interaction ...
but plan9 has no problems with that.

such windows need GUIs - dragging a selection on a wave,
but it's kinda different huh?

end of rant.

brucee

On Mon, 21 Feb 2005 11:54:16 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:
> > Regarding the UIs,
> > we have what we call omero (another experiment), it's a mixture of
> > a window-toolkit and a file server, that handles all the graphics by
> > its own. The application creates files to build its UI, and the fs takes
> > care of the mouse and everything else. This allows you to replicate
> > and move around UI components without placing the burden in the
> > application.
>
> How do you think that recent GUI programming style is too difficult
> to understand for non-computer science students.   We need GUI
> only for user interface, and it should be very easy to deal with, and
> can be used from all of the languages without special enbedded portion
> of those tools.
>
> Once upon a time, programming was a fan for many scientists because
> it was not so difficult.    They have to just care of the precisenenss of
> their own parts.   Now a days, I think most of them are buying some
> commercial products and students don't know how to make it from
> scratch.   It will soon make this world darker I fear.
>
> Does your Plan B help such?
>
> Kenji
>
>

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> such windows need GUIs - dragging a selection on a wave,
> but it's kinda different huh?

GUI not necessarily means controls/widgets; sometimes the whole is bigger
than the sum of components. Our society is literate, i.e., text-based,
no matter how hard certain groups try to change this. Take a look around,
basically every GUI has some textual info attached to an action that
can be performed. Even in 100% graphic icons the mind has first to
form a textual "token" before it can recognise what it is. The framing
of a button is just syntactic sugar so that you -god forbid- would not
actually have to think what's written there.

In "all-text" systems there of course remains the problem how the user
is supposed to pick active snippets from the general flow. Typescript
systems have this one solved rather elegantly IMHO, by making everyhing
active. The whole universe is your playground.

Graphics should support text, not vice versa.

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Tiit, Kenji, Nemo, and others

TL> GUI not necessarily means controls/widgets; sometimes the whole is bigger
TL> than the sum of components. Our society is literate, i.e., text-based,
TL> no matter how hard certain groups try to change this. Take a look around,
TL> basically every GUI has some textual info attached to an action that
TL> can be performed. Even in 100% graphic icons the mind has first to
TL> form a textual "token" before it can recognise what it is.
IMHO text/language only represents thoughts, images most fastest way to recognize
something, text one of images. If your say 'disk' only who known English
(ok, this word in many languages sounds like 'disk' but it's only example)
can understand you, but when you show 'disk' anyone understand you.
If in Acme 'Get Put send' change to button you lose nothing.
TL> The framing of a button is just syntactic sugar so that you -god forbid- would not
TL> actually have to think what's written there.

TL> In "all-text" systems there of course remains the problem how the user
TL> is supposed to pick active snippets from the general flow. Typescript
TL> systems have this one solved rather elegantly IMHO, by making everyhing
TL> active. The whole universe is your playground.
Plan 9 my first system with typescript system, and first impression was
great, but now I see many things is missing (buttons, lists etc).

Example:
If I need cad system, how I can create it in typescript system?
Or maybe you suggest type all command in console ;)

KO> Once upon a time, programming was a fan for many scientists because
KO> it was not so difficult. They have to just care of the precisenenss of
KO> their own parts. Now a days, I think most of them are buying some
KO> commercial products and students don't know how to make it from
KO> scratch.
It's good for people who 'write code', it's every time have
work... I am sure 'programming user' is utopia...
RO> It will soon make this world darker I fear.
We can't stop this :-)

nemo> Regarding the UIs,
nemo> we have what we call omero (another experiment), it's a mixture of
nemo> a window-toolkit and a file server, that handles all the graphics by
nemo> its own. The application creates files to build its UI, and the fs takes
nemo> care of the mouse and everything else. This allows you to replicate
nemo> and move around UI components without placing the burden in the
nemo> application.
Can I see it?


--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Fco. J. Ballesteros]

> Can I see it?

http://lsub.org/who/nemo/export/omero.gif

What you see is done so it could work on Plan 9 as well, so I
hope this is not too far off-topic ;-)

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> http://lsub.org/who/nemo/export/omero.gif

Hmm, it looks like same to our masv scheme, somewhat different
looks though.   I'm now stopping this line because it does not help
us (not pro-programmer) from tieing too much tightly us to "GUI
programming", too.

GUI programming should be separated from main programming stream,
I now think.   It is because the main purpose of programming is not make
GUI, which is just for user interface.   Or most importantly, it should not
add any of difficult things to programming, I believe.

Kenji

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

Sorry, I forgot this.

I'm not abusing you, nemo.
Everyone should try what s/he believes it's nice.
Fortunately, none knows what must be the best one in this case.☺
After times of tries, we may find better one for Plan 9 which is
the test base for new things, I believe.

Kenji

[-- Attachment #2: Type: message/rfc822, Size: 3762 bytes --]

From: Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Evolving rio / GUI development
Date: Tue, 22 Feb 2005 10:16:23 +0900
Message-ID: <2e7956d0fc4673cd2ccaa1a057955f86@granite.cias.osakafu-u.ac.jp>

> http://lsub.org/who/nemo/export/omero.gif

Hmm, it looks like same to our masv scheme, somewhat different
looks though.   I'm now stopping this line because it does not help
us (not pro-programmer) from tieing too much tightly us to "GUI
programming", too.

GUI programming should be separated from main programming stream,
I now think.   It is because the main purpose of programming is not make
GUI, which is just for user interface.   Or most importantly, it should not
add any of difficult things to programming, I believe.

Kenji

Re: [9fans] Evolving rio / GUI development

[Matthias Teege]

> GUI programming should be separated from main programming stream,
> I now think.   It is because the main purpose of programming is not make

Yes!

> GUI, which is just for user interface.   Or most importantly, it should not

It is the interface to a human.  It should be programmed by poeple who
know how humans "work" and not from people who know how computers
work.

Matthias

Re: [9fans] Evolving rio / GUI development

[Gorka Guardiola]

> Example:
> If I need cad system, how I can create it in typescript system?
> Or maybe you suggest type all command in console ;)


Autocad started as a lisp interpreter I think and many professionals prefer the
commands to the placing stuff with the mouse or at least combine both...


											G.

Re: [9fans] Evolving rio / GUI development

[lucio]

> Autocad started as a lisp interpreter I think and many professionals prefer the
> commands to the placing stuff with the mouse or at least combine both...

Dotty (from graphviz) still operates on that principle.  So it's not
as if there is only one scheme of things.

++L

Re: [9fans] Evolving rio / GUI development

[Skip Tavakkolian]

>> Autocad started as a lisp interpreter I think and many professionals prefer the
>> commands to the placing stuff with the mouse or at least combine both...
> 
> Dotty (from graphviz) still operates on that principle.  So it's not
> as if there is only one scheme of things.

My preference for the whole gui approach would be to have it cleanly
separated from the applications.  Following /dev/draw's model, ideally
a filesystem would enforce the GUI↔application interface.  A
refinement (not a new idea either) is to tie the whole "chrome"
filesystem to a language like tk/tcl; tcl or lisp/scheme would not be
my choices.

If the chrome could be cleanly detached from the underlying functions
and could be changed easily, look-and-feel development could continue
well past the time when it's functionality is complete.  If someone wanted
eye-candy, he could develop it.  Perhaps generalizing the interface is
not possible and would require specialization to specific problem
sets.

Re: [9fans] Evolving rio / GUI development

[Chesky Salomon]

On Mon, 21 Feb 2005 16:37:37 -0800, Skip Tavakkolian <9nut@9netics.com> wrote:
> My preference for the whole gui approach would be to have it cleanly
> separated from the applications.  Following /dev/draw's model, ideally
> a filesystem would enforce the GUI↔application interface.  A
> refinement (not a new idea either) is to tie the whole "chrome"
> filesystem to a language like tk/tcl; tcl or lisp/scheme would not be
> my choices.
> 

Searching the archives...
On Fri, 6 Sep 2002 20:34:16 -0700, Russ Cox wrote:
> 'How I ported the [Mozilla|Konqueror]
> HTML rendering engine to plan9 and 
> made it fit well with the rest of the system.'

2½ years from challenge to concept... ;-)

--Joel

Re: [9fans] Evolving rio / GUI development

[Skip Tavakkolian]

Something with finer graphics controls, more transparent and
less obtuse than the Struts model.

"or how to reimplement CICS for Plan9"

>> My preference for the whole gui approach would be to have it cleanly
>> separated from the applications.  Following /dev/draw's model, ideally
>> a filesystem would enforce the GUI↔application interface.  A
>> refinement (not a new idea either) is to tie the whole "chrome"
>> filesystem to a language like tk/tcl; tcl or lisp/scheme would not be
>> my choices.
>> 
> 
> Searching the archives...
> On Fri, 6 Sep 2002 20:34:16 -0700, Russ Cox wrote:
>> 'How I ported the [Mozilla|Konqueror]
>> HTML rendering engine to plan9 and 
>> made it fit well with the rest of the system.'
> 
> 2½ years from challenge to concept... ;-)
> 
> --Joel

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

On Mon, 21 Feb 2005, Gorka Guardiola wrote:

> Autocad started as a lisp interpreter I think and many professionals
> prefer the commands to the placing stuff with the mouse or at least
> combine both...

There's no universal rule. One of the nicest CAD systems I used was the
Altera system, which let you easily intermix text and graphics symbols as
you needed. You could create an include file from a graphics symbol, and
you could easily create a graphics symbol from AHDL code. The worst
systems are the ones that give you ONLY pictures or ONLY text.

The one thing I've observed in the last xy years is that some people love
those graphical systems and some people hate 'em. The most versatile
people learn to use both text and graphical aspects of the tools -- which
is why really good engineers like the Linux versions of the CAD tools as
opposed to the Windows versions -- you get way more options with the Linux
versions. For one thing, on Linux, you can shitcan all the various
'Wizards' and get in there with grep and sed and Makefiles and build a
project.

ron

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> Example:
> If I need cad system, how I can create it in typescript system?
> Or maybe you suggest type all command in console ;)

You don't have to confine yourself to text. I just think that text
should be the primary medium.

Re: [9fans] Evolving rio / GUI development

[lucio]

> IMHO text/language only represents thoughts, images most fastest way to recognize
> something, text one of images. If your say 'disk' only who known English
> (ok, this word in many languages sounds like 'disk' but it's only example)
> can understand you, but when you show 'disk' anyone understand you.

Try an icon for "beauty", or "intelligence".

++L

Re: [9fans] Evolving rio / GUI development

[Matthias Teege]

>> IMHO text/language only represents thoughts, images most fastest way to recognize
>> something, text one of images. If your say 'disk' only who known English

That is not true.  Start your Mozilla, and move the cursor over some
icon.  If you wait some seconds, you'll get a long description of the
icon.  Why?  Why do I need a description of an icon if it is the
"fastest way to recognize"?  The fundamental rule of user interfaces
is adaption.  A good interface must be monotone/consistent, modeless
and there must be only one way to solve a problem.  It must support
adaption.  It must be like Acme without a tagline (and with graffic
and WYSIWYG support ;-))

A textual interface is the most user friendly today (textual != cli).

Matthias

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Matthias,

Tuesday, February 22, 2005, 10:07:36 AM, you wrote:
>>> IMHO text/language only represents thoughts, images most fastest way to recognize
>>> something, text one of images. If your say 'disk' only who known English
MT> That is not true.  Start your Mozilla, and move the cursor over some
MT> icon.  If you wait some seconds, you'll get a long description of the
MT> icon.  Why?  Why do I need a description of an icon if it is the
MT> "fastest way to recognize"?
But after reading description you known what mean this icon.
This is like learn new language - you read word in dictionary once.

Example:
Long time (while I not read 'man acme' :) I can't understand what is
'Look', but if it have tool-tip i need just stop mouse over them...
MT> The fundamental rule of user interfaces
MT> is adaption.  A good interface must be monotone/consistent, modeless
MT> and there must be only one way to solve a problem.  It must support
MT> adaption.  It must be like Acme without a tagline (and with graffic
MT> and WYSIWYG support ;-))
That is right!

MT> A textual interface is the most user friendly today (textual != cli).
cli?
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[boyd, rounin]

> 'Look', but if it have tool-tip i need just stop mouse over them...

tool-tips are definitive proof of the failure of a user interface design.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Evolving rio / GUI development

[David Tolpin]

On 22.02.2005, at 18:00, boyd, rounin wrote:

>> 'Look', but if it have tool-tip i need just stop mouse over them...
>
> tool-tips are definitive proof of the failure of a user interface
> design.

man is like a tool-tip. It explains what a command does when it is not
obvious for a casual user from the command's name. Just less convenient
to reach.

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

>> tool-tips are definitive proof of the failure of a user interface design.
>
> man is like a tool-tip. It explains what a command does when it is not
> obvious for a casual user from the command's name. Just less convenient
> to reach.

You've just proven Boyd's point. If an explanation requires an
explanation, don't you think that the orginial explanation is a failure?
"What we seem to have here is a failure to communicate."

Re: [9fans] Evolving rio / GUI development

[David Tolpin]

On 22.02.2005, at 18:15, Tiit Lankots wrote:

>>> tool-tips are definitive proof of the failure of a user interface
>>> design.
>> man is like a tool-tip. It explains what a command does when it is
>> not obvious for a casual user from the command's name. Just less
>> convenient to reach.
>
> You've just proven Boyd's point. If an explanation requires an
> explanation, don't you think that the orginial explanation is a
> failure? "What we seem to have here is a failure to communicate."
>

I did not prove anyone's point. A symbol, whether textual or pictorial,
is not an explanation of self. It is a name; a name needs an
explanation. A tooltip is a good way to introduce an explanation; in
particular when someone coming from a non-american-english environment
trying to use an interface.

It is also nice for people who use alternative signaling system for
interaction, those visually impared do. They listen to the tooltip for
the first time, and then attach a tone or a tune which they recognize
easily to the icon or to the abbreviated name.

David

Re: [9fans] Evolving rio / GUI development

[lucio]

>> 'Look', but if it have tool-tip i need just stop mouse over them...
>
> tool-tips are definitive proof of the failure of a user interface design.

Agreed, specially when they need to be available in zillions of
alternative languages.  I have the occasional laugh at StarOffice when
it pops up unexpected German messages.  I do have an old copy, but it
makes a fine example.

And of course you never know whether you'll get a tool-tip or not.

++L

Re: [9fans] Evolving rio / GUI development

[Charles Forsyth]

>>MT> "fastest way to recognize"?

>But after reading description you known what mean this icon.
>This is like learn new language - you read word in dictionary once.

it is more like learning a new language that changes spelling and meaning
with every person (application) you meet that speaks it.

as the experience with international language-less signs suggests, it's hard to
design images that convey messages with complete accuracy.
it's worse when the conventions change (as part of international
standardisation, for instance).
that nasty looking green-and-yellow wire
must surely be the live and dangerous one ...

Re: [9fans] Evolving rio / GUI development

[Martin C.Atkins]

On Tue, 22 Feb 2005 14:09:59 +0000 Charles Forsyth <forsyth@terzarima.net> wrote:
>..
> that nasty looking green-and-yellow wire
> must surely be the live and dangerous one ...

Especially since yellow is nature's warning colour (examine a handy bee).

Martin

--
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] Evolving rio / GUI development

[Gorka Guardiola]

> Try an icon for "beauty", or "intelligence".


Interesting. And why do you need a button/tag with that on?. What exact
program are you thinking on?. Just curious...


								G.

Re: [9fans] Evolving rio / GUI development

[lucio]

> Interesting. And why do you need a button/tag with that on?. What exact
> program are you thinking on?. Just curious...

I only thought of it later: what about "volume" or "intensity"?

I was merely countering the suggestion that icons are better than
words, where in my opinion words are far more powerful symbols than
images, even though the latter are more descriptives.

Different levels of abstraction, really.  The more remote (abstract)
the symbol, the firmer the supporting social convention has to be to
support it.  I take that (I'm no educated philosopher) to imply that
fewer ambiguities are possible.  Mathematics makes a nice extreme
instance.

++L

Re: [9fans] Evolving rio / GUI development

[Skip Tavakkolian]

>> Interesting. And why do you need a button/tag with that on?. What exact
>> program are you thinking on?. Just curious...
>
> I only thought of it later: what about "volume" or "intensity"?
>
> I was merely countering the suggestion that icons are better than
> words, where in my opinion words are far more powerful symbols than
> images, even though the latter are more descriptives.
>
> Different levels of abstraction, really.  The more remote (abstract)
> the symbol, the firmer the supporting social convention has to be to
> support it.  I take that (I'm no educated philosopher) to imply that
> fewer ambiguities are possible.  Mathematics makes a nice extreme
> instance.

I was thinking along the same lines, then I remembered something
from Bill Bryson's latest book; he was talking about the chaotic notations
and abbreviations that were used for elements before a
Swedish scientist came up with a reasonable approach that became
the standard. If it's standard, then everyone gets it.

The most exact icon I've ever seen is the "bullet in the forehead"
button in an early version of Inferno's debugger.  I thought the
blood dripping was a nice touch, removing any doubt.

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

I find the "oh my god, what does that wonderful icon mean!" and
the phone calls involving talk like "yeah it's that kinda blue one
with the squiggle on it" rather entertaining/demeaning.

brucee

Re: [9fans] Evolving rio / GUI development

[C H Forsyth]

>>The most exact icon I've ever seen is the "bullet in the forehead"
>>button in an early version of Inferno's debugger.  I thought the
>>blood dripping was a nice touch, removing any doubt.

absolutely!

Re: [9fans] Evolving rio / GUI development

[fgergo]

On Wed, 23 Feb 2005 00:17:11 +0000, C H Forsyth <forsyth@vitanuova.com> wrote:
> >>The most exact icon I've ever seen is the "bullet in the forehead"
> >>button in an early version of Inferno's debugger.  I thought the
> >>blood dripping was a nice touch, removing any doubt.
>
> absolutely!

Any chance of putting it and the others back into wm/deb.
I suppose it is from version 0.1. I only have 0.2, but it already had
different icons. They are not that expressive.

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

they are in the original distribution.  and then someone who didn't
even know how to run emu decided they were politically incorrect.
the originals are much better than the VC inspired things that appeared.
tho i think someone had a laugh if you examine them closely.

i have a smiley "kill thread" t-shirt.

brucee

> Any chance of putting it and the others back into wm/deb.
> I suppose it is from version 0.1. I only have 0.2, but it already had
> different icons. They are not that expressive.

Re: [9fans] Evolving rio / GUI development

[lucio]

> I was thinking along the same lines, then I remembered something
> from Bill Bryson's latest book; he was talking about the chaotic notations
> and abbreviations that were used for elements before a
> Swedish scientist came up with a reasonable approach that became
> the standard. If it's standard, then everyone gets it.

Talk about going around in circles.  But Bill Bryson vs Andy Tanenbaum
is a rather neat stand-off.  My Tanenbaum literature is presently
hidden, so I can't check the number of n's in his surname :-(

++L

Re: [9fans] Evolving rio / GUI development

[Rob Pike]

> If it's standard, then everyone gets it.

C++ is standard.  I don't get it.

-rob

Re: [9fans] Evolving rio / GUI development

[Gorka Guardiola]

>> If it's standard, then everyone gets it.
>
> C++ is standard.  I don't get it.
>
> -rob


Are you standard?.

			G.

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

rob is a derived class.  fortunately he chooses his friends wisely.
i've been C++ing a bit lately (don't blame me).  i just can't wait
to see what features are needed for the next standard.

brucee

On Wed, 23 Feb 2005 14:19:43 +0100, Gorka Guardiola <paurea@lsub.org> wrote:
> >> If it's standard, then everyone gets it.
> >
> > C++ is standard.  I don't get it.
> >
> > -rob
>
> Are you standard?.

>                        G.
>
>

Re: [9fans] Evolving rio / GUI development

[Brantley Coile]

	C = 89;
	print("%d\n", C++);

	What's the deal?  I still get 89?
	Now, if the name had been ++C I would've looked at it.  :)

	Brantley

> rob is a derived class.  fortunately he chooses his friends wisely.
> i've been C++ing a bit lately (don't blame me).  i just can't wait
> to see what features are needed for the next standard.
>
> brucee
>
> On Wed, 23 Feb 2005 14:19:43 +0100, Gorka Guardiola <paurea@lsub.org> wrote:
>> >> If it's standard, then everyone gets it.
>> >
>> > C++ is standard.  I don't get it.
>> >
>> > -rob
>>
>> Are you standard?.
>
>>                        G.
>>
>>

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

On Thu, 24 Feb 2005, Bruce Ellis wrote:

> rob is a derived class.  fortunately he chooses his friends wisely.
> i've been C++ing a bit lately (don't blame me).  i just can't wait
> to see what features are needed for the next standard.

static dynamic virtual casts

ron

Re: [9fans] Evolving rio / GUI development

[Rob Pike]

public: volatile friend boyd;

-rob

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

Indeed perhaps the best aspect of C++ coding is embedding
puns in the code  Haven't had this much fun since COBOL.

- virtual pure brucee

On Wed, 23 Feb 2005 10:37:24 -0500, Rob Pike <robpike@gmail.com> wrote:
> public: volatile friend boyd;
>
> -rob

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

On Thu, 24 Feb 2005, Bruce Ellis wrote:

> Indeed perhaps the best aspect of C++ coding is embedding
> puns in the code  Haven't had this much fun since COBOL.

blast. We need a PERFORM verb.

ron

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

what about the lonely "try" keyword?  what if all you need is
a "penalty goal".

this is getting silly, back to work.

brucee

On Wed, 23 Feb 2005 09:06:56 -0700 (MST), Ronald G. Minnich
<rminnich@lanl.gov> wrote:
>
>
> On Thu, 24 Feb 2005, Bruce Ellis wrote:
>
> > Indeed perhaps the best aspect of C++ coding is embedding
> > puns in the code  Haven't had this much fun since COBOL.
>
> blast. We need a PERFORM verb.
>
> ron
>

Re: [9fans] Evolving rio / GUI development

[Skip Tavakkolian]

class brucee : { real friend class brucej; }

Re: [9fans] Evolving rio / GUI development

[David Leimbach]

On Thu, 24 Feb 2005 00:39:44 +1100, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> rob is a derived class.  fortunately he chooses his friends wisely.
> i've been C++ing a bit lately (don't blame me).  i just can't wait
> to see what features are needed for the next standard.
>

Fixed width integer types? :)

I've been ripping off software from boost to generate them at compile time using
template metaprogramming junk.  It works on LP32 and LP64 systems so far that
I've tested but it'd just be nicer if the standard would specify types

There is a really decent book on dealing with a bunch of C++
annoyances [if you must]
called Imperfect C++ that lists a bunch of problems and workarounds.

Dave
> brucee
>
> On Wed, 23 Feb 2005 14:19:43 +0100, Gorka Guardiola <paurea@lsub.org> wrote:
> > >> If it's standard, then everyone gets it.
> > >
> > > C++ is standard.  I don't get it.
> > >
> > > -rob
> >
> > Are you standard?.
>
> >                        G.
> >
> >
>

Re: [9fans] Evolving rio / GUI development

[Richard Miller]

> Fixed width integer types? :)

Actually quite a useful feature for hardware compilation (i.e. when
the output of the compiler is a VHDL chip description).  For example,
see http://www.sle.sharp.co.uk/research/scd/bach.htm

Re: [9fans] Evolving rio / GUI development

[Dave Lukes]

Yes, de facto:-).

On 23 Feb 2005, at 13:19, Gorka Guardiola wrote:

>>> If it's standard, then everyone gets it.
>>
>> C++ is standard.  I don't get it.
>>
>> -rob
>
>
> Are you standard?.
>
> 			G.
>

Re: [9fans] Evolving rio / GUI development

[Steve Simon]

> I was merely countering the suggestion that icons are better than
> words, where in my opinion words are far more powerful symbols than
> images, even though the latter are more descriptives.

Tis interesting that perceptually words are both symbols and
text - in order to read at more than a couple of hundred words
per min (roman script) you have to read words by pattern matching
and much of that through peripheral vision. People rarely read
the characters of a word unless its one they don't recognise.

[aside: We could have a bizzar icon that pops up when
you hover the mouse of Acme's Tag labels...]

-Steve

Re: [9fans] Evolving rio / GUI development

[Andrew Simmons]

>
>[aside: We could have a bizzar icon that pops up when
>you hover the mouse of Acme's Tag labels...]
Would this be bizarre enough?

http://www.juergenspecht.com/documentations/?number=1&photo=39#photo

Re: [9fans] Evolving rio / GUI development

[lucio]

> [aside: We could have a bizzar icon that pops up when
> you hover the mouse of Acme's Tag labels...]

ROFL!  Now, that's thinking "outside the box"!

++L

Re: [9fans] Evolving rio / GUI development

[Martin C.Atkins]

On Tue, 22 Feb 2005 23:47:40 +0000 "Steve Simon" <steve@quintile.net> wrote:
> Tis interesting that perceptually words are both symbols and
> text - in order to read at more than a couple of hundred words
> per min (roman script) you have to read words by pattern matching
> and much of that through peripheral vision. People rarely read
> the characters of a word unless its one they don't recognise.

Strange you should say that. I saw an article earlier in the week
that suggested that most of the success of "speed reading" courses is
to train people to do word-by-word pattern recognition. The unstated
conclusion would be that such courses are not so effective for people
who already read that way!

I wonder if people who read that way are also, on average, less good
at crossword puzzles/scrabble/etc? (Or have to learn these as a
separate skill?)

Martin
--
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] Evolving rio / GUI development

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

I don't think it does, if I understand what you said.
Doing UIs with omero is a bit simpler than doing them
with rio (same for acme). But it still requires programming.
Also, we are using the oberon/acme style of interaction (although
we got graphics as well).

[-- Attachment #2: Type: message/rfc822, Size: 3222 bytes --]

From: Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Evolving rio / GUI development
Date: Mon, 21 Feb 2005 11:54:16 +0900
Message-ID: <1831e14deca9e2a1e4c2c185f4979bcd@granite.cias.osakafu-u.ac.jp>

> Regarding the UIs,
> we have what we call omero (another experiment), it's a mixture of
> a window-toolkit and a file server, that handles all the graphics by
> its own. The application creates files to build its UI, and the fs takes
> care of the mouse and everything else. This allows you to replicate
> and move around UI components without placing the burden in the
> application.

How do you think that recent GUI programming style is too difficult
to understand for non-computer science students.   We need GUI
only for user interface, and it should be very easy to deal with, and
can be used from all of the languages without special enbedded portion
of those tools.

Once upon a time, programming was a fan for many scientists because
it was not so difficult.    They have to just care of the precisenenss of
their own parts.   Now a days, I think most of them are buying some
commercial products and students don't know how to make it from
scratch.   It will soon make this world darker I fear.

Does your Plan B help such?

Kenji

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> well, you folks all seem to be able to fit all your windows tiled. I just 
> plain can't. I've to two 21" LCDs and with the CAD systems etc. I use 
> there's no room at all to tile everything. It just doesn't work, hence my 
> need for multiple desktops and other such things. 

I think you mean virtual multiple deskops judging from andrey's comment
on this.

To me, I 'm not so good to remember the image in my head, that kind of
multiple desktops doesn't work well either.   It works for me, only to keep
web browser in a virtual desktop, and another work for another desktop etc.
In this sense, I'm doing completely different things for each desktop, and 
I'd be better to concentrate to use my brain only one for one thing at a time.
Although take a rest by using web browse is a usual play to me, too.☺
However, this is not a serious problem, if we think the computer for something
work.   However, if it doesn't make any problem, it's not bad to have virtual
desktops in Plan 9, I agree.

If we need many windows (need not be a desktop, I believe), probably I'm
doing one thing, and need to check multiple data at once.   In this case,
I'm sure tiling scheme can be used for this from my experience with marsv.
We just need a mouse operation to expand/shrink one window etc.   If
I want to see much larger data in a window, I believe I have to buy more
big physical medeia.☺ 

On the other hand, multiple tiled window scheme has a big advantage that
it can show us all the levels of possible operation in a desktop.  This makes
user easier to choose reasonable command from the windows.   No deep
hidden command which usually makes problem, and selling kindergarten
like teaching book.☺
How do you think of this?

Kenji

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> Although take a rest by using web browse is a usual play to me, too.☺
> However, this is not a serious problem, if we think the computer for something
> work.   However, if it doesn't make any problem, it's not bad to have virtual
> desktops in Plan 9, I agree.

When I wrote this, I was reading "why Europa has strike-slip fault things paper", and
failed to concentrate myself.    After had a lunch and joyful playing talks, I rethinked
"hide" operation must be enough for this purpose.   Is there any other reason why
we should have virtual desktop for Plan 9?

Kenji

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

Totally correct.  Label and Hide are enough for me to cope
with a few machines at once.

Gee ... open a big window and cpu somewhere, run rio.
Virtual desktop?  Call it what you like.

brucee

On Fri, 18 Feb 2005 16:10:27 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:
> > Although take a rest by using web browse is a usual play to me, too.☺
> > However, this is not a serious problem, if we think the computer for something
> > work.   However, if it doesn't make any problem, it's not bad to have virtual
> > desktops in Plan 9, I agree.
> 
> When I wrote this, I was reading "why Europa has strike-slip fault things paper", and
> failed to concentrate myself.    After had a lunch and joyful playing talks, I rethinked
> "hide" operation must be enough for this purpose.   Is there any other reason why
> we should have virtual desktop for Plan 9?
> 
> Kenji
> 
>

Re: [9fans] Evolving rio / GUI development

[Rob Pike]

On Fri, 18 Feb 2005 16:10:27 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:

> When I wrote this, I was reading "why Europa has strike-slip fault things paper", and
> failed to concentrate myself.    After had a lunch and joyful playing talks, I rethinked
> "hide" operation must be enough for this purpose.   Is there any other reason why
> we should have virtual desktop for Plan 9?
>
> Kenji
>

This is one of the greatest mail messages I ever received.

-rob

Re: [9fans] Evolving rio / GUI development

[McLone]

On Fri, 18 Feb 2005 12:50:13 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:
> We just need a mouse operation to expand/shrink one window etc.
In *box i bind mousewheel[s] or buttons 4-5 on window borders/title
for that. Highly useful.

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[rog]

> So, yes, rio is a fine and wonderful thing, but I don't buy it as the
> be-all and end-all of window managers.

winwatch helps, but i have to say, i do find available screen space
restrictive (and i'm running at 1400x1050). i run with acme
taking up all the horizontal space and 95% of the vertical
space, leaving a strip along the top for access to windows.
winwatch is useful.

> With multiple desktops, as much as I like rio, I find it easier to use
> flwm and swap around with CTRL-F[1234] etc.

so, like a fool, i thought "this'll be totally easy to do with rio; i'll just
place a filter onto its keyboard input that switches windows when it
sees a function key".

there sure are some sticky bits lurking under the surface in plan 9 if
you swim where others haven't swum before...

i kinda got it working, but it's not really usable.  here are some
gotchas i encountered along the way:

1) you can't make a full screen window in rio (1 pixel less in each dimension)
2) you can't make a borderless window in rio.
3) creation of a badly sized window fails silently.
4) there's no way of finding out the current available screen (*not* display)
	size when running rio in rio.
5) screenids run out quickly when you've got multiple clients creating screens
	(see /sys/src/libdraw/window.c:/25). most people don't notice
	because most windows are created by the same draw client.
	try:
		cpu
		for(i in `{seq 1 25}){window -m lens}
	perhaps screenid should probably be seeded somewhere random-ish
	(e.g. milliseconds^pid) and increase by prime multiples.

	at the least, the loop should at least detect that it's gone over the end
	and return an appropriate error message.
7) if you give rio an init command, it puts it in a new note group, so
	if you kill off the window within which rio is running, the
	command hangs around, thus:
8) managing recalcitrant groups of processes where the process names
	are all very similar is hard, particularly if you're running rio.
	very very easy to kill off your main window manager.
	there's no easy way to find out what processes are
	grouped together (perhaps ps could be able to print noteids, which
	helps a bit).

[if others consider any/all of the above to be bugs, i could
do patches, depending on what's considered the right way to fix
them.]

it's not worth posting my code.
conclusion: if you want to do this, modify rio itself!

'course there are other issues to solve too here, like:
if the plumber creates a new window, where should it appear?

i think rio can definitely be improved. that "sticky" menu has caused
me to unintentionally delete windows sooo many times, for one.

Re: [9fans] Evolving rio / GUI development

[arisawa]

rog said:

> i think rio can definitely be improved. that "sticky" menu has caused
> me to unintentionally delete windows sooo many times, for one.
>

me too.
I want "undo" for sticky menu.

Kenji Arisawa

Re: [9fans] Evolving rio / GUI development

[Sam]

> rog said:
>
>> i think rio can definitely be improved. that "sticky" menu has caused
>> me to unintentionally delete windows sooo many times, for one.
>>
>
> me too.

Me three, due to Hide and Delete being right next to
each other.  Swapping Delete and Resize mitigated this
for me.

I also list hidden windows in the b3 menu in reverse
order so the most recently hidden window is right beneath
Hide.

Triviality, but helpful.

Sam

Re: [9fans] Evolving rio / GUI development

[rog]

> Triviality, but helpful.

actually these kind of details are crucial to a good user interface.

as observed by rob: ``A user interface should not only provide the
necessary functions, it should also *feel* right.  In fact, it should
almost not be felt at all; when one notices a user interface, one is
distracted from the job at hand.''

this is why acme is so deliciously usable - it gets the little things right;
in particular it is not modal, so one can develop "muscle memory"
for the commonly performed tasks.

this can't be said of rio.
actually, i'd quite like to see an implementation of rio with pie
menus. it's just a pity they're so awkward to implement
(and that it's not clear what to do with menus of open-ended size).
anyone out there implemented pie menus in the past?

Re: [9fans] Evolving rio / GUI development

[Russ Cox]

> this can't be said of rio.
> actually, i'd quite like to see an implementation of rio with pie
> menus. it's just a pity they're so awkward to implement
> (and that it's not clear what to do with menus of open-ended size).
> anyone out there implemented pie menus in the past?

i think the right thing to do is eliminate the menus entirely.

on button 2, we have cut, paste, snarf, send, plumb, scroll.
on button 3, we have New, Reshape, Move, Delete, Hide.

if we get rid of the menus, then in a text window we can use
chords for cut, paste, snarf, button 2 for send, button 3 for
plumb.  that leaves scroll.

for window management, Reshape and Move are already
handled via the window border, leaving New, Delete, and Hide.
if there's no b3 menu then a new window can be created
by just dragging out a rectangle with b3 when you start
on grey background.  that leaves Delete and Hide.
the hidden window menu can go on b1.

so scroll, delete, and hide.  if windows had a title bar (heresy!)
like acme's tag lines, then those could go there.

just an idea.  what i'd really like is to be able to move
windows between rio and acme, not just make them look
similar.

russ

Re: [9fans] Evolving rio / GUI development

[g01495]

On Thu, 3 Mar 2005 13:27:30 -0500, Russ Cox <russcox@gmail.com> wrote:
> for window management, Reshape and Move are already
> handled via the window border

i like the reshape functionality -- i prefer it over using the window
borders, i find most of the time i and up both moving and resizing a
window and it's useful to do this in one operation, also i find using
the window borders can sometimes be a bit awkward.

Re: [9fans] Evolving rio / GUI development

[Charles Forsyth]

if i'm just tweaking a window's size or shape, i tend to use the borders.
otherwise i use Reshape, but that could be started a different way.
at the moment, though, i'm stuck in console mode trying to work out which
bit is wrong in the ATI on this A22.  now i know why they gave it
realistic names such as Rage, Fury, etc.

Re: [9fans] Evolving rio / GUI development

[arisawa]

Russ said:

> so scroll, delete, and hide.  if windows had a title bar (heresy!)
> like acme's tag lines, then those could go there.
>

good idea.
I think current menu of rio is residuum of 8 half window of Plan 9
version 2.
If rio has a tag line that is similar to acme, then we can have many
other
things there: label, search, undo,...

Kenji Arisawa

Re: [9fans] Evolving rio / GUI development

[rog]

> just an idea.  what i'd really like is to be able to move
> windows between rio and acme, not just make them look
> similar.

i agree.

i thought about this before and looked into the acme data structures a
bit.  at the moment, you've got multiple Columns, but only one Row. i
didn't go any further into it, but i reckoned it might not be too hard
to make acme multi-window capable, and have one Row for each separate
window that it creates.

then maybe you could drag an acme window onto the rio background and
have it create a new rio window; you could move other windows there
too.

if you enabled graphics-style windows in acme (which i haven't looked
into but rob says isn't hard), then you lose a lot of the need for rio.
in fact you could run acme as your window manager and nest rio
inside a window inside it, and further acme windows inside that.
maybe that's going a bit far :-)

one difficulty i have is when editing code in a deeply nested
directory.  i wonder whether in the above scenario, one might allow a
Row window to have a filename tag; any windows in it would display
relative pathnames if under that directory.

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

>> just an idea.  what i'd really like is to be able to move
>> windows between rio and acme, not just make them look
>> similar.
> 
> i agree.

 I don't.☺

I think rio should be as simple as possible, because it's a solid base
window system for Plan 9, and we need a simple shell running window
system for an emergency.

> to make acme multi-window capable, and have one Row for each separate
> window that it creates.

Mutiple window capable acme?  what for?
I suppose we need multiple windows when we do different things
in that windows, conseqentry I don't need such.    Different works on
different windows, this is simpler.   It's easier and clearer to have multiple 
acmes on a rio window system.☺

> in fact you could run acme as your window manager and nest rio
> inside a window inside it

I also thought this possibility once, but just nest rio inside acme...
However, I now think it's no use.

I may be away from here for a couple of weeks, so my response
to this may delay, sorry.

Kenji

Re: [9fans] Evolving rio / GUI development

[Scott Schwartz]

> anyone out there implemented pie menus in the past?

No, just Don Hopkins. :)

http://www.bx.psu.edu/~schwartz/tkpie.shar.gz

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

TL> how about no new gui
TL> the old one ain't smellin' yet
What you mean in term 'GUI'?
Yes, with large monitors we can forget about window switching, but now
most of Plan 9 programs have only console version! When you want
create application with buttons, entryes, list boxes you need draw it
by self...

RM> With multiple desktops, as much as I like rio, I find it easier to use
RM> flwm and swap around with CTRL-F[1234] etc.
See! People need advanced window manager!

AM> with rio i can sit behind somebody else's terminal and use it without
AM> having to read a 100-page manual on their key bindings, virtual
AM> displays configuration, focus behaviour and menu buttons.
Show at least one GUI which need 100 page manual... most of it have
intuitive interface, and 'rio' too.

--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[boyd, rounin]

> Show at least one GUI which need 100 page manual...

X11
--
MGRS 31U DQ 52572 12604

Re: [9fans] Evolving rio / GUI development

[McLone]

On Thu, 17 Feb 2005 21:17:06 +0100, boyd, rounin <boyd@insultant.net> wrote:
> > Show at least one GUI which need 100 page manual...
> X11
w/o toolkit and WM? You must be kiddin'.
*unuseable*

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[andrey mirtchovski]

> Show at least one GUI which need 100 page manual... most of it have
> intuitive interface, and 'rio' too.

The only "intuitive" interface is the nipple. After that it's all learned.

                                                  -- bruce ediger

Re: [9fans] Evolving rio / GUI development

[g01495]

On Thu, 17 Feb 2005 22:00:20 +0200, Sergey Reva <rs_rlab@mail.ru> wrote:
> TL> how about no new gui
> TL> the old one ain't smellin' yet
> What you mean in term 'GUI'?
> Yes, with large monitors we can forget about window switching, but now
> most of Plan 9 programs have only console version! When you want
> create application with buttons, entryes, list boxes you need draw it
> by self...
>
> RM> With multiple desktops, as much as I like rio, I find it easier to use
> RM> flwm and swap around with CTRL-F[1234] etc.
> See! People need advanced window manager!

Maybe the ability to create a container frame.  The interface could be
similar to ``win'' and Acme, but allowing you to run any type of
application within the frame.  You could create this frame, associate
applications with it, and click within the frame to toggle between the
applications it's managing (which could be any type of application,
graphical, etc).

This could be useful as you could tile your windows initially and
assign applications to each container as required, similar to ``tab''
functionality many UNIX WM's have.

This would increase manageability on displays with many clients.

Re: [9fans] Evolving rio / GUI development

[Rob Pike]

You might want to read the paper I wrote long ago called
"A Concurrent Window System.".  8½ and rio arose from those
ideas, although they sacrificed a lot of the generality.

-rob

Re: [9fans] Evolving rio / GUI development

[McLone]

On Thu, 17 Feb 2005 16:02:33 -0500, Rob Pike <robpike@gmail.com> wrote:
> "A Concurrent Window System.".  8½ and rio arose from those
> ideas, although they sacrificed a lot of the generality.
why WM is in Rio? can they be divided? or we'll got another X?

-- 
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[Russ Cox]

> > "A Concurrent Window System.".  8½ and rio arose from those
> > ideas, although they sacrificed a lot of the generality.
> why WM is in Rio? can they be divided? or we'll got another X?

They already are divided.  Insofar as the analogy holds, rio is the
window manager and /dev/draw is X11.  Graphics can be used without rio:

slay rio | rc
acme

Russ

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

I tried doing rio-in-rio to do multiple desktops but it got clunky fast.

(that's why I was trying to figure out how to do borderless windows and
failing badly :-)


ron

Re: [9fans] Evolving rio / GUI development

[rog]

> (that's why I was trying to figure out how to do borderless windows and
> failing badly :-)

name the window image starting with "noborder".
i don't think this is documented.

Re: [9fans] Evolving rio / GUI development

[geoff]

I use rio-in-rio all the time: use cpu to start a cpu-server window
and run rio in it.  Then each window swept there is automatically
on the cpu server.

A practice that I've found useful to keep track of unhidden windows
is to make sure that each window's upper left corner remains visible
(at least within its innermost rio) even when other windows obscure
portions of the window in question.

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> Yes, with large monitors we can forget about window switching, but now
> most of Plan 9 programs have only console version! When you want
> create application with buttons, entryes, list boxes you need draw it
> by self...

You have libcontrol.
But what I've discovered - after moving to Plan 9 - is that a text-based
user interface is intrinsically more powerful than a mostly grahpic one.
A typescript system is like a user-programmable GUI except you don't
have to program it! Give it a try.

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Tiit,

Friday, February 18, 2005, 2:15:53 PM, you wrote:
TL> You have libcontrol.
ok, how much program you write with it? Where list boxes in this
library? Does it maintained?
TL> But what I've discovered - after moving to Plan 9 - is that a text-based
TL> user interface is intrinsically more powerful than a mostly grahpic one.
TL> A typescript system is like a user-programmable GUI except you don't
TL> have to program it! Give it a try.
In some case yes, and all OS have console, and many user use it
(including me), but gui most intuitive and simples

--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> In some case yes, and all OS have console, and many user use it
> (including me), but gui most intuitive and simples

Console != typescript, not even close.
Think Acme (or Oberon).

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Tiit
Friday, February 18, 2005, 3:18:41 PM, you wrote:
TL> Console != typescript, not even close.
TL>> A typescript system is like a user-programmable GUI except you don't
TL>> have to program it! Give it a try.
Oops! Sorry, not fully understand english, what meaning typescript in
your post?

--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> Oops! Sorry, not fully understand english, what meaning typescript in
> your post?

A typescript system is one, where any text on the screen is just that -
text, and can be edited, etc. At the same time, any text on the screen
is a potential command waiting to be executed. Acme is pretty much a
definition of a typescript system. It has had Oberon (obviously) as one
of its prime inspirations. It is amazing how powerful these things are.

Re: [9fans] Evolving rio / GUI development

[McLone]

On Thu, 17 Feb 2005 07:50:14 +0200, Sergey Reva <rs_rlab@mail.ru> wrote:
> >> Because other more advanced (more friendly to user).
> M> complicated configs != user-friendly
> Most of modern GUI have gui configurator
...which just isn't enought for, say, fvwm2. Yes GUI configurator can
do basic settings, like focus policy etc, but what if you need
"personalized desktop environment from scratch"?

> incompatible GUI's, as result we got manu programs, may be good but
> uses different gui library...
> program): one for KDE, one for Gnome and one which not use this library...
don't forget that only Motif is "full" toolkit; neither Qt nor GTK
can't do X resources IIRC

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[andrey mirtchovski]

with rio i can sit behind somebody else's terminal and use it without
having to read a 100-page manual on their key bindings, virtual
displays configuration, focus behaviour and menu buttons.

rio gives you great functionality.  throwing that away because it
doesn't implement your particular pet-peeve is like cutting the forest
to make more room for fresh air.  (and no, this comment isn't directed
towards ron, he has his own version of rio with virtual displays and
focus-follows-mouse.  that's what happens when you're the ruler of
minions ;)

Re: [9fans] Evolving rio / GUI development

[Steve Simon]

I find I hadly use "rio" at all. The only window I hide is
my vnc session which itself only ever holds IE6 (yea, I know).

I beleive a lot depends upon what resolution you run the display at,
I run at 1080x1024 which is just enough. 1024x768 on my laptop is painfull
Ideally I would run at 1600 odd but my monitor just isn't sharp enough.

High resolution displays are wonderfull and allow you room
to just put things anywhere and still see them, think of the
traditional desktop metaphor - how would you cope with a 3 foot square
desk?

-Steve

Re: [9fans] Evolving rio / GUI development

[andrey mirtchovski]

i rarely manage rio either. i do much more 'managing' of windows
inside acme, where there are some strides made with automatic cursor
placement and windows resize. i suggest you look there for
inspiration.

Re: [9fans] Evolving rio / GUI development

[McLone]

On Wed, 16 Feb 2005 11:37:45 -0700, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
> i do much more 'managing' of windows inside acme, where there are some
> strides made  with automatic cursor placement and windows resize.
Strides? Hmm. For me acme's placement heuristic seems almost natural
and indeed convenient.

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for emgrish

Re: [9fans] Evolving rio / GUI development

[McLone the Great]

On Wed, 16 Feb 2005 11:45:14 -0600, g01495@gmail.com <g01495@gmail.com> wrote:
> I find rio very usable, but I also find I spend alot of my time "using
> rio".  When I say this I mean moving windows, organizing the screen,
> hiding windows, resizing things.
I won't comment rio, used it not so long; but for X window...

17'' all around, at 1152x864 or 1024x768; almost all windows -
fullscreen, so i'm using mostly Ctrl+A because of nested screen(1)s
and Win+A because i bind virtual desks to it. In case of 1280x1024 or
better, i use Alt+Tab etc, so good task-switch-previewer is a must [as
in MacOSX/Aqua]. Personally i dislike window hiding - shading is for
me. Also i found tabbed windows useable [as in fluxbox-stable] on
high-res displays

My X wm's often driven by keys, not mouse. I have bindings in
{open,flux}box or {bad,evil}wm to place windows in a smart way, so
they don't move in a merely weeks.On a mouse i use wheel.
Win32/gnome's/kde's etc. WMs/DEs all unuseable as for me, and i don't
need no taskbars/icons/applets. Think "CUI freak".

> What does everybody else think about this?
to think not in a main[stream] "slab" is a task for chosen one.
Especially when one talks about GUIs.

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for emgrish

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> Where will rio (or it's successors) end up going?
> 
> What does everybody else think about this?

Rio is aimed just to devide the whole window to some smaller ones, 
and multiplex the keyboard/mouse events for the focused window.  
That's all I believe.
There are some other neat things in rio, however, I suppose it's just for
minimum.

Then how to make GUI programs for Plan 9?
I think this is still open to everyone.
Why? probably, rob had no time or got older?☺

We have control library (control(2)), however, I think there is no good
consensus that it's should be the upper level GUI library for Plan 9.
(Sorry Sape, I'm not abusing you. _o_)
Regarding this, look at inferno which has the GUI developed in the same
laboratory, and uses one button GUI interface (Tk) different from that of acme.   
When I saw it first, I thought they probably had no enough time to make 
completely new GUI scheme, however, now, I believe that they believed 
it's enough!   I don't think its enough though...

In short, we have no good agreement regarding what should be the Plan 9 
GUI programming and/or user interface, I believe.

Young and talented programmer can try this, however, it must be painful
and brain consuming thing I think.   First of all, they have to forget any
existing GUI scheme.☺

Please correct me if I'm wrong.

Kenji

Re: [9fans] writing code

[Skip Tavakkolian]

>> i think it's realistic.  a boot cd would get you the same access.
>> if you get physical machine access, you win.  typing a password
>> to authenticate to the local system gives you the feeling of
>> security, not actual security.
>
> yes, if I get physical acccess, I win. I'll just tear the thing to bits
> and boot it with an ICE :-) I don't even care if I mark up the pretty
> plastic.
>

Possession is 9/10th of security.  The boot cd is the other 1/10th.

Re: [9fans] writing code

[andrey mirtchovski]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]


NOTE: i originally sent this message (successfuly, according to
plan9.ucalgary's mail server) but since it took so long i'll just
assume some filter decided fcp.c was spam.  i've gzipped it now.
sorry if you get double copies.

andrey

--- original message follows ---

> if you want to experiment, i've attached a version of the Inferno
> cp(1) called "streamcp" that uses this technique to try to speed up
> file transfer; it allows you to specify the number of concurrent reads
> and writes.

attached is the same idea for plan9, done by Aki Nyrhinen (with a
little help from me integrating it with the official plan9 cp).  it
speeds up copy from sources up to tenfold in some occasions.  has
reasonable speed locally.

i heard ioproc is even faster.

% time cp /n/sources/extra/sun.tgz /dev/null
0.00u 0.02s 19.91r   cp /n/sources/extra/sun.tgz /dev/null
% time cp /n/sources/extra/sun.tgz /dev/null
0.00u 0.03s 20.35r   cp /n/sources/extra/sun.tgz /dev/null
% time cp /n/sources/extra/sun.tgz /dev/null
0.00u 0.03s 19.93r   cp /n/sources/extra/sun.tgz /dev/null


% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.01s 4.36r    fcp /n/sources/extra/sun.tgz /dev/null
% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.00s 5.31r    fcp /n/sources/extra/sun.tgz /dev/null
% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.04s 5.36r    fcp /n/sources/extra/sun.tgz /dev/null

[-- Attachment #2: fcp.c.gz --]
[-- Type: application/octet-stream, Size: 1482 bytes --]

Re: [9fans] writing code

[rog]

> attached is the same idea for plan9, done by Aki Nyrhinen (with a
> little help from me integrating it with the official plan9 cp).  it
> speeds up copy from sources up to tenfold in some occasions.  has
> reasonable speed locally.

have you compared the speed against raw TCP?

Re: [9fans] writing code

[andrey mirtchovski]

> have you compared the speed against raw TCP?

this may sound silly, but the only way i could find to compare against
raw tcp is via hget:

% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.01s 2.90r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.02s 4.16r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.01u 0.02s 4.07r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.00s 2.83r 	 fcp /n/sources/extra/sun.tgz /dev/null


% time hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz > /dev/null
0.01u 0.00s 2.49r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.00u 0.00s 2.43r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.00u 0.01s 3.14r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.01u 0.02s 2.34r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz

short of writing something small, of course :)

Re: [9fans] writing code

[rog]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

i tried it myself:

% for(i in 1 2 3 4){
	time fcp sun.tgz /dev/null
	time cp sun.tgz /dev/null
	time hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz  > /dev/null
}
0.00u 0.01s 12.09r 	 fcp sun.tgz /dev/null
0.00u 0.03s 30.37r 	 cp sun.tgz /dev/null
0.03u 0.11s 11.93r 	 hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz
0.00u 0.04s 12.16r 	 fcp sun.tgz /dev/null
0.00u 0.00s 30.32r 	 cp sun.tgz /dev/null
0.01u 0.06s 10.16r 	 hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz
0.00u 0.04s 12.46r 	 fcp sun.tgz /dev/null
0.00u 0.01s 30.24r 	 cp sun.tgz /dev/null
0.08u 0.02s 9.71r 	 hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz
0.00u 0.01s 11.86r 	 fcp sun.tgz /dev/null
0.00u 0.03s 30.10r 	 cp sun.tgz /dev/null
0.05u 0.07s 9.93r 	 hget http://plan9.bell-labs.com/magic/9down4e/compressed/1108754619.nm555mqv7uc7rvvyye52p4zcaeeziq2d/sun.tgz

overhead was averaging about 15% there.
it seems it isn't nearly as bad as i remember, which is good!

BTW, there's a bug in fcp; you need to malloc the
buffer separately inside each thread, otherwise
you get data corruption.

[-- Attachment #2: Type: message/rfc822, Size: 3024 bytes --]

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] writing code
Date: Fri, 18 Feb 2005 11:53:09 -0700
Message-ID: <0f57322cacb80f7c319565aeb7cfae61@plan9.ucalgary.ca>

> have you compared the speed against raw TCP?

this may sound silly, but the only way i could find to compare against
raw tcp is via hget:

% time fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.01s 2.90r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.02s 4.16r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.01u 0.02s 4.07r 	 fcp /n/sources/extra/sun.tgz /dev/null
0.00u 0.00s 2.83r 	 fcp /n/sources/extra/sun.tgz /dev/null


% time hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz > /dev/null
0.01u 0.00s 2.49r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.00u 0.00s 2.43r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.00u 0.01s 3.14r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz
0.01u 0.02s 2.34r 	 hget http://204.178.31.2/magic/9down4e/compressed/1108752459/sun.tgz

short of writing something small, of course :)

Re: [9fans] writing code

[Charles Forsyth]

>>BTW, there's a bug in fcp; you need to malloc the
>>buffer separately inside each thread, otherwise
>>you get data corruption.

i think it was Cray that observed (about fp) ``you can get the right answer, or the quick answer''

Re: [9fans] writing code

[andrey mirtchovski]

> BTW, there's a bug in fcp; you need to malloc the
> buffer separately inside each thread, otherwise
> you get data corruption.

you got old version of the code, sorry.

Re: [9fans] writing code

[Roland Dowdeswell]

Around Fri Feb 18 14:34:48 EST 2005, Tim Newsham wrote:
> To prevent this you either need to prevent someone from booting
> (ie. bios password and hope they dont go through the trouble
> of yanking the drive or resetting the bios) or you need to
> protect the disk (after all thats probably what they want to
> get at after they log in, not network access or the gui).
> Something like:
>
>	http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
>
> would address this nicely.  For those who don't want to chase
> down the paper, it's an encrypted disk format used by the
> FreeBSD group.

You might also consider CGD [which I wrote].  GBDE has a number of
serious drawbacks, namely:

	1.  it can lose sectors if the machine crashes in the ``middle''
	    of a write to a single sector,
	2.  it is quite slow,
	3.  it makes no attempt to frustrate dictionary attacks, and
	4.  the crypto is a little dubious [and brittle].

Thanks,

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/