On Jan 25, 2010, at 12:28 PM, Ethan Grammatikidis
eeke...@fastmail.fm wrote:
On 8 Jan 2010, at 7:12 am, Jeff Sickel wrote:
there's not a single searchable
site that provides a quick reference release that would give us
inroads
to all the /other/ operating systems available these
The digital group was in Adelaide. Shand worked for them and Mudge was
the honcho. Does that help? I'm still in contact with Shand - he
visited last month.
I'll give it a try.
brucee
On 1/8/10, Jeff Sickel j...@corpus-callosum.com wrote:
No, I'm not suggesting VAX/VMS on this channel::
No, I'm not suggesting VAX/VMS on this channel::
Though I really enjoyed working on VAX Forth-sim/VMS so way-
back that the wayback machine at web.archive.org can't find it.
If brucee could track down the creator in Australia I'd be
much obliged. He worked for DEC
what could we do today, but don't quite dare?
a Blue Ray writer does 50Gb per disk (we're supposed to be getting one
soon, so maybe I can report back about this later)
ArcVault SCSI autoloading tape drives do from 9.6tb - 76tb
what could we do today, but don't quite dare?
a Blue Ray writer does 50Gb per disk (we're supposed to be getting one
soon, so maybe I can report back about this later)
ArcVault SCSI autoloading tape drives do from 9.6tb - 76tb
erik quanstrom wrote:
what could we do today, but don't quite dare?
a Blue Ray writer does 50Gb per disk (we're supposed to be getting one
soon, so maybe I can report back about this later)
ArcVault SCSI autoloading tape drives do from 9.6tb - 76tb
2009/4/20 erik quanstrom quans...@quanstro.net:
i'm not following along. what would be the application?
Jukebox, perhaps?
- erik
The seesion would not be suspended, it would continue to operate as
your agent and identity and, typically, accept mail on your behalf,
perform background operations such as pay your accounts and in
general represent you to the web to the extent that security (or lack
thereof, for many
people's ideas about what's complicated or hard don't change
as quickly as computing power and storage has increased. i
think there's currently a failure of imagination, at least on
my part. there must be problems that aren't considered
because they were hard.
as an old example, i think
On Fri Apr 17 16:22:55 EDT 2009, blstu...@bellsouth.net wrote:
I often tell my students that every cycle used by overhead
(kernel, UI, etc) is a cycle taken away from doing the work
of applications. I'd much rather have my DNA sequencing
application finish in 25 days instead of 30 than to
On Sat, Apr 18, 2009 at 10:54:34AM -0400, erik quanstrom wrote:
as an old example, i think that the lab's use of worm storage
for the main file server was incredibly insightful.
what could we do today, but don't quite dare?
stop writing all programs in C, and start writing them in a
Actually, I have long had a feeling that there is a convergence of
VNC, Drawterm, Inferno and the many virtualising tools (VMware, Xen,
Lguest, etc.), but it's one of these intuition things that I cannot
turn into anything concrete.
This brings to mind something that's been rolling around
in
On Fri, Apr 17, 2009 at 11:32:33AM -0500, blstu...@bellsouth.net wrote:
- First, the gap between the computational power at the
terminal and the computational power in the machine room
has shrunk to the point where it might no longer be significant.
It may be worth rethinking the separation of
In some sense, logically (but not efficiently: read the caveats in the
Plan9 papers; a processor is nothing without tightly coupled memory, so
memory is not a remote pool sharable---Mach!),
if you look closely enough, this kind of breaks down. numa
machines are pretty popular these days
On Fri, Apr 17, 2009 at 01:29:09PM -0400, erik quanstrom wrote:
In some sense, logically (but not efficiently: read the caveats in the
Plan9 papers; a processor is nothing without tightly coupled memory, so
memory is not a remote pool sharable---Mach!),
if you look closely enough, this
The definition of a terminal has changed. In Unix, the graphical
In the broader sense of terminal, I don't disagree. I was
being somewhat clumsy in talking about terminals in
the Plan 9 sense of the processing power local to my
fingers.
A terminal is not a no-processing capabilities (a dumb
Absolutly, but part of what has changed over the past 20
years is that the rate at which this local processing power
has grown has been faster than rate at which the processing
power of the rack-mount box in the machine room has
grown (large clusters not withstanding, that is). So the
gap
if you look closely enough, this kind of breaks down. numa
machines are pretty popular these days (opteron, intel qpi-based
processors). it's possible with a modest loss of performance to
share memory across processors and not worry about it.
Way back in the dim times when hypercubes roamed
Absolutly, but part of what has changed over the past 20
years is that the rate at which this local processing power
has grown has been faster than rate at which the processing
power of the rack-mount box in the machine room has
grown (large clusters not withstanding, that is). So the
gap
On Fri Apr 17 14:21:03 EDT 2009, tlaro...@polynum.com wrote:
On Fri, Apr 17, 2009 at 01:29:09PM -0400, erik quanstrom wrote:
In some sense, logically (but not efficiently: read the caveats in the
Plan9 papers; a processor is nothing without tightly coupled memory, so
memory is not a
But the question in my mind for a while
has been, is it time for another step back and rethinking
the big picture?
Maybe, and maybe what we ought to look at is precisely what Plan 9
skipped, with good reason, in its infancy: distributed core
resources or the platform as a filesystem.
What
I often tell my students that every cycle used by overhead
(kernel, UI, etc) is a cycle taken away from doing the work
of applications. I'd much rather have my DNA sequencing
application finish in 25 days instead of 30 than to have
the system look pretty during those 30 days.
i didn't mean
On Fri, Apr 17, 2009 at 01:31:12PM -0500, blstu...@bellsouth.net wrote:
Absolutly, but part of what has changed over the past 20
years is that the rate at which this local processing power
has grown has been faster than rate at which the processing
power of the rack-mount box in the machine
even today on an average computer one has this articulation: a CPU (with
a FPU perhaps) ; tightly or loosely connected storage (?ATA or SAN) ;
graphical capacities (terminal) : GPU.
It happens so that a reversal of specialization has really taken place, as
Brian Stuart suggests. These
On Fri, Apr 17, 2009 at 2:59 PM, Eris Discordia
eris.discor...@gmail.com wrote:
even today on an average computer one has this articulation: a CPU (with
a FPU perhaps) ; tightly or loosely connected storage (?ATA or SAN) ;
graphical capacities (terminal) : GPU.
It happens so that a reversal
I often tell my students that every cycle used by overhead
(kernel, UI, etc) is a cycle taken away from doing the work
of applications. I'd much rather have my DNA sequencing
application finish in 25 days instead of 30 than to have
the system look pretty during those 30 days.
i didn't
What struck me when first looking at Xen, long after I had decided
that there was real merit in VMware, was that it allowed migration as
well as checkpoint/restarting of guest OS images with the smallest
...
The way I see it, we would progress from conventional utilities strung
together
Absolutly, but part of what has changed over the past 20
years is that the rate at which this local processing power
has grown has been faster than rate at which the processing
power of the rack-mount box in the machine room has
grown (large clusters not withstanding, that is). So the
gap
I'd like to add to Brian Stuart's comments the point that previous
specialization of various boxes is mostly disappearing. At some point in
near future all boxes may contain identical or very similar powerful
hardware--even probably all integrated into one black box. So cheap that
The
On Fri, Apr 17, 2009 at 04:25:40PM -0500, blstu...@bellsouth.net wrote:
Again, that's not to say that there aren't other valid motivators
for some centralized functionality. It's just that in my opinion,
we're at the point were if it's raw cycles we need, we'll have
to be looking at a large
On Fri, Apr 17, 2009 at 04:25:40PM -0500, blstu...@bellsouth.net wrote:
Again, that's not to say that there aren't other valid motivators
for some centralized functionality. It's just that in my opinion,
we're at the point were if it's raw cycles we need, we'll have
to be looking at a large
I guess I'm a little slow; it's taken me a little while to get
my head around this and understand it. Let me see if I've
got the right picture. When I login I basically look up a
previously saved session in much the same way that LISP
systems would save a whole environment. Then when I
32 matches
Mail list logo
