headers
Alan Horkan | 31 Mar 2006 01:26
Picon
Picon
Favicon

Re: Servers


On Thu, 30 Mar 2006, Stephen J. Smoogen wrote:

> [I will admit I do not know much about the newer 'mesh' technologies
> so this may be mute.]

I think you meant "moot", as in moot point as opposed to a person who is
unable to speak.

--

-- 
Alan H.

P.S. Apologies in advance if English is not your first language.  My own
understanding of other languages is not as good as I would like it to be.

--
olpc-software mailing list
olpc-software <at> redhat.com
https://www.redhat.com/mailman/listinfo/olpc-software
Permalink | Reply | 0 comments |
headers
Jim Gettys | 31 Mar 2006 04:33
Favicon
Gravatar

Re: Servers

Depends where you are.  You are certainly correct that in many parts of
the world, building codes are very different.  

But in hot desert areas, you often get very thick walled adobe or
masonry construction.

Even so, the expense of the cable becomes considerable.
                            - Jim

On Thu, 2006-03-30 at 13:05 -0600, Dean Johnson wrote:
> Jim Gettys wrote:
> > 
> > And one per class room implies pulling cable to nearly every classroom;
> > I know that has been a big problem even in the school my own children
> > attend here in the Boston area, and a serious expense.
> > 
> 
> It could be really really easy. Many of the schools that I have seen in the 
> non-first world, particularly in tropical areas, are very open floor plans and 
> don't suffer from the restrictions of building codes.
> 
> 	-Dean
> 
> --
> olpc-software mailing list
> olpc-software <at> redhat.com
> https://www.redhat.com/mailman/listinfo/olpc-software
--

-- 
Jim Gettys
One Laptop Per Child
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ivan Krstic | 31 Mar 2006 05:40
Picon

Re: Servers

Jim Gettys wrote:
> Most commodity access points don't work well with large numbers of
> clients; their design center is a house with a few users. Identifying
> pretty cheap, access points that don't have this problem would be good
> to do.

Right. On the OLPC scale, though, management and logistics cost of the
access points become serious factors to consider.

> The laptops, even used as an access point, will function much better
> than the typical cheap access points you buy in a store.

And there are various approaches to take here. One laptop won't be able
to serve as an AP to a thousand others if we enact the standard,
fully-centralized AP model. But there's a lot of research[0] that deals
with data querying and routing in mesh networks; we could likely turn
some of it inside out to provide a laptop AP mode that scales to large
numbers of clients. We can't match the level of service provided by
high-powered dedicated AP hardware, but we can make things work.

[0] e.g. Zhao, Liu, Lui, Guibas and Reich (2003) or Chu, Haussecker,
Zhao (2002)

--

-- 
Ivan Krstic <krstic <at> fas.harvard.edu> | GPG: 0x147C722D

--
olpc-software mailing list
olpc-software <at> redhat.com
https://www.redhat.com/mailman/listinfo/olpc-software
(Continue reading)

Permalink | Reply | 1 comment |
headers
Krzysztof Kowalczyk | 31 Mar 2006 13:05
Picon
Gravatar

Re: AbiWord, HIG

> Andy Herzfeld (the early Mac designer, then etc., now at Google) did several terrific UIs along these
lines about 10-15 years ago (one for General Magic and the other for Frog Designs).

Not everyone thinks that the approach of trying to duplicate physical
methaphors in UI is such a great idea:
http://www.cooper.com/articles/art_myth_of_metaphor.htm

I tend to agree with Alan Cooper on that.

Incidentally, General Magic was a spectacular failure. Wheter it was
because their UI was weak or despite the fact that their UI was great
- I don't know (I would like to know what Andy thinks about Magic Cap
UI today)

