Adrian van den Heever wrote:
No we aren't involved in that - an interesting looking device though.
We have moved on quite a bit since we last spoke - we have a USB product in volume manfacture in conjunction with a USA based laptop peripheral manufacturer - take a look at the news section on our website.
-- Adrian van den Heever
From: Henry Keultjes [mailto:hbkeultjes@xxxxxxxxxxxxx] Sent: 01 June 2006 14:28
To: Adrian van den Heever
Subject: Small Box 'To End Digital Divide
Are you and/or your company involved in this http://news.zdnet.co.uk/0,39020330,39272166,00.htm ?
Henry Keultjes Database Scientifics Project http://www.ncolug.org/ppc.htm Microdyne Company Mansfield Ohio USA Voice 419-525-1111 Home 419-756-0527
Please note that my business line and cell phone number are now the same 419-525-1111 but to reach me early or late in the day, the home number 419-756-0527 is still best.
-------- Original Message --------
Subject: Small Box 'To End Digital Divide'
Date: Wed, 04 May 2005 21:28:47 -0400
From: Henry Keultjes <hbkeultjes@xxxxxxxxxxxxx>
Organization: Henry Keultjes Home
To: Adrian van den Heever
Thanks for your quick response. Forgot to mention something that could
be significant in terms of IP. In 1993 or thereabouts I acquired a
license from Cumulus for their Unix implementation of AlphaWindows
http://www.cs.utk.edu/~shuford/terminal/alphawindows_news.txt for the
purpose of porting that to *native* Pick and thus GUIizing Pick. In
case you are not familiar with Pick, it is an exo-kernel like
multi-dimensional RDBMS (mdRDBMS) meaning that it has its own operating
systems *functions* in the form of loadable device drivers and such. Starting in about 1986, most Pick activity has been with ported versions
like IBM's UniVerse and UniData , UK based jBase, UniVision and Reality
and what is the successor to Pick Systems, Raining Data's D3 because
keeping up with device drivers and such was very hard and very expensive
in that era. The Open Source scene changed all that and led me back to
my mothballed project because most of the pieces my project needs are
already in the open Source domain, includingOpenQM, an Open Source
mdRDBMS that is also being spearheaded by a UK based development team.
The Cumulus "monitor" works pretty much the way the nextgen Nivo has
been described, the Thin Client functionality is part of the terminal. When Cumulus went bankrupt I mothballed the monitor and the diskettes. Should that ever interest you to examine the working of the hardware and
the software, I will be glad to share. As I mentioned in another email,
I am not looking to make money by doing this, I am only hoping to make
it easier for your project to succeed because it looks like it is
exactly what I have been looking for to best use the software that I
want to further develop.
If you read all the way to the end of the "Perfect Pair . . " artricle
of the http://www.ncolug.org/ppc.htm link, you read that I am still
trying to develop this new Native Pick, something that is not easy for
me because I am not a programmer and I depend on others to put my ideas
to code. When I actively ran the chair company I could dictate what
programmers did. Now I either have to pay them out of my own pocket or
I depend on them having this same vision of this new "Native Pick" becoming the db-centric applications platform of the future, something
that would compete with the eventual db-centric version of Longhorn. Unlike Longhorn, EKP (Exo-Kernel Pick) would not have a flat file but a
multi-dimensional file system and. because it would be so much more
compact, it would be so much faster, especially if it uses the 64-bit
PowerPC instruction set with the Altivec and, as descibed in my original
email, can be developed to not use a graphics card and use much simpler
communications between the server and the monitor, as long as the
monitor is strictly digital. Being strictly digital would also reduce
the cost of the monitor. I have been using an ADI 12-v monitor with a
brick which I see as being able to do dual use by also powering the Nivo
before it becomes an integral part of the monitor.
Now to some specifics of your reply:
You said "Unfortunately, our implementation is a key part of our IP portfolio, so Icannot divulge any more detail." Reply: Understood
You said "Our system and its implementation is intended to be OS agnostic" Reply: Exo-kernal type functionality derived from Open Source like Linux, Darwin and FreeBSD would fit much better with your concept than the "throw in everything, including the kitchen sink, that is one of the major reasons that TCO is out of hand. In a way, that is just as OS agnostic because that should work for the application that runs on the server.
I have some pretty good contacts at IBM and I believe that they could be a great deal of help in developing the SoC version that would fit inside the monitor and, as you probably know, IBM is one of the major LG/Philips LCD screen customers. Another potential source of help could be Samsung, also one of the major LCD players and also a PowerPC licensee. However, some of the things that IBM is doing with Sony and Toshiba and, ironically, Microsoft, mostly game console related, are driving the cost of SoC implementation down very rapidly. The new XBox for example will have a three dual 970 SoC implementation. Check the rumor mills and the stock market folks where that XBox will be priced and you will find that at this point nothing can compete in cost with that kind of horsepower. My guess is that, given a justifiable quantity, that a 970 SoC implementation for the Nivo could be bought for about ten bucks.
One last thing. For the last two years I have shown PowerPC and Linux stuff at the Ohio Linux Fest. This years event will be on 01OCT2005 and being able to show Nivo as a client on OpenQM running on PowerPC
would be awesome.
Adrian van den Heever wrote:
As I grew up in South Africa, it might have been Adriaan - however it really is Adrian - that's what my birth certificate says.
I'm glad that you are such an avid fan of the 'small box' concept
We are too!
While considering how to develop this product, we evaluated a number of
potential solution platforms - all of which were inadequate in some way
- too much power required, too expensive, not enough processing poweretc...
Unfortunately, our implementation is a key part of our IP portfolio, so
I cannot divulge any more detail.
Our system and its implementation is intended to be OS agnostic and to be limited in the scope of application only by the imagination of our technology and implementation partners.
Hopefully, in the not too distant future, we will be in a position to make more detail available about our product, the technology used and our partners.
Groetjes! Did I assume correctly that it is Adriaan and not Adrian?
The Netherlands Netwerk holds a Koneginneday celebration in the Cleveland area every year but we missed yesterday because my wife had to be at a magistrate's seminar.
First off, I love that "Small Box"concept even better than the Mac-Mini and if you read http://www.ncolug.org/ppc.htm you will know why.
Anyway, being an avid PowerPC evangelist, I wonder if your goals could
not be accomplished better by using PowerPC SoC technology or similar.
While the article did not state what chip you are using, you could well be using PowerPC or ARM. However, from our standpoint of porting
the mdRDBMS (multi-diemsnional RDBMS) platform to that Thin Client, anything but PowerPC would make that job very difficult because we rely heavily on the PowerPC instruction set to create an upgrade path to the Mac and any of the IBM PowerPC servers, including the most powerful commercial server in the world, the IBM zSeries.
BTW, we has this Thin Client platform in the mdRDBMS arena as far back
as 1982. I am a museum type collector of sorts and have two versions
of the client box that turned an ordinary IBM PC of that era into a client on the multi-user system. The main objective was to reduce the processor interrups that occurred as each character was echoed
from the dumb terminal to the server and back so it could appear as a
character on the screen. The Teleport, as it was called, client allowed keystrokes to accrue on the PC and interrupt only as a screen,
like an invoice, was complete making an 8-12 mHz system capable of running as many as 512 *simultaneous* users.
Googling for Newnham Research braught up this link <http://www.cambridgenetwork.co.uk/pooled/profiles/BF
COMP/view.asp?Q=BF COMP 21534> Newnham Research Ltd ... Newnham Research Ltd. Profile, Job. Newnham Research is developing new and powerful ways of connecting monitors and computers together, making it
While I am not a techy, I tend to have a good understanding of how computer things work without clouding that knowledge with details.
Going by my experience as an mdRDBM architect and business owner/user,
I believe that the dynamic array that "holds" our applications could be *digitally* translated or "twinned" to the screen in a strictly digital 16:9 digital screen aplication. That, I believe, could lead to transmitting the protocol and data over Cat-5/6 wire, just like we transmitted the old style data over RS-232, rather than using the high
voltage cable that is now the common connector between the PC and the monitor.
I am also a big fan of the 16:9 aspect ratio because it is more natural for applications to have a "constant data" column on the left
and the rest of the screen, top to bottom for the application. Using
a PowerPC processor, we could easily let applications that so required
use the whole screen width. I have had some contact in the past with the Philips/LG coordinator, a Dutchman who is stationed in Korea., about this aspect ratio. He personally believes it the right idea and
they have made a lot of the Mac screens that way but sofar the rest of
the industry is still lagging behind. However, ultimately the 16:9 aspect ratio monitor will tend to be cheaper because the greatest glass area will be devoted to HDTV that has the 16:9 aspect ratio.
I look forward to your comments.
Mansfield Ohio USA
Home 419-756-0527 - anytime before 10:00 or after 18:00 UTC Cell 419-525-1111