> 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
> 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
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
highe
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
> 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
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 larg
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 l
> 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
>> 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 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
> togeth
>> 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
On Fri, Apr 17, 2009 at 2:59 PM, Eris Discordia
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 of specialization
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 "terminal
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 mach
> 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 m
> 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".
Wh
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 n
>> 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 t
> 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 roa
> 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
>
> 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
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,
> 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 (o
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
> 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
25 matches
Mail list logo