I do know that the only succesful PDA (Palm Pilot) didn't use "force
physical methapors in UI" but rather is designed to accomodate
weaknesses and strengths of hardware. If you read/listen to what Jeff
Hawkins and other key designers of Palm say, that was a conscious
decision (and it doesn't look like Hawkins thought that Magic Cap was
a good idea: http://www.pencomputing.com/palm/palmnews/palmnews-11-14-01.html)

I also know that Andy Rubin after working on Magic Cap started Danger,
Inc. and the Sidekick OS (which is quite beautiful design, at least
technically) that Danger did looks much more like Palm OS than Magic
Cap. It's also tightly optimized for the hardware they designed.

Of course, there are people who think that Magic Cap was the best
thing ever: http://multipart-mixed.textdriven.com/magiccap/magic_cap_developer_docs.html

Which does show that there's actually little consensus about what is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Krzysztof Kowalczyk | 31 Mar 2006 14:13
Picon
Gravatar

Re: graceful handling of out-of-memory conditions

Relating to OOM discusion.

The way Pocket PC is trying to solve this problem is:
* there's a configurable setting that represents a free memory
threshold that OS considers to be "dangerously low". Usually it's set
to 2 MB
* when the amount of free memory falls below this threshold the OS
sends WM_HIBERNATE to all apps which means "please free up as much
memory as you can"
* if apps don't free up any memory, the OS does the OOM thing by
sending WM_CLOSE to background apps (it's the "please kill yourself"
message)
* if apps don't cooperate with WM_CLOSE, it shows a UI listing all
apps and asks the user to choose the one to kill

This complexity is a byproduct of a design decisions Microsoft made:
* the OS is multi-tasking so there can be multiple apps running at the same time
* closing the app (from user point of view) doesn't cause the process
to exit, it just gets put into background. this improves responsivness
when the user "launches" the app again but will eventually fill up all
the memory.

Palm OS or Amiga OS don't have any OOM handling. The apps are supposed
to handle malloc() failures properly or they die (sometimes taking the
OS with them).

While I agree with Havoc that handling malloc() failures takes more
code and is harder than ignoring failures and crashing, I disagree
with the conclusion that it's imposible to do or that it adds 30% of
exe size (exaggeration).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ivan Krstic | 31 Mar 2006 14:27
Picon

Re: graceful handling of out-of-memory conditions

Krzysztof Kowalczyk wrote:
> Linux stack consists of millions of lines of C code written with 
> desktop pc in mind, targeting specs of at least 1 GHz processor, 0.5
> GB of RAM, gigabytes of hard-drive, and high-resolution screens.

A reasonably snappy blackbox running on a 400 Mhz PII with 64MB RAM
disagrees.

> And the same time it lacks some of the things that proved to be useful
> like good IPC mechanizm or system-wide, standard scripting language
> that can be used to both script the apps and as a high-level language
> for writing large class of apps

Python is getting there, and there's lots of work being done on taking
it even further in that direction.

> No matter how hard you try, you're not going to do a good job at
> scaling this stack down to a reasonable size and it will still lack
> the good features.

I disagree; take a look at what Nokia has done with Maemo on the 770.

To take a step back, though, the OOM discussion seems unnecessarily
complicated to me. While solving the problem "correctly" requires
significant engineering work, I'm not sure the OLPC timeline tolerates a
correct solution; a pragmatic one, if it got us 80% of the way there,
would do just fine.

We have pragmatic solutions available: polling the available amount of
RAM, or passing a notification from the kernel when available RAM drops
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Kay | 31 Mar 2006 16:06

Re: AbiWord, HIG

Hi --

At 03:05 AM 3/31/2006, Krzysztof Kowalczyk wrote:
> > Andy Herzfeld (the early Mac designer, then etc., now at Google) did 
> several terrific UIs along these lines about 10-15 years ago (one for 
> General Magic and the other for Frog Designs).
>
>Not everyone thinks that the approach of trying to duplicate physical
>methaphors in UI is such a great idea:
>http://www.cooper.com/articles/art_myth_of_metaphor.htm

There are few topics in this world that don't have opinions on every side, 
so "just opinions" don't help resolve much.

>I tend to agree with Alan Cooper on that.

Check out my (quite) earlier chapter in The Art of Human-Computer Interface 
Design (Ed. B. Laurel) from 1990, on just that topic, and you will see that 
I agree also. So why do I like what Andy did? Especially for Frog?

>Incidentally, General Magic was a spectacular failure. Wheter it was
>because their UI was weak or despite the fact that their UI was great
>- I don't know (I would like to know what Andy thinks about Magic Cap
>UI today)

This seems to be a tangent and doesn't help resolve the question.

>I do know that the only succesful PDA (Palm Pilot) didn't use "force
>physical methapors in UI" but rather is designed to accomodate
>weaknesses and strengths of hardware. If you read/listen to what Jeff
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Zeuthen | 31 Mar 2006 18:01
Picon
Favicon

