![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizys
Originally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysExperiments with http://www.yooouuutuuube.com/ from last night (thanks Matt for showing me this):
Beware of epilepsy on the next few:
Some final meta-treatments
This tool reminds me of delay/reverb in audio, but in a video sense. Playing with this is like playing with NI’s Spektral Delay.
Originally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysOriginally published at The Ephemeral Notebook. You can comment here or there.
oizysSorry Zug but I have to repost this one… This is like my childhood colliding headfirst with modern marketing while 4chan stands by and comments. Other than the obvious memes the first thing I thought when I saw this is… “this is someone’s fetish”
Originally published at The Ephemeral Notebook. You can comment here or there.
oizysWhut.
http://news.livedoor.com/article/detail/4
Originally published at The Ephemeral Notebook. You can comment here or there.
oizysThis is my first auto-post by my google shared-items, so it looks like it’s cleaning out some older stuff. I will post links weekly, and hopefully next time it will format in my comments correctly.
Originally published at The Ephemeral Notebook. You can comment here or there.
oizysThis is a futurism exploration and a fun example of turning it into a game based on my last post. This is largely inspired by Jane McGonigal’s inspiring talk at GDC this year - about how game designers are the reality hackers of the future and how we will be called on to solve problems. So here goes:
In the theoretical future, a major data collapse happens. A single service like Amazon S3 or one of those services to back up your personal data online falls to a natural disaster, manmade disaster or virus. Much like trust in the banks is an issue today, trust in services becomes an issue. It’s also just a plain-good optimization pattern, disaster or no, but sometimes people won’t move on something until after they should’ve so I pulled this scenario out of the blue as an example.
My solution is the cloud storage game. It’s also sort of a cloud processing and cloud throughput / latency solution (see last post) but for simplicity of example sake I’m going to focus on storage. It’s based on parity-driven data storage and delivery models like ZFS and BitTorrent. Let’s say you take a picture on your phone - it needs to be stored somewhere. It will of course also be stored on your phone, but that’s not enough because phones die and the data is lost for good.
Instead of storing it somewhere you store it ManyWhere (my name idea for this). A number of possible storage vendors are all available for you to store this data with a single API (ManyWhere API) bridging their APIs. However, as with all these systems, these cost money (in the cast of S3, transfer, request and storage over time are all charged). Also there’s the trust issue. Here’s where the ZFS-ish part comes in. You have some thick hardware lying around - so do your friends and people you would trust to hold onto something. Through a simple provider interface, they will store some of your data if you store some of theirs. So now when you store something you have a list of places it will go and a cost threshold. It will go to ALL of the places below the threshold. Imagine data being stored (in an encrypted or parity form of course) across your entire social network.
Now while companies charge money for this, your friends instead charge points. By providing storage or processing power for your friends you amass points from them. Your points are visible as a ‘who owes you’ breakdown as well as an amass of total points owed to you. You proudly display this on your social networks as a form of social capital realized. Other friends-of-friends can see that many other people trust you with their data, so you must also be fairly trustworthy. Local social networks and large groupings have leaderboards (this is again all based on offering up spare storage and cpu - so it’s of no real cost unless you decide to be philanthropic). In addition the number of parking wars -esque games that could be created on top of this is pretty epic.
Ok, now we bring the companies back in. Companies can be both sources-of-last-resort (trust * cost = social cost) - if you trust them enough and their cost is low (or nothing) they might also make it in past your threshold. On the reverse side, companies may need storage or processing needs to offer in return for points. Those points may be microtrans equivalent values (virtual currencies) which may be redeemable by them or by partner vendors. For example, provide some extra CPU for big internet company A, redeem some virtual goods from MMO company B (a partner of A). The leaderboard concept still applies and is already gamey (SETI and Folding are two projects doing this RIGHT NOW with no direct incentive).
The end result of all of this would require a descriptor system (looking at you bittorrent, zfs), and would require that this be either decentralized (a DNS-like system or extension would work), or a part of a service (whether hypothetical company ManyWhere, or more likely a partner project with someone like Google). However the ramifications are - less traffic and latency all around (using the description which is easily cacheable, you could always pull from a close, often local data/processing source), less storage and cpu costs for society in general (we’re not likely to ever move to a word of only thin clients - and due to that there are trillions of FLOPs and Gigabytes lying around dormant), a visualization of social capital mechanics (likely to breed its own decorum, but you can base some value decisions on it regardless), and an incentive for people to provide help to causes they care about (no one has to provide cpu to NastyMarketingCompany but many would choose to offer up social capital for HelpsFeedTheHomelessOrg).
There are some obvious technical limitations to the processing side (universal language - though that’s relatively solveable by bucketing the service into platforms), but the storage side is something people could work on NOW, so I think it at least deserves a PGI award (Pretty Good Idea). [Edit: This also requires to a certain degree an embrace of OpenID or something like it. Not from a technical side but from a society-accepting-distributed-trust-brok
What do you think, internet?
Originally published at The Ephemeral Notebook. You can comment here or there.
oizysThere has been a lot of talk about Onlive.com and their stellar presentation at GDC. Instead of discussing the intracacies of their technical limitations, the business model, etc - I’ll start by sending you to Dave Perry’s accurate depiction of my thoughts on the matter. I will instead start with an alternate present time scenario for kicks:
The year is 2009, Microsoft never entered the graphics acceleration fray with Direct Draw and instead adopted Open GL (I know, lol). Open GL over the years gets many extensions driven by the games industry and Microsoft’s foray into it. A lot of work is done to maintain a steady state in video memory so that new data flushes were required less often (extensions for animation, culling and scene graphing) - due to the fact that the curve of memory costs increased far faster than the cost of bandwidth (due to buss switching and such, see also DMA channel 0, etc). This focus on throughput optimization leads to a revelation and a very different form of OpenGL ES. An Onlive-like service shows up (they’re not the first to do this by far), and instead of pushing HD pixels compressed, they’re pushing standardized commands filtered by a recognition of what the output device is. The television manufacturers or the cable/dsl boxes add in a graphics card to turn the commands into video. Phones are able to run the same way, with pixel resolution handled by the phones - so yes, hook up a bluetooth gaming pad to your phone and play Team Fortress 2 on it. Now the problem is flipped on its head - throughput is no longer quite the factor is was and now memory is the issue (one in which we are currently excelling at progressing). Also, the business is a distributed issue now: ISPs provide graphics hardware in their black boxes (which has a planned obsolescence - a cherish business model), and partner with gaming companies, as they’d still likely want to house servers in their NOCs due to latency. Now you don’t have on large company providing the ’service’ (Historically, systems like Onlive which require absolute adoption and ‘cannot fail’ have been trumped by systems which allow failure to happen iteratively and distribute the cost of such failure).
Ok, so enough fantasy - that scenario obviously didn’t happen (and I could even point out a good many reasons why) - but it’s fun to speculate. The base issue is an optimization one. For anything digital it tends to be: Memory - Processing - Throughput - Latency, with the last one generally intertwined with the previous three, so you could for simplicity sake boil it down to Memory - Processing - Throughput. Much like other optimization triangles (Cheap - Good - Fast), the optimization patterns are typically: ‘pick 2′ or ‘pick 1′. My above scenario was based on a Throughput optimization as historically it has the worst progression curve. This optimization triangle is very interesting because we’re constantly playing with it. The thin-client/thick-client ‘wiggle’ in history has been a product of this. Back in the 70s when memory and processing were expensive, thin clients (terminals) were the norm. In the 90s there was a huge shift from processing to memory (with more caches, etc) as the price of memory plummetted.
Now the issues are less technical and more political - Trust, Social Capital, Privacy, Security, Availability. The problem with the thin client isn’t really a technical issue so much anymore - it’s an issue of trust. To describe the thin/thick issue another way, there’s the war between Distribution and Centralization. Except that issue is largely gone - even our Centralization is distributed at this point. Our centralized data isn’t often stored on a single server - and in the future (or present depending on the service), it isn’t processed on a single server either.
A possible dream for the future (in ARG game form!) is my next post (seperated so this isn’t a TL;DR).
Originally published at The Ephemeral Notebook. You can comment here or there.
 |
You are viewing oizys's journal Create a LiveJournal Account Learn more | Explore LJ: Life Entertainment Music Culture News & Politics Technology |
