wladimir

If you make your demo to work on one ATI card you will have a small audience at most, and the card will be out of the market in a year and all the tricks you learnt were for nothing. And if you want it to work on more hardware you get into the device driver business, and that rules out special tricks for specific hardware to do non-standard rendering anyway...

Back in the days of home computers there was one longer-lived hardware platform that many people were using. There is a faint hope that initiatives such as the Raspberry Pi may bring people to "standardize" on one more or less ubiquitous platform for longer time, but I'm afraid this ship has sailed. So it makes sense for demosceners to focus on what is possible on the higher, portable API level.

The problem is that one person cannot possibly learn about everything. One has to make choices. If you spend time learning graphical design rules, you cannot use that time to learn some new algorithm, or how to do business, or some other thing life asks of you. The idea that everyone can be a jack of all trades is equally misguided. I agree that learning everything around your trade up to a certain level is a good idea (to have a clue what people are talking about), but people that specialize in an area tend to underestimate how much time it took them to become experienced in that area, and trivialize how easy others can learn to be adept in their area of expertise.

It makes me think of a bit of a Matrioshka Brain structure (for example from the Alistair Reynolds story Troika), with a star and surrounding shells that capture ever more of the light.

Technically, it takes a similar approach to "real time" raytracing as the cycles render engine in Blender, increasing the number of samples (thus decreasing the noise) over time.

The topology reminds me of this paper "The Landscape of Parallel Computing Research: A View from Berkeley" http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-18...

https://en.bitcoin.it/wiki/Hardfork_Wishlist

Of course, none of these are major economic changes. To quote the article "Please don't list anything here which would significantly change the committed overall economics of the system, it's safe to assume anything with significant economic impact will _never_ be changed in Bitcoin, because such changes would undermine the trust people have in the system, though they may form the basis of an interesting alternative chain.".

A recent example of a change that affects the P2P network, but not the block chain, is the use of bloom filters to make more efficient (but still secure) light clients possible.

A length field doesn't mean that you have to pre-allocate that amount of memory. Never do that! Robust implementations use the length field only as a hint, as an hidden delimiter, and allocate memory as the data comes in.

That said, she does have a point. Though escaping is fraught with dangers, too (remember PHP in the beginnings? magic quotes, ugh).

Especially when you don't have your own backups of the data, as usual with these kind of services. Outages, unexplained data loss, services being shut down, users being locked out for unrelated reasons (oh you didn't put your real name in G+?), unexpected changes to the interface and software, the list goes on.

The vendor lock-in is even worse than when using closed-source software with DRM. At least you can keep running those (if necessary in an emulator) when discontinued, or reverse engineer them...

I don't understand what you mean by "easily broken by revolutions". I also don't see what is bad with a wider perspective, unless it is somehow restricted to "bad people" (the classical panopticon?), but that'd require a very centralized system.

What I proposed was something we (as in people with intimate knowledge about these things) could do to make this better. A lot of technical people are content with being high priests, and a lot of "consumers" content with not understanding what is going on. It may be possible to change that, albeit slowly.

Looking beneath the surface level hyper commercialized pooha, there are quite active developments by in distributed protocols, mesh networks, cryptocurrencies, and people working on technology that is open and can meet basic human needs (for example see http://opensourceecology.org/wiki/Global_Village_Constructio...), and so on.

Another thing is that centralization makes things fragile. Even though centralization may be more efficient at first glance, once centralized systems collapse enough, people will look for more decentralized solutions.

All we can really do is make sure that technology, and knowledge about it, is more evenly distributed, so that central control is more difficult: make sure it isn't seen as kind of magic to people that they deem is impossible to understand and out of reach to them. Technology is simply a set of tools and should be regarded as such.

Centralized technologies with easily controlled, single points of failure are by far the most dangerous, and the most attractive for oppression. This is why DRM, for example, is really bad. It lives by obfuscation and being hard and/or undesirable to understand.

As for a big impact on the value of bitcoin, I don't think so. Bitcoin has the networking effects for now, many people are working on accepting them. It may be that the additional cost of accepting, for example LTC is lower when already accepting BTC, but BTC has a large first mover advantage.

https://bitbucket.org/pypy/compatibility/wiki/Home

I'm mostly missing Qt GUI support myself. Hopefully cppyy (http://doc.pypy.org/en/latest/cppyy.html) matures, as then it will be possible to use C++ libraries automatically without none or very little binding work.

Note that I'm not saying they did this, or have good reason to. It's just that I'm a bit suspicious of anything Anonymous related after the Sabu/Lulzsec story, especially when it relates to propaganda like this.