Re: graceful handling of out-of-memory conditions


Hi,

On Fri, 2006-03-31 at 04:13 -0800, Krzysztof Kowalczyk wrote:
> I know for a fact that Exchange Server or SQL Server won't crash just
> because some malloc() failed so open-source developers on projects
> 1/10th of the size should be able to do it as well. Given enough
> eyeballs and all that. For example, sqlite and cairo do the right
> thing.

Handling OOM would break lots of library API. Not to mention that
upstream probably wouldn't take it.

> To go on a tangent: to me the "how to handle OOM in kernel" discussion
> just shows that Linux (in the broad sense of Linux Kernel + X +
> standard Linux libraries and apps) is wildly inappropriate technical
> choice for OLAP.

The other OOM thread on this list concluded we can restrict OOM handling
to user apps running and not taking down the UI shell. Do you disagree?

Sure, we can add lots of (silly) UI asking what user app to kill like in
the Windows CE example I snipped. Some research on what user experience
we want will tell us what to do. I'm interested in this but it's not
really my area of expertise.

Look at it this way: We also don't need to put the software developer
into the pain of having to handle OOM; surely, as an individual written
many many lines of code myself (some having to handle OOM) I can attest
to the fact that it's annoying have to care whether malloc fails.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dean Johnson | 31 Mar 2006 19:12

Re: AbiWord, HIG

Alan Kay wrote:
> 
> The idea and importance of "knowing your field" is pretty simple stuff, 
> well known in every developed profession and art -- and this is 
> certainly the case in the physics of the HW. Why should it be so 
> controversial and avoided in the software side of computing, to the 
> detriment of all?

Its different because humanoids are quite quirky beasts and there are very few 
things that are "right" in the UI world. Part of the issue is that users 
typically attempt to truly minimize their knowledge to satisfy their needs as a 
tool user. Consequently their knowledge and usage grows rather organically and 
rather than best practices, they hammer at the square peg and eventually get it 
into the round hole. Eventually their quirks get codified and you get things 
like vi-mode in emacs.

When you look around at recent computer history, one could suggest that the WIMP 
interface was revolutionary for the computer industry. It is pretty much 
ubiquitous for desktop systems and could be considered "right", especially given 
its usage as a foundation for lots of academic UI mutterings. However, what 
could be dumber than a mouse that requires you to take your hands off the 
keyboard to use? Clearly that can't be right. You wouldn't expect the driver of 
a car to move over to the passenger seat to shift, so why is a mouse "right"? 
Would not a court reporter type keyboard interface (pressing many keys 
simultaneously) be more "right" than a mouse? Okay, you have that in emacs, but 
the point remains.

BTW, very few developed professions and arts have a well developed true sense of 
"knowing your field". The people most likely to "know their field" have narrowed 
down the definition of 'field' to fit in one human head. Look at biology,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jecel Assumpcao Jr | 31 Mar 2006 19:39
Favicon
Gravatar

new os (was: graceful handling of out-of-memory conditions)

David Zeuthen wrote on Fri, 31 Mar 2006 11:01:30 -0500
> On Fri, 2006-03-31 at 04:13 -0800, Krzysztof Kowalczyk wrote:
> > Even Lisp Machine, 
> 
> Oh my. And, btw, is the source available?

Ask, and you shall receive ;-)

http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html

> > Any of those systems seems like a better choice for OLAP than Linux
> > system. Or a system designed and implemented from scratch, that uses
> > the good things that can be learned from those systems (and Linux, if
> > there really is anything to learn from it other than  given a chance
> > to redo things, you would probably want to do everything differently).

There are very good reasons for OLPC to use Linux, but I don't think
these two options are mutually exclusive. So much so that I am doing my
own OS for a kid's computer. It would be just as unreasonable to ask the
Fedora people to give up on Linux to work on something different (HURD?
;-) as to ask me to give up on Neo Smalltalk (previously Self/R and
Merlin OS before that) to help fix Linux. Why not try both alternatives
at the same time and see what result is best?

> Can I suggest 
> 
>  - Getting up to speed on the core technologies we plan to include 
>    for OLPC and review these

Indeed, though I have been using Linux since 1994 and keeping track of
(Continue reading)

Permalink | Reply | 0 comments |

Gmane