From jbone at place.org Mon Dec 14 05:03:18 2009 From: jbone at place.org (Jeff Bone) Date: Mon, 14 Dec 2009 07:03:18 -0600 Subject: [FoRK] A story of (years of) productive frustration in software development Message-ID: <55C99150-DEA1-4020-8D58-A6CAF0A32329@place.org> Excellent stuff... William Stein's personal story of how Sage came to be, entitled "Mathematical Software and Me: a Very Personal Recollection" http://wstein.org/mathsoftbio/history.pdf Recommended. jb From jbone at place.org Mon Dec 14 05:24:41 2009 From: jbone at place.org (Jeff Bone) Date: Mon, 14 Dec 2009 07:24:41 -0600 Subject: [FoRK] taxonomy of composition and coordination (thinking out loud...) Message-ID: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> Dr. Ernie asks: > Where would you put tools like ssh, Capistrano, and other flavors of > remote shell / configuration? They would likely fit somewhere between the first and second entries in that taxonomy. (I.e., showing its incompleteness.) Pipes in general, when extended over the network, show the weakness of making networks transparent. (Try pumping a lot of data over an ssh connection at close to line speed, for any fast line.) They're synchronous in that they block, but not really... Really, the difficulty here is in really rounding out e.g. Rohit's work on similar issues to capture all the critical dimensions of composition and coordination. Such a taxonomic set of features would be useful (academically, and perhaps practically) in its own right, but my goal is really more along the lines of understanding how to make composition as easy as e.g. pipes but more general and flexible, for use in my own pet project and for my own understanding. I.e., what *is* it that makes reuse in e.g. the shell so easy, and so hard everywhere else, and how can we generalize that and make it even stronger? It seems that there are several potential dimensions of composition: (1) is there some kind of reified "connection" or channel between communicating components? (Vs. "just" messaging.) (2) do all components support the same set of interfaces? (3) is communication synchronous (blocking, implying return value) or async (non-blocking, no rv per se) (4) is there flow control, and how is it handled? (5) do components know each other by name? What kinds of names are used? (6) if not name-based coupling, what? (channels; generative dispatch; ...?) (7) what's the relationship between the transport-level metaphors and the higher-level ones? (8) sharing of state, mutability of data, etc. etc. (Again, not presenting this as a complete set, or consistent. Just thinking out loud...) BTW, thanks to Sean for reminding me about QNX. Thinking about explicit element-wise node addressing has generated some interesting questions / ideas over the last 24 hours... In particular, one of the things I've wrestled with for a while now is formalizing the notion of a UNIX-like process. What is it, exactly? The sort of rough definition I've been working from is that it's a partial function from streams, args, etc. (i.e. tuple of (stdio, fds, env, args)) to same (sans args, plus return value). The curried function is reified by providing e.g. args and env, then yields a function from streams to streams + argv. That's not really satisfactory. In particular return values are a problem. I'm sure it's in the more general literature, but (aha moment!) pure functions with return values can be modeled in the pi-calculus with uniqueness types as processes that have a one-shot return value channel. More thinking out loud... jb From jbone at place.org Mon Dec 14 06:45:07 2009 From: jbone at place.org (Jeff Bone) Date: Mon, 14 Dec 2009 08:45:07 -0600 Subject: [FoRK] taxonomy of composition and coordination (thinking out loud...) In-Reply-To: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> References: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> Message-ID: On Dec 14, 2009, at 7:24 AM, Jeff Bone wrote: > The curried function is reified by providing e.g. args and env, then > yields a function from streams to streams + argv. ^argv^rv Ugh. *You* try writing out a type signature for a process in e.g. standard Hindley-Milner that doesn't involve some weird IO monad contortions... ;-) OTOH, in Clean, with uniqueness types, it's a bit more straightforward. jb From eugen at leitl.org Mon Dec 14 08:48:31 2009 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 14 Dec 2009 17:48:31 +0100 Subject: [FoRK] decent CMS templates Message-ID: <20091214164831.GL17686@leitl.org> Anyone aware of a richly themable CMS which isn't a complete system hog and has a large theme designer community? I'm thinking of Joomla or WordPress so far. I'm not happy with either of them, but if they're the best, so be it. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From ken_ganshirt at yahoo.ca Mon Dec 14 08:51:26 2009 From: ken_ganshirt at yahoo.ca (Ken Ganshirt @ Yahoo) Date: Mon, 14 Dec 2009 08:51:26 -0800 (PST) Subject: [FoRK] A story of (years of) productive frustration in software development In-Reply-To: <55C99150-DEA1-4020-8D58-A6CAF0A32329@place.org> Message-ID: <286226.31505.qm@web33003.mail.mud.yahoo.com> --- On Mon, 12/14/09, Jeff Bone wrote: > > Excellent stuff...? William Stein's personal story of > how Sage came to be, entitled "Mathematical Software and > Me:? a Very Personal Recollection" > > ? http://wstein.org/mathsoftbio/history.pdf > Thanks, Jeff. I've always had a warm/fuzzy about open source but I never really got the power of it until that article. Just never thought about it, really, beyond feeling intuitively that it's a Good Thing. He makes it personal, which makes it easy to get. ...ken.... __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From russell.turpin at gmail.com Mon Dec 14 16:53:26 2009 From: russell.turpin at gmail.com (Russell Turpin) Date: Mon, 14 Dec 2009 18:53:26 -0600 Subject: [FoRK] Anarchy high in Asia? Message-ID: I thought some here might find this interesting: http://www.boston.com/bostonglobe/ideas/articles/2009/12/06/the_mystery_of_zomia/?page=full From ken_ganshirt at yahoo.ca Mon Dec 14 17:45:27 2009 From: ken_ganshirt at yahoo.ca (Ken Ganshirt @ Yahoo) Date: Mon, 14 Dec 2009 17:45:27 -0800 (PST) Subject: [FoRK] Anarchy high in Asia? In-Reply-To: Message-ID: <944639.6776.qm@web33001.mail.mud.yahoo.com> --- On Mon, 12/14/09, Russell Turpin wrote: > I thought some here might find this > interesting: > > http://www.boston.com/bostonglobe/ideas/articles/2009/12/06/the_mystery_of_zomia/?page=full > _______________________________________________ Wow. I'm reading "The Fourth Turning" right now. This article juxtaposed against that book made for a really interesting perspective. ...ken... __________________________________________________________________ The new Internet Explorer? 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ From sdw at lig.net Mon Dec 14 18:43:56 2009 From: sdw at lig.net (Stephen D. Williams) Date: Mon, 14 Dec 2009 18:43:56 -0800 Subject: [FoRK] taxonomy of composition and coordination (thinking out loud...) In-Reply-To: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> References: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> Message-ID: <4B26F7EC.3070500@lig.net> Jeff Bone wrote: > ... > Really, the difficulty here is in really rounding out e.g. Rohit's > work on similar issues to capture all the critical dimensions of > composition and coordination. Such a taxonomic set of features would > be useful (academically, and perhaps practically) in its own right, > but my goal is really more along the lines of understanding how to > make composition as easy as e.g. pipes but more general and flexible, > for use in my own pet project and for my own understanding. I've thought and talked about working on an "upgrade" for the Unixen shell also. On a completely different level, I did an architecture and design solving the composition problem a few years ago - something like a confluence of grid/HPC, map/reduce, P2P, SOA, etc. The goal of that system was very loose coupling, i.e. fully decoupled "tools" as contrasted with half-decoupled SOA/SOAP and most other systems. Among other things, I combined the ideas of Unix filter tools with a macro-level rule engine that controlled flow via message (data blob) metadata pattern matching and a distributed pull work queue with bidding, timeout, and resilient re-execution, operating on an immutable temporal distributed datastore. Each compute node was normally also a storage node. > > I.e., what *is* it that makes reuse in e.g. the shell so easy, and so > hard everywhere else, and how can we generalize that and make it even > stronger? Shell programs generally don't know about each other and are not integrated with each other. They are input+args+algorithm = output(s). I see these next steps: structured interchange (typed graphs, OGDL+types, etc.), option for complex communication connections (managed by the shell, just like piping is, not the tool/process, should include both pipeline, bidirectional pipeline, and more complex options - mux/demux, etc.), option for complex communication architecture in addition to pipelines (arbitrary networks, map/reduce, services), option to be either a process or thread or method (pseudo-thread in a message architecture), and various kinds of efficient context. Memcached is one kind of context. Databases of various kinds are another. There should also be one or more flexible event / metadata matching, filtering, and mapping capabilities. It should be possible to do zero copy as much as possible. It should be possible to avoid serialization and parsing to a large extent (esXML/esDOM etc). Perhaps swizzling should be integral. Scoping should be pervasive. Transactions should be possible at a number of levels, or globally, or scoped in various ways (esXML/esDOM for the memory/process, etc.). This is not the same as fully-general transactional memory, but rather a generational / delta data structure that is directly modifiable. My preferences: > > It seems that there are several potential dimensions of composition: > > (1) is there some kind of reified "connection" or channel between > communicating components? (Vs. "just" messaging.) Most components shouldn't know about anything more than the data needed to complete some operation, i.e. grep etc. Communication channels should generally be async, pipelined, message oriented, multi-channel underneath, reliable but fail-fast best effort unless otherwise indicated (i.e. a "tee"-like component might create a persistent queue that could support auto-recovery). The "shell" should normally do all communication addressing and handling. The tool/component should have even less I/O handling than Unixen tools. > (2) do all components support the same set of interfaces? There should be a few standard types and then the ability to have specialized / arbitrary connector interfaces for 'external' use. > (3) is communication synchronous (blocking, implying return value) or > async (non-blocking, no rv per se) Async should be preferred, sync for simplicity. Return value / result processing should normally be by another step, with context as needed. It could be the same tool/thread or another (bidirectional messages, etc.) > (4) is there flow control, and how is it handled? The "shell", which handles most "normal" communication, should enforce various policies, buffering, flushes, memory management, etc. > (5) do components know each other by name? What kinds of names are > used? Normally they don't know each other at all! Fully decoupled if and when possible. Coupling is the job of the shell, just like Unix. RPC-like "side" communication should be handled in one or more pattern/filter/type ways which can be mapped efficiently (and semi-statically) by the shell. Exceptions of course, just like popen() now. At least that is the goal. For real world, that doesn't solve much. > (6) if not name-based coupling, what? (channels; generative > dispatch; ...?) The shell (and sometimes the tool) does deal in names / handles of some kind. URL/URIs, etc. There are several reasonable alternatives. > (7) what's the relationship between the transport-level metaphors and > the higher-level ones? > (8) sharing of state, mutability of data, etc. Shared nested context in scopes, transactions, and mutable / immutable modes perhaps. > > etc. (Again, not presenting this as a complete set, or consistent. > Just thinking out loud...) > > BTW, thanks to Sean for reminding me about QNX. Thinking about > explicit element-wise node addressing has generated some interesting > questions / ideas over the last 24 hours... > > In particular, one of the things I've wrestled with for a while now is > formalizing the notion of a UNIX-like process. What is it, exactly? > The sort of rough definition I've been working from is that it's a > partial function from streams, args, etc. (i.e. tuple of (stdio, fds, > env, args)) to same (sans args, plus return value). The curried > function is reified by providing e.g. args and env, then yields a > function from streams to streams + argv. That's not really > satisfactory. In particular return values are a problem. I'm sure > it's in the more general literature, but (aha moment!) pure functions > with return values can be modeled in the pi-calculus with uniqueness > types as processes that have a one-shot return value channel. Since a "UNIX-like process" can mean anything, I try to think in terms of prototypical tool-types. A "Unix filter" is a pretty clear choice. In "UFng" (above), it should support bidirectional (and more) communication paradigms. In a large set of those cases, the key to modeling the interaction is context. Whether it is a thread waiting on a synchronous RPC or a pseudo-thread (i.e. some data structure representing a logical context that will be materialized in a thread later), the state of that part of a program is the context of the communication. So, a web application communication stack could be: Bidirectional pipeline: (|| could indicate bidir, or it could be inferred by the tool, or command line... Here, it would make sense for tcp to indicate to the shell that it needed a new real or session context (which could be a pipeline channel) fork of the rest of the pipeline. -C is context ID.) tcp -L -h lig.net -p 80 || tls server.key || supertee -t http -o http.log || apachetool -C lig.net -p /date -c "date" -p "/urlshortener" -c "urlshort -C lig.net" Or unwrapped and paired via context: tcp -C lig.net -L -h lig.net -p 80 | tls -C lig.net server.key | supertee -t http -o httpin.log | apachetool -C lig.net -p /date -c "date" -p "/urlshortener" -c "urlshort -C lig.net" | supertee -t http -o httpout.log | tls -C lig.net server.key | tcp -C lig.net -L -h lig.net -p 80 The first is clearly nicer most of the time, however the latter allows more complex relationships in process / data flow. One other major option is to simply name each endpoint with each command as a discrete definition, allowing the shell to stitch them together arbitrarily. tcp --ID TCP -O TLS tls --ID TLS -I TCP -O SUPERTEE ... Ideally, you use the first style for much of the time, only resorting to the other two (or more) options for the outlier cases. And you allow use of all methods in the same "command line". However, this only solves simple situations where components are already mostly pipeline ready because of their inputs/outputs. You can get pretty far by supporting various levels of metadata tagging of the stream, interaction between tools once they have been connected (content and encoding negotiation, etc.), and data scoping. A la esXML/esDOM, the idea is to create a writable view (via a copy on write layer when transactional) into a larger object / graph space. In pipelines like above, it could be done via a scope operator. More of a language is needed to handle the rest. Note in all of the above, the data need not be constantly copied, parsed, or serialized. Likewise, each tool can be a process, thread, or function call, both local and remote in various senses, where network remote requires some already-present service perhaps. > > More thinking out loud... I hear you. > jb sdw From nornagon at gmail.com Mon Dec 14 21:06:22 2009 From: nornagon at gmail.com (Jeremy Apthorp) Date: Tue, 15 Dec 2009 16:06:22 +1100 Subject: [FoRK] taxonomy of composition and coordination (thinking out loud...) In-Reply-To: <4B26F7EC.3070500@lig.net> References: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> <4B26F7EC.3070500@lig.net> Message-ID: <14d615330912142106v5517346bp341294204605f821@mail.gmail.com> GStreamer has a fairly sophisticated and flexible method of plugging various multimedia components together: http://en.wikipedia.org/wiki/GStreamer#Technical_overview j 2009/12/15 Stephen D. Williams : > Jeff Bone wrote: >> >> ... >> Really, the difficulty here is in really rounding out e.g. Rohit's work on >> similar issues to capture all the critical dimensions of composition and >> coordination. ?Such a taxonomic set of features would be useful >> (academically, and perhaps practically) in its own right, but my goal is >> really more along the lines of understanding how to make composition as easy >> as e.g. pipes but more general and flexible, for use in my own pet project >> and for my own understanding. > > I've thought and talked about working on an "upgrade" for the Unixen shell > also. ?On a completely different level, I did an architecture and design > solving the composition problem a few years ago ?- something like a > confluence of grid/HPC, map/reduce, P2P, SOA, etc. ?The goal of that system > was very loose coupling, i.e. fully decoupled "tools" as contrasted with > half-decoupled SOA/SOAP and most other systems. ?Among other things, I > combined the ideas of Unix filter tools with a macro-level rule engine that > controlled flow via message (data blob) metadata pattern matching and a > distributed pull work queue with bidding, timeout, and resilient > re-execution, operating on an immutable temporal distributed datastore. > ?Each compute node was normally also a storage node. >> >> I.e., what *is* it that makes reuse in e.g. the shell so easy, and so hard >> everywhere else, and how can we generalize that and make it even stronger? > > Shell programs generally don't know about each other and are not integrated > with each other. ?They are input+args+algorithm = output(s). ?I see these > next steps: structured interchange (typed graphs, OGDL+types, etc.), option > for complex communication connections (managed by the shell, just like > piping is, not the tool/process, should include both pipeline, bidirectional > pipeline, and more complex options - mux/demux, etc.), option for complex > communication architecture in addition to pipelines (arbitrary networks, > map/reduce, services), option to be either a process or thread or method > (pseudo-thread in a message architecture), and various kinds of efficient > context. ?Memcached is one kind of context. ?Databases of various kinds are > another. ?There should also be one or more flexible event / metadata > matching, filtering, and mapping capabilities. ?It should be possible to do > zero copy as much as possible. ?It should be possible to avoid serialization > and parsing to a large extent (esXML/esDOM etc). ?Perhaps swizzling should > be integral. ?Scoping should be pervasive. ?Transactions should be possible > at a number of levels, or globally, or scoped in various ways (esXML/esDOM > for the memory/process, etc.). ?This is not the same as fully-general > transactional memory, but rather a generational / delta data structure that > is directly modifiable. > > My preferences: >> >> It seems that there are several potential dimensions of composition: >> >> (1) ?is there some kind of reified "connection" or channel between >> communicating components? ?(Vs. "just" messaging.) > > Most components shouldn't know about anything more than the data needed to > complete some operation, i.e. grep etc. Communication channels should > generally be async, pipelined, message oriented, multi-channel underneath, > reliable but fail-fast best effort unless otherwise indicated (i.e. a > "tee"-like component might create a persistent queue that could support > auto-recovery). ?The "shell" should normally do all communication addressing > and handling. ?The tool/component should have even less I/O handling than > Unixen tools. >> >> (2) ?do all components support the same set of interfaces? > > There should be a few standard types and then the ability to have > specialized / arbitrary connector interfaces for 'external' use. >> >> (3) ?is communication synchronous (blocking, implying return value) or >> async (non-blocking, no rv per se) > > Async should be preferred, sync for simplicity. ?Return value / result > processing should normally be by another step, with context as needed. ?It > could be the same tool/thread or another (bidirectional messages, etc.) >> >> (4) ?is there flow control, and how is it handled? > > The "shell", which handles most "normal" communication, should enforce > various policies, buffering, flushes, memory management, etc. >> >> (5) ?do components know each other by name? ?What kinds of names are used? > > Normally they don't know each other at all! ?Fully decoupled if and when > possible. ?Coupling is the job of the shell, just like Unix. ?RPC-like > "side" communication should be handled in one or more pattern/filter/type > ways which can be mapped efficiently (and semi-statically) by the shell. > ?Exceptions of course, just like popen() now. ?At least that is the goal. > > For real world, that doesn't solve much. >> >> (6) ?if not name-based coupling, what? ?(channels; ?generative dispatch; >> ?...?) > > The shell (and sometimes the tool) does deal in names / handles of some > kind. ?URL/URIs, etc. ?There are several reasonable alternatives. >> >> (7) ?what's the relationship between the transport-level metaphors and the >> higher-level ones? >> (8) ?sharing of state, mutability of data, etc. > > Shared nested context in scopes, transactions, and mutable / immutable modes > perhaps. >> >> etc. ?(Again, not presenting this as a complete set, or consistent. ?Just >> thinking out loud...) >> >> BTW, thanks to Sean for reminding me about QNX. ?Thinking about explicit >> element-wise node addressing has generated some interesting questions / >> ideas over the last 24 hours... >> >> In particular, one of the things I've wrestled with for a while now is >> formalizing the notion of a UNIX-like process. ?What is it, exactly? ?The >> sort of rough definition I've been working from is that it's a partial >> function from streams, args, etc. (i.e. tuple of (stdio, fds, env, args)) to >> same (sans args, plus return value). ?The curried function is reified by >> providing e.g. args and env, then yields a function from streams to streams >> + argv. ?That's not really satisfactory. ?In particular return values are a >> problem. ?I'm sure it's in the more general literature, but (aha moment!) >> pure functions with return values can be modeled in the pi-calculus with >> uniqueness types as processes that have a one-shot return value channel. > > Since a "UNIX-like process" can mean anything, I try to think in terms of > prototypical tool-types. ?A "Unix filter" is a pretty clear choice. ?In > "UFng" (above), it should support bidirectional (and more) communication > paradigms. ?In a large set of those cases, the key to modeling the > interaction is context. ?Whether it is a thread waiting on a synchronous RPC > or a pseudo-thread (i.e. some data structure representing a logical context > that will be materialized in a thread later), the state of that part of a > program is the context of the communication. ?So, a web application > communication stack could be: > > Bidirectional pipeline: (|| could indicate bidir, or it could be inferred by > the tool, or command line... ?Here, it would make sense for tcp to indicate > to the shell that it needed a new real or session context (which could be a > pipeline channel) fork of the rest of the pipeline. -C is context ID.) > tcp -L -h lig.net -p 80 || tls server.key || supertee -t http -o http.log || > apachetool -C lig.net -p /date -c "date" -p "/urlshortener" -c "urlshort -C > lig.net" > > Or unwrapped and paired via context: > tcp -C lig.net -L -h lig.net -p 80 | tls -C lig.net server.key | supertee -t > http -o httpin.log | apachetool -C lig.net -p /date -c "date" -p > "/urlshortener" -c "urlshort -C lig.net" | supertee -t http -o httpout.log | > tls -C lig.net server.key | tcp -C lig.net -L -h lig.net -p 80 > > The first is clearly nicer most of the time, however the latter allows more > complex relationships in process / data flow. ?One other major option is to > simply name each endpoint with each command as a discrete definition, > allowing the shell to stitch them together arbitrarily. > > tcp --ID TCP -O TLS > tls --ID TLS -I TCP -O SUPERTEE > ... > > Ideally, you use the first style for much of the time, only resorting to the > other two (or more) options for the outlier cases. ?And you allow use of all > methods in the same "command line". > > However, this only solves simple situations where components are already > mostly pipeline ready because of their inputs/outputs. ?You can get pretty > far by supporting various levels of metadata tagging of the stream, > interaction between tools once they have been connected (content and > encoding negotiation, etc.), and data scoping. ?A la esXML/esDOM, the idea > is to create a writable view (via a copy on write layer when transactional) > into a larger object / graph space. ?In pipelines like above, it could be > done via a scope operator. > > More of a language is needed to handle the rest. > > Note in all of the above, the data need not be constantly copied, parsed, or > serialized. ?Likewise, each tool can be a process, thread, or function call, > both local and remote in various senses, where network remote requires some > already-present service perhaps. >> >> More thinking out loud... > > I hear you. > >> jb > > sdw > > _______________________________________________ > FoRK mailing list > http://xent.com/mailman/listinfo/fork > From sean at conman.org Mon Dec 14 21:37:45 2009 From: sean at conman.org (Sean Conner) Date: Tue, 15 Dec 2009 00:37:45 -0500 Subject: [FoRK] taxonomy of composition and coordination (thinking out loud...) In-Reply-To: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> References: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> Message-ID: <20091215053745.GA24062@brevard.conman.org> It was thus said that the Great Jeff Bone once stated: > > I.e., what *is* it that makes reuse in e.g. the shell so easy, and so > hard everywhere else, and how can we generalize that and make it even > stronger? Because there's only a single type between components---lines of text (which can also be considered a stream of text). That's it. It's up the the programmer/program to massage the data into a usable form. > In particular, one of the things I've wrestled with for a while now is > formalizing the notion of a UNIX-like process. What is it, exactly? I was taught that a "process" can own (or use) resources---the CPU, files, memory and the like; a "thread" (or "unit of execution" as my OS instructor liked to say) did not. You can also think of a process as an instantiation of a program, and (in my thinking) a program is nothing more than an overblown subroutine (or rather, subroutines and programs are equivalent---they may take input [1], they may do some processing [2], but they must have output [3]). -spc (I would also like to find a way to separate logic, language (that is, human language) and layout, especially with web applications) [1] A program/subroutine to calculate e to a million digits does not require input. [2] By "process" I mean transform or manipulate data. A program like the Unix "yes" program does no processing, nor does the Unix program "cp" or "mv". [3] Without output, why call the program/subroutine? The only exception I've found so far is the sleep() command, but even there, the "output" (or "side effect") is the passage of a set amount of time. So far, that's about the only execption I've found to this rule. From ken_ganshirt at yahoo.ca Mon Dec 14 21:54:04 2009 From: ken_ganshirt at yahoo.ca (Ken Ganshirt @ Yahoo) Date: Mon, 14 Dec 2009 21:54:04 -0800 (PST) Subject: [FoRK] Cloudy thoughts on backups Message-ID: <356180.63778.qm@web33001.mail.mud.yahoo.com> I read a post on one of those popular tech blogs .. ZDNet, maybe? The guy was having a problem with his Mac and it had to go in for repair. He was able to coax it to run enough to do a backup "... to the safety of the cloud." Is that an oxymoron? Or is he just a moron? On a somewhat related note, a message for the suppliers of cloudy services: http://www.joelonsoftware.com/items/2009/12/14.html ...ken... __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ From michaelslists at gmail.com Mon Dec 14 22:02:22 2009 From: michaelslists at gmail.com (silky) Date: Tue, 15 Dec 2009 17:02:22 +1100 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <356180.63778.qm@web33001.mail.mud.yahoo.com> References: <356180.63778.qm@web33001.mail.mud.yahoo.com> Message-ID: <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> On Tue, Dec 15, 2009 at 4:54 PM, Ken Ganshirt @ Yahoo wrote: > I read a post on one of those popular tech blogs .. ZDNet, maybe? The guy was having a problem with his Mac > and it had to go in for repair. He was able to coax it to run enough to do a backup "... to the safety of the cloud." > > Is that an oxymoron? Or is he just a moron? > > On a somewhat related note, a message for the suppliers of cloudy services: > > http://www.joelonsoftware.com/items/2009/12/14.html I was with you right up until you referenced joel. I really wish we could all just ignore that guy, or at least his personality, and focus on things that really matter; not useless ego-stroking bullsh*t. Anyway, as we all know, "cloud" is nothing but a computer you don't own sitting with someone else. So lets disregard the term and focus on providers of such computers, or space, who let you do backups. And yes, we've used Mozy (http://mozy.com/) to do a backup AND restore, in a critical situation, only recently, and it worked. So from that point of view, I don't care where it is or what some article calls it (or even what it calls itself); I am happy that it worked, and will be trying out the free version for myself a little later in the week. And as to your question of the guy being a moron, well, he's running mac. You decide :P > ? ? ? ? ...ken... -- silky http://www.mirios.com.au/ http://island.mirios.com.au/t/rigby+random+20 CONCORDANT; blasphemy camcorder = capsize, anyway pacifist oriole. PARASYMPATHETIC unbelievable. From nornagon at gmail.com Tue Dec 15 05:06:05 2009 From: nornagon at gmail.com (Jeremy Apthorp) Date: Wed, 16 Dec 2009 00:06:05 +1100 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> References: <356180.63778.qm@web33001.mail.mud.yahoo.com> <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> Message-ID: <14d615330912150506j1454992ei1e71f6eff73e5972@mail.gmail.com> 2009/12/15 silky : > And as ?to your question of the guy being a moron, well, he's running > mac. You decide :P Or perhaps the moron is the one that jumps to conclusions ;) j From michaelslists at gmail.com Tue Dec 15 05:07:18 2009 From: michaelslists at gmail.com (silky) Date: Wed, 16 Dec 2009 00:07:18 +1100 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <14d615330912150506j1454992ei1e71f6eff73e5972@mail.gmail.com> References: <356180.63778.qm@web33001.mail.mud.yahoo.com> <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> <14d615330912150506j1454992ei1e71f6eff73e5972@mail.gmail.com> Message-ID: <5e01c29a0912150507n1c3d73e4j65dd38838be9d0fa@mail.gmail.com> On Wed, Dec 16, 2009 at 12:06 AM, Jeremy Apthorp wrote: > 2009/12/15 silky : > > And as ?to your question of the guy being a moron, well, he's running > > mac. You decide :P > > Or perhaps the moron is the one that jumps to conclusions ;) What conclusion did I jump to? > j -- silky http://www.mirios.com.au/ http://island.mirios.com.au/t/rigby+random+20 From nornagon at gmail.com Tue Dec 15 05:12:25 2009 From: nornagon at gmail.com (Jeremy Apthorp) Date: Wed, 16 Dec 2009 00:12:25 +1100 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <5e01c29a0912150507n1c3d73e4j65dd38838be9d0fa@mail.gmail.com> References: <356180.63778.qm@web33001.mail.mud.yahoo.com> <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> <14d615330912150506j1454992ei1e71f6eff73e5972@mail.gmail.com> <5e01c29a0912150507n1c3d73e4j65dd38838be9d0fa@mail.gmail.com> Message-ID: <14d615330912150512g145d3710v49362d75311d9f67@mail.gmail.com> 2009/12/16 silky : > On Wed, Dec 16, 2009 at 12:06 AM, Jeremy Apthorp wrote: >> 2009/12/15 silky : >> > And as ?to your question of the guy being a moron, well, he's running >> > mac. You decide :P >> >> Or perhaps the moron is the one that jumps to conclusions ;) > > What conclusion did I jump to? That using a mac makes you a moron :) j From michaelslists at gmail.com Tue Dec 15 05:13:55 2009 From: michaelslists at gmail.com (silky) Date: Wed, 16 Dec 2009 00:13:55 +1100 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <14d615330912150512g145d3710v49362d75311d9f67@mail.gmail.com> References: <356180.63778.qm@web33001.mail.mud.yahoo.com> <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> <14d615330912150506j1454992ei1e71f6eff73e5972@mail.gmail.com> <5e01c29a0912150507n1c3d73e4j65dd38838be9d0fa@mail.gmail.com> <14d615330912150512g145d3710v49362d75311d9f67@mail.gmail.com> Message-ID: <5e01c29a0912150513n5ee4bfe4n29ac418b6e0f2bf4@mail.gmail.com> On Wed, Dec 16, 2009 at 12:12 AM, Jeremy Apthorp wrote: > > What conclusion did I jump to? > > That using a mac makes you a moron :) I'm going to assume you realise that I was making a joke, and that you are doing the same. > j -- silky http://www.mirios.com.au/ http://island.mirios.com.au/t/rigby+random+20 From nornagon at gmail.com Tue Dec 15 05:26:24 2009 From: nornagon at gmail.com (Jeremy Apthorp) Date: Wed, 16 Dec 2009 00:26:24 +1100 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <5e01c29a0912150513n5ee4bfe4n29ac418b6e0f2bf4@mail.gmail.com> References: <356180.63778.qm@web33001.mail.mud.yahoo.com> <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> <14d615330912150506j1454992ei1e71f6eff73e5972@mail.gmail.com> <5e01c29a0912150507n1c3d73e4j65dd38838be9d0fa@mail.gmail.com> <14d615330912150512g145d3710v49362d75311d9f67@mail.gmail.com> <5e01c29a0912150513n5ee4bfe4n29ac418b6e0f2bf4@mail.gmail.com> Message-ID: <14d615330912150526q629c344awaaeeac8a9efe307c@mail.gmail.com> 2009/12/16 silky : > On Wed, Dec 16, 2009 at 12:12 AM, Jeremy Apthorp wrote: >> > What conclusion did I jump to? >> >> That using a mac makes you a moron :) > > I'm going to assume you realise that I was making a joke, and that you > are doing the same. hence the ;) on the original post. Ah, tone is so tricky on the blogoblag. From michaelslists at gmail.com Tue Dec 15 05:28:40 2009 From: michaelslists at gmail.com (silky) Date: Wed, 16 Dec 2009 00:28:40 +1100 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <14d615330912150526q629c344awaaeeac8a9efe307c@mail.gmail.com> References: <356180.63778.qm@web33001.mail.mud.yahoo.com> <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> <14d615330912150506j1454992ei1e71f6eff73e5972@mail.gmail.com> <5e01c29a0912150507n1c3d73e4j65dd38838be9d0fa@mail.gmail.com> <14d615330912150512g145d3710v49362d75311d9f67@mail.gmail.com> <5e01c29a0912150513n5ee4bfe4n29ac418b6e0f2bf4@mail.gmail.com> <14d615330912150526q629c344awaaeeac8a9efe307c@mail.gmail.com> Message-ID: <5e01c29a0912150528g6b3d9240h943df62f4f5184e@mail.gmail.com> On Wed, Dec 16, 2009 at 12:26 AM, Jeremy Apthorp wrote: > 2009/12/16 silky : > > On Wed, Dec 16, 2009 at 12:12 AM, Jeremy Apthorp wrote: > > > > What conclusion did I jump to? > > > > > > That using a mac makes you a moron :) > > > > I'm going to assume you realise that I was making a joke, and that you > > are doing the same. > > hence the ;) on the original post. Ah, tone is so tricky on the blogoblag. Forgive me, I happened to be amidst another argument through this account, and accidentally carried the argumentative tone across :) -- silky http://www.mirios.com.au/ http://island.mirios.com.au/t/rigby+random+20 CONGREGATIONALISM estrangement SOBERNESS TRADESWOMAN deaconess sponger! Tallness, duck! WOK. From ken_ganshirt at yahoo.ca Tue Dec 15 08:02:55 2009 From: ken_ganshirt at yahoo.ca (Ken Ganshirt @ Yahoo) Date: Tue, 15 Dec 2009 08:02:55 -0800 (PST) Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> Message-ID: <725111.1378.qm@web33001.mail.mud.yahoo.com> --- On Tue, 12/15/09, silky wrote: > On Tue, Dec 15, 2009 at 4:54 PM, Ken Ganshirt @ Yahoo > wrote: > > I read a post on one of those popular tech blogs .. > > ZDNet, maybe? The guy was having a problem with his Mac > > and it had to go in for repair. He was able to coax it > > to run enough to do a backup "... to the safety of the > > cloud." > > > > Is that an oxymoron? Or is he just a moron? > > > > On a somewhat related note, a message for the > > suppliers of cloudy services: > > > > http://www.joelonsoftware.com/items/2009/12/14.html > > I was with you right up until you referenced joel. I really > wish we could all just ignore that guy, or at least his > personality, and focus on things that really matter; not > useless ego-stroking bullsh*t. > Yes, I find his attitude a bit grating sometimes. But I learned a long time ago that even egotists can be smart. For instance... > > Anyway, as we all know, "cloud" is nothing but a computer > you don't own sitting with someone else. ... > Just so. Most notably the "don't own" and run by "someone else" parts. Which makes Joel's point so compelling. It's not sufficient that a *user* of a cloud-based ... okay, non-local, backup service have done their own restore testing. It's critical that the *purveyor* of said non-local backup service have done restore testing and that they do it with some regularity. With the recent events of service providers not being able to restore themselves after outages, it's unconscionable that any external service provider would not do such testing on a regular basis ... regardless of what you think of Joel's attitude... What's the point of a Plan B (restore from backups) if you don't have any idea it will work? Or don't have a Plan B at all (backups but no plan how to recover with them). ...... Especially when you are someone else's Plan B. My plan B is a $100 USB drive that sits at my daughter's house between backups (well, you could get the same drive for 69 bucks today). It contains both a restorable image and recent backups of critical data files. Yes, I have restored from it successfully. ...ken... __________________________________________________________________ The new Internet Explorer? 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ From eugen at leitl.org Tue Dec 15 08:16:46 2009 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 15 Dec 2009 17:16:46 +0100 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <725111.1378.qm@web33001.mail.mud.yahoo.com> References: <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> <725111.1378.qm@web33001.mail.mud.yahoo.com> Message-ID: <20091215161646.GS17686@leitl.org> On Tue, Dec 15, 2009 at 08:02:55AM -0800, Ken Ganshirt @ Yahoo wrote: > My plan B is a $100 USB drive that sits at my daughter's house between backups (well, you could get the same drive for 69 bucks today). It contains both a restorable image and recent backups of critical data files. Yes, I have restored from it successfully. I recommend a raidz3 zfs appliance (random box with 4x nearline SATA drives with Nexenta), better two if them in spatially distinct locations, synchronized via rsync or unison. I currently have one based on FreeNAS 0.7 with raidz2 (it even has a BT client, but it keeps rebooting the box) and 4x SATA consumer drives, planning to do EON or napp-it on Nexenta with the next box on Xmas vacation. It's not a backup, but better than nothing. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From jbone at place.org Tue Dec 15 08:20:06 2009 From: jbone at place.org (Jeff Bone) Date: Tue, 15 Dec 2009 10:20:06 -0600 Subject: [FoRK] taxonomy of composition and coordination (thinking out loud...) In-Reply-To: References: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> Message-ID: <3C4AD853-89A4-4AF2-976E-B291E93DA10F@place.org> Sean says (re: "What is a UNIX process...) > Because there's only a single type between components---lines of > text (which can also be considered a stream of text). That's it. > It's up the the programmer/program to massage the data into a usable > form. That's certainly true as far as it goes, and it's the easy answer, but it's not the complete answer. I.e., seems "necessary but not sufficient." I'm looking for the difficult answers, i.e. "what is it about functional composition vs. the various means of wiring "processes" together that makes the latter harder than the former for the trivial cases, and how can we make the latter easier for the non- trivial cases? Reuse isn't merely about what passes between components, it's about how you hook them up. There's a bunch of assumptions (called "stdio" and "UNIX return values" and "the environment" and "the filesystem" and so on) built into the typical UNIX process abstraction; those things all impact how you wire things up, and for the trivial cases they make the wiring trivial. Pi-calculus gives us some hooks into the latter; in particular, either of the two major formalisms should be sufficient to express either in terms of the other. And indeed equivalence of certain of the pi-c's have been proven to be equivalent to both typed and untyped lambda calculi. And a rigorous definition of UNIX-like processes *can* be given / has been given already in terms of the non-mobile pi- calculus (ref. escapes me...?) But a *practical* definition of either in terms of the other --- such as would be required to prove correct an implementation of one in terms of a virtual machine for the other --- is conspicuously absent (short of the actual code that implements the whole schebang.) In case some of you might think this is a little bit academic, I'm not trying to joust w/ Hoare and Milner here, I'm merely attempting to get enough of the formalism down right in order to inform a better implementation. And one that's not chock-full-o-buzzword soup (ahem, sdw... ;-) or hand-wavy architecture astronautics but rather a nice, unambiguous, minimalist formalism that maps well to (implementing!) how things might get (more effectively!) wired together. A better question than "what is a process" --- and one that might be necessary to answer that --- is "what is a channel" (i.e., in the various process calculi that use channels, which is IMHO all of them except the labeled join calculi such as Erlang rests upon.) (Food for thought: relationships between mobile channels and capabilities in capability-based system, cf. Amoeba.) jb From tomhiggins at gmail.com Tue Dec 15 09:06:34 2009 From: tomhiggins at gmail.com (Tom Higgins) Date: Tue, 15 Dec 2009 09:06:34 -0800 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <356180.63778.qm@web33001.mail.mud.yahoo.com> References: <356180.63778.qm@web33001.mail.mud.yahoo.com> Message-ID: Clouds, cloud backup, cloud computing and cloudy weather....a pre coffee wandering. devices - If you can not root it you do not control it, hence you are at best marginally out of control and at worst SOL should the fan be impacted by the shizz. Often this is the best solution for the task at hand, often it is simply the convenient default. Knowing is half the battle sayeth GI Joe. But even a boxen on which you have full on rootability is still out of your control should the hard-line fall dead. You can not open a door you can not ge the key into. So again....at best marginal. data - If you can/do not encrypt it you do not control its audience. Sure you can lots about breaking the code, so then sure you can say lots about upping the bits. Cat and Mouse, Moose and Squirrel. 99.99% of data may never need encrypting, for everything else there is the option...or not. How much different would the net be if pgp made it in with the cool kids such that every text box we filled in with our thoughts, loves, day filling musings and extemporaneous miscellany were easily transformed only to be easily read by those with the right key? Data mining might take a shuffle back...a little. Dust ups over Facebook screwing the proletariat might not hit my inbox so often. But nah, it was not cool enough and too hard to fit into the "perfect" gui cult..so out it went and here we be. traffic - ISP's plonk down quotas on bwf so therefor what you can convert from out there to local and vice versa is of a limit. Not always an issue but often it can be. The boundaries of the that which can be expressed on the greater consensual fabric of knowing are confined in part by this little item. Which, I think, is all to say that clouds offer an ease of spread but the trade off is control. Same as it always was. Oh hey, the coffee is brewed. -tom(lord i was born a rambling man) From sdw at lig.net Tue Dec 15 09:45:30 2009 From: sdw at lig.net (Stephen Williams) Date: Tue, 15 Dec 2009 09:45:30 -0800 Subject: [FoRK] taxonomy of composition and coordination (thinking out loud...) In-Reply-To: <3C4AD853-89A4-4AF2-976E-B291E93DA10F@place.org> References: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> <3C4AD853-89A4-4AF2-976E-B291E93DA10F@place.org> Message-ID: <4B27CB3A.10002@lig.net> Jeff Bone wrote: > > ... > In case some of you might think this is a little bit academic, I'm not > trying to joust w/ Hoare and Milner here, I'm merely attempting to get > enough of the formalism down right in order to inform a better > implementation. And one that's not chock-full-o-buzzword soup (ahem, > sdw... ;-) or hand-wavy architecture astronautics but rather a nice, > unambiguous, minimalist formalism that maps well to (implementing!) > how things might get (more effectively!) wired together. When talking about architecture & design, you have to communicate pools of ideas that you are and are not pulling from. Whether you refer to a particular calculus or some reduced-to-practice implementation, the mental operation is the same, albeit more-pure vs. cluttered conglomerations in certain cases. The biggest problem with referring to a particular item is that one often only means that a particular subset is important and the rest should be ignored, which is hard to concisely state. Anything can and usually should be described using metaphorical references. http://en.wikipedia.org/wiki/Buzzword > A buzzword (also fashion word and vogue word) is a term of art or > technical jargon that has begun to see use in the wider society > outside of its originally narrow technical context by nonspecialists > who use the term vaguely or imprecisely. Labelling a term a "buzzword" > often perjoratively implies that it is now used pretentiously and > inappropriately by individuals with little understanding of its actual > meaning who are most interested in impressing others by making their > discourse sound more esoteric, obscure, and technical than it > otherwise would be. Really?? I think we are both either guilty or not guilty of this. Since we've both designed and implemented many of these "buzzwords", I myself wouldn't have gone there. ;-) > > A better question than "what is a process" --- and one that might be > necessary to answer that --- is "what is a channel" (i.e., in the > various process calculi that use channels, which is IMHO all of them > except the labeled join calculi such as Erlang rests upon.) (Food for > thought: relationships between mobile channels and capabilities in > capability-based system, cf. Amoeba.) > > jb > sdw From jbone at place.org Tue Dec 15 11:52:07 2009 From: jbone at place.org (Jeff Bone) Date: Tue, 15 Dec 2009 13:52:07 -0600 Subject: [FoRK] Son of a gun... Message-ID: <12B41DC2-7D94-4037-A39A-37F105F564E4@place.org> Carl Hewitt's the man, of course. Has been for a long time --- wrote the book on a lot of the stuff I'm yammering about. Gets it. Saw this via LtU today: http://arxiv.org/pdf/0907.3330v12 Interesting. Haven't done more than skim it, but he's hitting a lot of right notes. Not sure about the language per se. But clearly the right direction... jb From sdw at lig.net Tue Dec 15 13:07:07 2009 From: sdw at lig.net (Stephen Williams) Date: Tue, 15 Dec 2009 13:07:07 -0800 Subject: [FoRK] Son of a gun... In-Reply-To: <12B41DC2-7D94-4037-A39A-37F105F564E4@place.org> References: <12B41DC2-7D94-4037-A39A-37F105F564E4@place.org> Message-ID: <4B27FA7B.1030500@lig.net> Very cool, thanks! Can't wait to digest this. Stephen Jeff Bone wrote: > > Carl Hewitt's the man, of course. Has been for a long time --- wrote > the book on a lot of the stuff I'm yammering about. Gets it. > > Saw this via LtU today: > > http://arxiv.org/pdf/0907.3330v12 > > Interesting. Haven't done more than skim it, but he's hitting a lot > of right notes. > > Not sure about the language per se. But clearly the right direction... > > > jb > > _______________________________________________ > FoRK mailing list > http://xent.com/mailman/listinfo/fork From sean at conman.org Tue Dec 15 13:57:50 2009 From: sean at conman.org (Sean Conner) Date: Tue, 15 Dec 2009 16:57:50 -0500 Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <725111.1378.qm@web33001.mail.mud.yahoo.com> References: <5e01c29a0912142202v252be0a2o6944a998e6b6b622@mail.gmail.com> <725111.1378.qm@web33001.mail.mud.yahoo.com> Message-ID: <20091215215750.GA29837@brevard.conman.org> It was thus said that the Great Ken Ganshirt @ Yahoo once stated: > > With the recent events of service providers not being able to restore > themselves after outages, it's unconscionable that any external service > provider would not do such testing on a regular basis ... regardless of > what you think of Joel's attitude... About a decade ago, I had the displeasure of working with a database [1] and I asked my friend (who was more knowledgable in these things than I) how I could get a "dump" of the database. You'd think I asked him to sprout antennae or something. "Why the @#$@#$ would you need something so @#$@#$ stupid as that?" "I want to back up the database!" "What a #$$%# stupid thing to do," he said. He then went on to explain that "real" databases can't be backed up because 1) some of the "data" in a data base isn't explicitely stored in the database, and 2) you're talking terrabytes of data (to be fair, he was working in telephony at the time and the "smallest" database he worked on was measured in the millions of rows; same with the codebases he was used to---smallest was measured in millions of lines written over 30 years in a proprietary langauge). In his world (enterprise-class software systems) "backups" just aren't possible because it doesn't make all that much sense [6]. I've also been on the back end of a outtage when the main server of the company I worked for (different from The Company I work for now) was hacked [2] during a particularly bad time of the year [3]. Even though we had a full backup, it still took over 50 hours to rebuild, reinstall and restore [4]. It's not something I'd like to repeat. And that was a small operation (just a few gigs of information). But I can see how restoring from backups can be difficult. At our current company, our bus number [5] is 1 (maybe 2) and I'm not counted in that number (then again, out bus number for the network is also 1, and I'm counted in that number). IT is already considered a cost-center by near every large company that doesn't specialize in IT (and even then, I'm guessing the internal IT is *still* considered a cost-center) and recovery testing costs extra (so sayeth the bean counters) so I'm guessing it doesn't get tested all that often unless there's strong support from the C*O level. -spc (I think Joel was just saying, "test your restore procedure, not just your backup procedures ... ") [1] I hate databases. Not quite as much as control panels, but still, I hate them (bad experiences and an insane instructor in college). [2] http://boston.conman.org/2004/09/19.1 And yes, the hacker really did write me an email explaining what he did. [3] http://boston.conman.org/2004/09/ The hurricanes *just* *wouldn't* *stop* *coming*! [4] Just in time for yet another hurricane. [5] http://c2.com/cgi/wiki?BusNumber [6] Then again, he showed me the closest were the previous version of the switch software was stored---printed out on about a million pages of paper, which I doubt was even of the acid-free archival type. From jbone at place.org Tue Dec 15 18:52:37 2009 From: jbone at place.org (Jeff Bone) Date: Tue, 15 Dec 2009 20:52:37 -0600 Subject: [FoRK] taxonomy of composition and coordination (thinking out loud...) In-Reply-To: <3C4AD853-89A4-4AF2-976E-B291E93DA10F@place.org> References: <5CB824FF-304C-4F6C-8BB4-320BE79B3CBF@place.org> <3C4AD853-89A4-4AF2-976E-B291E93DA10F@place.org> Message-ID: Stephen says: > I think we are both either guilty or not guilty of this. Guilty as charged. Unf. you have to in order to get sufficient compression; shared context etc. Mostly I was just razzing you for using the term "SOA." ;-) :-/ Means everything, and therefore nothing at all --- but that hasn't stopped hordes of third-stringers from writing reams and reams of religious material on the topic to be read by managers who don't generally have any idea what the writer is talking about (to the extent that the writer himself does...) Ugh. (Not talking about you here in either case.) Just hate that term... And sometimes, too, the terms themselves lose their meaning over time. Atrophy. We lose sight of first principles. ("SOA" certainly isn't a first-principles approach to architecture.) I'm not interested in software architecture, or architectural styles, per se. I'm interested in how to write systems: in the large, in the small, in general. It seems that might have something to do with architectural styles, and that which might be abstracted from various of them and distilled to its essential parts. jb From mike at dierken.com Tue Dec 15 18:58:04 2009 From: mike at dierken.com (Mike Dierken) Date: Tue, 15 Dec 2009 18:58:04 -0800 Subject: [FoRK] decent CMS templates In-Reply-To: <20091214164831.GL17686@leitl.org> References: <20091214164831.GL17686@leitl.org> Message-ID: <3f5bf96b0912151858o5958fa2ah68e85e7b95359ceb@mail.gmail.com> I've used Drupal a bit, but don't like any of them. If I have to, I'll try WordPress next time. On Mon, Dec 14, 2009 at 8:48 AM, Eugen Leitl wrote: > > Anyone aware of a richly themable CMS which isn't a complete > system hog and has a large theme designer community? > > I'm thinking of Joomla or WordPress so far. I'm not happy > with either of them, but if they're the best, so be it. > > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A ?7779 75B0 2443 8B29 F6BE > _______________________________________________ > FoRK mailing list > http://xent.com/mailman/listinfo/fork > From ken_ganshirt at yahoo.ca Tue Dec 15 20:55:29 2009 From: ken_ganshirt at yahoo.ca (Ken Ganshirt @ Yahoo) Date: Tue, 15 Dec 2009 20:55:29 -0800 (PST) Subject: [FoRK] Cloudy thoughts on backups In-Reply-To: <20091215215750.GA29837@brevard.conman.org> Message-ID: <847613.27843.qm@web33007.mail.mud.yahoo.com> Hi Sean, I'm not going to do a point-by-point so I'm going to top-post here. Twenty-nine year career in IT in a telco and a year with Nortel immediately prior to the 2001 meltdown. Developer for the first eight years. Managed development groups and desktop support for the next eight in internal IT. Then spent the rest managing development and support groups in an IT group in Engineering (got totally fed up with the whiny "nobody understands us, everybody hates us" mainstream IT bunker mentality). Took a two year side trip in there somewhere managing an Engineering group that supported the guys who installed, operated and maintained the switches so I'm aware of all the issues with switch software .. at least with Nortel's. I relate to your friend's comments about mega databases. I truly do. But it's a copout. Whining about IT being viewed as a cost centre is also a copout. Even though it's also true and I can seriously relate. Here's how you change that, if you have the balls. You start by getting a key user department to do a review of their business continuity and offer to help. HELP, not do it for them. They have to lead and control the whole thing. They're gonna get their eyes opened, really wide, when they see the things that can get in the way of their being able to continue doing business. Other departments they are dependent on. Other departments that are dependent on them. And how utterly and hopelessly dependent they have become on their computer-based functions. Your stuff. The comprehension dawns fairly quickly that you really aren't a cost centre but a major enabler of their business processes. And a giant disaster waiting to happen if you and they don't have your collective shit together in the event of non-trivial system outages. It rather changes their whole view of internal IT. It can be changed for the positive if you're prepared to work with them to deal with the issues that get flushed out if they want to start working up some business continuity plans. Yes, Joel's message was test your restore plan. If you're internal IT the way you get the resources and support to do that is help one or two key departments to understand how vulnerable their business is if, between the two of you, you don't have a plan for how to restore their business operation in the event of nasty things happening, of which you are among them. The best ones to start with are those that interface or interact directly with customers: order takers and fulfillment. Billing isn't a bad place to hook into either .. hard as hell to make money if you can't take orders, can't fulfill or/and can't get the bills out. If you're outsourcing, it's irresponsible to not ensure that you and the user departments affected have sorted out the same business continuity issues, now that an external service supplier is in the middle of things. And then make sure the SLA covers the necessities, with serious enough penalties to get their attention. That will include making sure the external supplier actually has their part of the plan worked out and that they can execute on it. And that all parties who will be affected review the situation from time to time to make sure things have not changed enough to make it irrelevant. Of COURSE it costs money. TANSTAAFL is a fundamental law of the universe (one of the laws of thermodynamics, isn't it?). So you do a business case: the cost of business continuity versus the cost of the alternative (degraded business capability for X days/weeks/years, no business capability for X days/weeks/years, some combination of both). You can be very specific and very believable. It's not rocket science. There just has to be someone who gives a crap to kickstart it. Back to the BS about a database that's too big to backup (geez, same mentality as the bankers)... if it's critical to the operation of the business, clone and mirror the damn thing. Run parallel systems against it with load sharing and automatic switchover. It's not only a good "backup" strategy because you're always working in both copies, it's a super way to be able to do maintenance and upgrades .. dump all the activity to one side, make changes, test, restore load sharing and when things are stable repeat for the other side. That's how the telcos do it. At least everyone outside the IT department. 8-) ...ken... --- On Tue, 12/15/09, Sean Conner wrote: > From: Sean Conner > Subject: Re: [FoRK] Cloudy thoughts on backups > To: "Friends of Rohit Khare" > Received: Tuesday, December 15, 2009, 3:57 PM > It was thus said that the Great Ken > Ganshirt @ Yahoo once stated: > > > > With the recent events of service providers not being > able to restore > > themselves after outages, it's unconscionable that any > external service > > provider would not do such testing on a regular basis > ... regardless of > > what you think of Joel's attitude... > > ? About a decade ago, I had the displeasure of working > with a database [1] > and I asked my friend (who was more knowledgable in these > things than I) how > I could get a "dump" of the database.? > > ? You'd think I asked him to sprout antennae or > something.? "Why the @#$@#$ > would you need something so @#$@#$ stupid as that?" > > ? "I want to back up the database!" > > ? "What a #$$%# stupid thing to do," he said.? He > then went on to explain > that "real" databases can't be backed up because 1) some of > the "data" in a > data base isn't explicitely stored in the database, and 2) > you're talking > terrabytes of data (to be fair, he was working in telephony > at the time and > the "smallest" database he worked on was measured in the > millions of rows; > same with the codebases he was used to---smallest was > measured in millions > of lines written over 30 years in a proprietary > langauge).? In his world > (enterprise-class software systems) "backups" just aren't > possible because > it doesn't make all that much sense [6]. > > ? I've also been on the back end of a outtage when the > main server of the > company I worked for (different from The Company I work for > now) was hacked > [2] during a particularly bad time of the year [3].? > Even though we had a > full backup, it still took over 50 hours to rebuild, > reinstall and restore > [4].? It's not something I'd like to repeat. > > ? And that was a small operation (just a few gigs of > information). > > ? But I can see how restoring from backups can be > difficult.? At our current > company, our bus number [5] is 1 (maybe 2) and I'm not > counted in that > number (then again, out bus number for the network is also > 1, and I'm > counted in that number).? IT is already considered a > cost-center by near > every large company that doesn't specialize in IT (and even > then, I'm > guessing the internal IT is *still* considered a > cost-center) and recovery > testing costs extra (so sayeth the bean counters) so I'm > guessing it doesn't > get tested all that often unless there's strong support > from the C*O level. > > ? -spc (I think Joel was just saying, "test your > restore procedure, not just > ??? your backup procedures ... ") > > [1]??? I hate databases.? Not quite as > much as control panels, but still, I > ??? hate them (bad experiences and an insane > instructor in college). > > [2]??? http://boston.conman.org/2004/09/19.1 > > ??? And yes, the hacker really did write me > an email explaining what he > ??? did. > > [3]??? http://boston.conman.org/2004/09/ > > ??? The hurricanes *just* *wouldn't* *stop* > *coming*! > > [4]??? Just in time for yet another > hurricane. > > [5]??? http://c2.com/cgi/wiki?BusNumber > > [6]??? Then again, he showed me the closest > were the previous version of > ??? the switch software was stored---printed > out on about a million > ??? pages of paper, which I doubt was even > of the acid-free archival > ??? type. > _______________________________________________ > FoRK mailing list > http://xent.com/mailman/listinfo/fork > __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From jebdm at jebdm.net Wed Dec 16 12:00:30 2009 From: jebdm at jebdm.net (Jebadiah Moore) Date: Wed, 16 Dec 2009 20:00:30 +0000 Subject: [FoRK] decent CMS templates In-Reply-To: <20091214164831.GL17686@leitl.org> References: <20091214164831.GL17686@leitl.org> Message-ID: <69ae910f0912161200g1e5e71actd9ac7f9de37277a3@mail.gmail.com> I don't have any experience with it, but Textpattern looks nice: http://textpattern.com/ -- Jebadiah Moore http://jebdm.net From sdw at lig.net Wed Dec 16 19:09:06 2009 From: sdw at lig.net (Stephen Williams) Date: Wed, 16 Dec 2009 19:09:06 -0800 Subject: [FoRK] decent CMS templates In-Reply-To: <69ae910f0912161200g1e5e71actd9ac7f9de37277a3@mail.gmail.com> References: <20091214164831.GL17686@leitl.org> <69ae910f0912161200g1e5e71actd9ac7f9de37277a3@mail.gmail.com> Message-ID: <4B29A0D2.3040607@lig.net> Jebadiah Moore wrote: > I don't have any experience with it, but Textpattern looks nice: > http://textpattern.com/ > > -- > Jebadiah Moore > http://jebdm.net > I will look at this and anything else that might solve the CMS/Wiki/doc/blog/publishing problem better. I have not been happy with anything yet, although various wikis are nice in a lot of ways. However, I did just think yesterday that this should exist, and upon search, there it was: Inline Google Docs for WordPress: http://code.google.com/p/inline-google-docs/ http://wordpress.org/extend/plugins/inline-google-docs/ Coupled with Google Docs fairly clean read-only "publish" model, MSOffice/OpenOffice-like editing, and some URL indirection, this is a nice solution for certain cases. I'm planning to use it for my mother and her business. Seems like textpattern is nice but has lost pace with WP. I think I like it better in some ways, but probably WP is now flexible enough to do most things. We'll see. Stephen From michael at i-magery.com Sun Dec 20 06:50:58 2009 From: michael at i-magery.com (Michael Cummins) Date: Sun, 20 Dec 2009 09:50:58 -0500 Subject: [FoRK] From Meccania to Atlantis In-Reply-To: <4B29A0D2.3040607@lig.net> References: <20091214164831.GL17686@leitl.org> <69ae910f0912161200g1e5e71actd9ac7f9de37277a3@mail.gmail.com> <4B29A0D2.3040607@lig.net> Message-ID: <01bb01ca8183$d7211990$85634cb0$@com> Some fascinating reading here, to me at least. As of today Takuan Seiyo is on part 13(2). He touches on a wide range of topics. >From Meccania to Atlantis: Part 13(2) http://www.brusselsjournal.com/blog/7745 This is the piece that caught my eye (reading feeds over coffee this morning) though it is a very tiny part of the greater whole: >From Meccania to Atlantis: Part 13(1) http://www.brusselsjournal.com/node/4158 -- begin quote -- The strongest, most admired country in the world until just a few years ago is now a cautionary tale of the wages of sin and stupidity told to Chinese schoolchildren. A nation that works for a living can weather perhaps even such great storms. But the jobs of the American lower class have been outsourced to imported Mexicans. The jobs of the American middle class have been exported to China and India. The jobs of the American upper-middle class have been taken from the white males who held them by merit, and given to resentful identity groups that hold them by the fiat of the government's preferred skin colors and favored genitalia. And the jobs of the American upper class have been reprogrammed from leadership and service, to ripping off the less clever via lawyering, banksterism, and padding one's golden CEO parachute, and then expiation via funding and leading socialist NGOs. A freefalling dollar cannot help by increasing exports, when you have off-shored your manufacturing, and your main industries are predatory lawsuits, selling shoddy American housing to Salvadorians with faked mortgages, and marketing financial weapons of mass destruction worldwide. And a falling dollar is not a good inducement for the world to keep buying dollar-denominated U.S. debt. The cessation of that buying has such dire consequences to the United States that Chinese strategists have named them "the nuclear option." The American people can't do anything about it either, except mailing tea bags to the crooks and loons who govern them. Their only electoral choice is between the party of demented progressives, and the party of progressive dementia. -- end quote -- From sdw at lig.net Sun Dec 20 13:50:10 2009 From: sdw at lig.net (Stephen Williams) Date: Sun, 20 Dec 2009 13:50:10 -0800 Subject: [FoRK] From Meccania to Atlantis In-Reply-To: <01bb01ca8183$d7211990$85634cb0$@com> References: <20091214164831.GL17686@leitl.org> <69ae910f0912161200g1e5e71actd9ac7f9de37277a3@mail.gmail.com> <4B29A0D2.3040607@lig.net> <01bb01ca8183$d7211990$85634cb0$@com> Message-ID: <4B2E9C12.40004@lig.net> Michael Cummins wrote: > Some fascinating reading here, to me at least. As of today Takuan Seiyo is > on part 13(2). He touches on a wide range of topics. > Touches on, but doesn't definitively reference. In these faux news days, that is highly suspect. > >From Meccania to Atlantis: Part 13(2) > http://www.brusselsjournal.com/blog/7745 > > > > This is the piece that caught my eye (reading feeds over coffee this > morning) though it is a very tiny part of the greater whole: > > >From Meccania to Atlantis: Part 13(1) > http://www.brusselsjournal.com/node/4158 > It is good to know what the Europeans (?) and the Chinese are thinking. That could come in handy. This page relies on this site: http://www.usgovernmentspending.com/us_20th_century_chart.html for the statement "But government spending in Obamerica is 45% of GDP, and its deficit stands at 43.3%." I don't understand where those numbers come from. Right on that page it shows: 2010 GDP 14240.2M, US Federal Budget Totals: 3.56T http://en.wikipedia.org/wiki/United_States_federal_budget > During FY 2008, the federal government collected approximately $2.52 > trillion in tax revenue. > Tax revenues have averaged approximately 18.3% of gross domestic > product (GDP) over the past 40 years, generally ranging plus or minus > 1% from that level. > At 15% of GDP, the 2009 collections were the lowest level of the past > 50 years. > During FY 2008, the federal government spent nearly $2.98 trillion on > a budget or cash basis. > During FY 2008, the U.S. government spent nearly $800 billion on > defense and homeland security, approximately 32% of tax receipts of > $2.5 trillion.[22] > > * Department of Defense: $741 billion > * Homeland Security: $52 billion > > The U.S. defense budget (excluding spending for the wars in Iraq and > Afghanistan, Homeland Security, and Veteran's Affairs) is around 4% of > GDP.[23] According to the CBO, defense spending grew 9% annually on > average from fiscal year 2000-2009. > In fiscal 2007, U.S. public debt was approximately $5 trillion (36.8 > percent of GDP) and total debt was $9 trillion (65.5 percent of GDP.) Perhaps the numbers made a huge jump in the last year or two, perhaps not. Too bad the articles don't have authoritative links, such as for this: > In 2002, the U.S. national debt was close to $6 trillion. By November > 2009, it had doubled to nearly $12 trillion. > -- begin quote -- > > The strongest, most admired country in the world until just a few years ago > is now a cautionary tale of the wages of sin and stupidity told to Chinese > schoolchildren. > Yadda yadda yadda. Good luck with that. Recent events are only about 5% of what it would take to be a death blow, if that. > A nation that works for a living can weather perhaps even such great storms. > But the jobs of the American lower class have been outsourced to imported > Who are now American lower class... And climbing fast. > Mexicans. The jobs of the American middle class have been exported to China > The mindless ones that should be automated away any day now. > and India. The jobs of the American upper-middle class have been taken from > the white males who held them by merit, and given to resentful identity > groups that hold them by the fiat of the government's preferred skin colors > Only goes so far until they have to perform, which they have been pretty much. > and favored genitalia. And the jobs of the American upper class have been > reprogrammed from leadership and service, to ripping off the less clever via > lawyering, banksterism, and padding one's golden CEO parachute, and then > That is becoming more difficult. Sarbox et al. > expiation via funding and leading socialist NGOs. > > A freefalling dollar cannot help by increasing exports, when you have > off-shored your manufacturing, and your main industries are predatory > There is still a lot of manufacturing going on. > lawsuits, selling shoddy American housing to Salvadorians with faked > mortgages, and marketing financial weapons of mass destruction worldwide. > And a falling dollar is not a good inducement for the world to keep buying > dollar-denominated U.S. debt. The cessation of that buying has such dire > consequences to the United States that Chinese strategists have named them > "the nuclear option." > The Chinese will be in a more delicate overall position than the US for a very long time. > The American people can't do anything about it either, except mailing tea > bags to the crooks and loons who govern them. Their only electoral choice is > between the party of demented progressives, and the party of progressive > dementia. > Huh, really? > -- end quote -- > There is a whole lot in Chapter 2: Barko... that sounds like fishy, shallow analysis. > The only true choice left is to get up and walk out of the circus tent. Does he know where Gult's Gulch is?? That's a cop out. Smart people can ride most waves successfully. Mistakes have been made constantly, especially for many years of the last decade. Most recent monetary mistakes can be corrected or at least learned from. One I just read about in the paper today is that the mortgage modification program is being gamed by lenders to get people to keep paying, then sell their house out from under them at the last moment with no notice. Apparently, part of the fine print is that notifications were being waived as part of the deal. If true, some banks should get slapped along with writers of the law. As far as economics from a different perspective, the SJ Mercury News had this today in the Globalist Quiz: Where "millionaire" is defined as: "an individual having investable assets of $1 million or more, excluding primary residences and belongings". Millionaires per country: US: 2,460,000, 1 out of 125 people Japan: 1,366,000, 1/90 Germany: 810,000 China: 364,000, 1/3700 France: 346,000 ... Switzerland, 8th: 185,000, 1/40 ... United Kingdom ... Brazil, 10th: 131,000, 1/1500 Australia Spain Russia: 97,000 India: 84,000 The Chinese state may hold a lot of assets, but their people don't. Stephen From michael at i-magery.com Sun Dec 20 14:45:13 2009 From: michael at i-magery.com (Michael Cummins) Date: Sun, 20 Dec 2009 17:45:13 -0500 Subject: [FoRK] From Meccania to Atlantis In-Reply-To: <4B2E9C12.40004@lig.net> References: <20091214164831.GL17686@leitl.org> <69ae910f0912161200g1e5e71actd9ac7f9de37277a3@mail.gmail.com> <4B29A0D2.3040607@lig.net> <01bb01ca8183$d7211990$85634cb0$@com> <4B2E9C12.40004@lig.net> Message-ID: <01cc01ca81c6$180fd940$482f8bc0$@com> > Touches on, but doesn't definitively reference. In these faux > news days, that is highly suspect. I found some of it to be uncomfortable reading as well, but it was still quite interesting. Mr. Seiyo didn't beat around the bush much. > The Chinese will be in a more delicate overall position than the US for a very long time. Why do you think that? I'm not challenging your assertion, I just don't know enough about it to hold an opinion. I *am* bumping into more and more Chinese companies these days, just doing business. From jbone at place.org Sun Dec 20 21:07:28 2009 From: jbone at place.org (Jeff Bone) Date: Sun, 20 Dec 2009 23:07:28 -0600 Subject: [FoRK] Stand up and face the future Message-ID: <272652A8-D280-4DE1-9257-C0AE119DE290@place.org> There's this occupational hazard we programmers, techie types, and similar geeks face as we ease on down that road to professional senescence... "Parallel programming? That's just like doing multi-tasking on big iron. We were doing that 10 years ago. More." That was my "systems analyst" later-to-be-ex father-in-law (first wife) back in, oh, '87 or so, when I was attempting to describe to him the difficulties faced by the company I then worked for as a system administrator in building a parallelizing Fortran compiler for one of the experimental parallel systems that were becoming available at the time. It was ridiculous for him to make such obviously moldy and non-current pronouncements then --- of course this is new and different stuff, Pops, you just don't grasp the difference because it's beyond your prior experience. You just don't get the *shift* involved. But as I ease my way ever deeper and hopefully gently into my third decade of (sometimes) writing software for money I find that this tendency tugs. It pulls. It becomes the easy out. We might even believe it: Been there, done that, got the t-shirt. Same shit, different day. No. Absolutely not. The only reason we think so is because change outpaces our puny ability to imagine the future. And then --- whammo. Over. This guy below, though... Whether or not the article is too long, is too windy, isn't particularly stylistically sophisticated, isn't particularly technically accurate, has too many errors of fact or language or otherwise... I don't know how old this guy is, how grey his beard or what his other credentials. I read the site; but I don't usually find it particularly interesting, useful, insightful, or news-breaking. It's sort of enterprise developer-ish. It tends to say what I already know, generally at a less-than-useful level of detail. But with this article, at least the author has had the courage and has made the effort to cast off some assumptions that may be convenient and comfortable but are prima facie false. At least he has had the courage to stand up and face the future, unflinching, and tell it like it is. I wish more of us did this. I wish I did more often. Read it: http://highscalability.com/blog/2009/12/16/building-super-scalable-systems-blade-runner-meets-autonomic.html aka http://tinyurl.com/y8ro8pl Enjoy. jb From michaelslists at gmail.com Sun Dec 20 21:28:01 2009 From: michaelslists at gmail.com (silky) Date: Mon, 21 Dec 2009 16:28:01 +1100 Subject: [FoRK] Stand up and face the future In-Reply-To: <272652A8-D280-4DE1-9257-C0AE119DE290@place.org> References: <272652A8-D280-4DE1-9257-C0AE119DE290@place.org> Message-ID: <5e01c29a0912202128h5f35dce1hf68f9173e28bf007@mail.gmail.com> On Mon, Dec 21, 2009 at 4:07 PM, Jeff Bone wrote: [...] > Read it: > > ?http://highscalability.com/blog/2009/12/16/building-super-scalable-systems-blade-runner-meets- > autonomic.html I'm reading this now (it'll be a few weeks before I'm finished ...) but one thing that I can't help but wonder immediately: Do we *need* "planet-scalable" systems? IMHO, the answer is: "No". I don't think everyone needs to use the same system, I don't think everything should be connected, and I think it's quite reasonable for there to be some reasonably-small limit on the amount of "things" a site can connect to, and I'm okay with various delays or limits imposed on a system due to it's nature (i.e. real-time). That said, I do think the article is interesting, but I don't think the motivation for it is "good", whether or not it happens. [...] > jb -- silky http://www.mirios.com.au/ http://island.mirios.com.au/t/rigby+random+20 SEMIMONTHLY NERVELESS sample cocoa permute serviette PUNCHER cyst underpart sparsely, BEHEAD:... From michaelslists at gmail.com Sun Dec 20 22:26:13 2009 From: michaelslists at gmail.com (silky) Date: Mon, 21 Dec 2009 17:26:13 +1100 Subject: [FoRK] Stand up and face the future In-Reply-To: <5e01c29a0912202128h5f35dce1hf68f9173e28bf007@mail.gmail.com> References: <272652A8-D280-4DE1-9257-C0AE119DE290@place.org> <5e01c29a0912202128h5f35dce1hf68f9173e28bf007@mail.gmail.com> Message-ID: <5e01c29a0912202226k1b41d274i4eacedc4f36ccf31@mail.gmail.com> Having finished the article; I think most of the ideas raised are old, and he even shows that most of it was brought up in an earlier article from IBM[1]. I just don't see the case for many applications needing to be planet-sized. Personally I don't want *any* planet-sized apps, but I could concede that some people may want some of them to be that way. But "most" work we do doesn't need that. To that end, I wonder what the motivation will be for people to have this "ambient" software installed on their phone, and give up time to do the processing. Because all processing power phones/computers are given, ends up being wasted by increasingly larger and more useless apps. It's not that each device is getting more data and power and not using it. I just don't see why people would do it. As to the other comments, about programs running the world, or at least themselves, by being programmed to make appropriate purchasing decisions on various data, which is obviously completely accurate?, being presented to them; well that just seems a bit too magically to me. Anyway, I suppose I won't continue to rant my point here. I do think the article is interesting, but not particularly new, and not particularly practical, and not even a nice goal to aim for, as far as I'm concerned. But who knows. Maybe I'll be left behind. Quite possible. -- [1] http://www.research.ibm.com/autonomic/research/papers/AC_Vision_Computer_Jan_2003.pdf