BonsaiDen

Very interesting concept as well as technical execution by encoding the whole thing into the PNG pixels :)

Also cool to see myself featured there, so in case you need another homebrew game with access to the source try https://gitlab.com/BonsaiDen/vectroid.gb

Considering that pretty much all multiplayer games in existence perform some sort of local prediction / state interpolation to hide the lag on the local machine, cloud only multiplayer will be considerably worse. After all you can no longer hide the lag locally, since you're not computing anything on the local machine, so the minimum precieved lag will go from 0 (for movement of your own player character) to the RT between the datacenter and your PC :/

I actually wrote a Asteroids "Clone" that uses Vector Graphics last year :) [0]

But I agree, tooling is complicated. I'm currently adding the finishing touches to the rewrite of my own Assembler / Compiler pipeline [1] and started work on a more "traditional" Metroid-like shooter, the sprite and map editor are both custom programs written in rust using imgui bindings and take care of the grunt work for generating all the data structures used in the game currently the dev efforts are 50/50 tooling/game though :D

[0] https://gitlab.com/BonsaiDen/vectroid.gb [1] https://gitlab.com/BonsaiDen/gbasm-rs

That however goes both ways, making it also far easier to install a dictatorship etc. because you don't have to replace tens of thousands of police officers with regime loyal ones.

We're walking on razors edge here, it only takes one "election gone wrong" and we might find ourselves in a nightmare with no escape.

Plus the fact that you can't directly write to VRAM at all times and have to wait for the corresponding access windows.

But it's also a big contributor to the general art style and gameplay limitations for which the games of that generation are known for.

However with a few tricks drawing vector like graphics is possible[1] (to some degree), even though it requires a huge amount of lookup tables to be anywhere near peforment :D

[1] https://gitlab.com/BonsaiDen/vectroid.gb

Factories in Orbit, pretty much. There might not be many products today which will benefit from this ability, but a free fall environment brings many benefits to things such as crystallization of materials.

For example, the last resupply mission of Space X to the ISS included an experiment to product optical fibers onboard the space station, the goal is that these fibers will have a much lower number of defects in their crystalline structure then their earth produced counterparts, this means less refraction, which results in less signal loss over a longer distance which reduces the number of repeaters which reduces increases the overall signal speed.

Now, of course if you wanted to deploy these things on a world wide scale you'll need to set up a bigger shop then the ISS - which most likely will go out of service within the next decade anyway...

And while the moon does not provide a free fall environment such as LEO, the gravitational influence is still much lower than on earth itself and scaling up on a surface will most likely prove easier in the long term than doing so in orbit around the earth.

They are simply ignoring the real world economic impacts though, which is stubborn to say the least.

The world is no utopia, and as long as money / economic gain is the utmost priority for most of humanity and its corporations, allowing widespread use of patented G.M.O.s will only cause more damage in the long run.

Imagine a whole countries population being dependent upon a companies patented seeds. Now add some secret courts implemented via trade agreements so the country is effectively unable to just "use" these seeds without paying up incredible amounts of money and suddenly you got yourself a situation where the country might end up under effective control by the company.

Yes there's probably still a way out of this dilemma, but with the right/wrong people coming to power through the course of action, you might quickly end up with nationalist government for which the most easy solution is out is a war.

Currently a lot of fincancial products can be created and managed in London, since once approved there, they are automatically approved in all other EU member states, too.

This of course will have to change once the UK has left the EU, making the people involved in these processes one of the first to be moved to Franfkurt etc.

It is actually the other way around. Internal producers simply cannot compete with external ones who can produce in multiple countries, in giant quantities at very low overhead cost and then sell reject goods for a very low price.

Africa has a big problem with this. Due to trade agreements, many European meat producers sell their "leftovers" into the African market at extremely low costs, which has lead to the demise of domestic producers of live stock. Which then resulted in a loss of jobs.

Yes, some people might be able to purchase things at a lower cost now, but some other people will loose their jobs and won't be able to purchase anything at all, which also negatively affects the domestic market.

For the outside producer is not a problem, they simply can move on. But kick starting a domestic market and bringing wages back up again will be huge issue for any government in the long run.

Compared to the current situation of writing a few lines and then having to wait for a vendor specific day one graphics driver update to have your game actually running at halfway decent speed, it is simple.

The current APIs are a giant collection for graphics vendor specific driver "fixes" which had been implemented initially to cheat in benchmarks, and then later had to be implement to fix issues which arose from those initial cheats. It is a giant, ugly mess.

Also 95% of game developers will never ever touch a single line of vulkan because the engine developers of Unreal/Frostbite/CryEngine etc. will handle all of the "dirty work" for their abstractions to run on top of vulkan. All without the need of trying wo workaround vendor specific bug fixes etc.

One could assume that they are either simply lazy or incapable of designing such a system on their own. By taking a look at their "index" which consists of one giant directory in a single GitHub Repo, one could indeed argue that it's a mixture of both.

There are so many (big) companies out there using cocoapads for their app development, getting a few to sponsor the hosting bills should be more than doable. A lack of funding is really no excuse.

This would definitely be very interesting in regards to language study. Repeating the experiment with people which are actively in the progress of learning a new language every few weeks could give some remarkable insight in how the new words are being mapped onto the brain.

Point here is, all of this doesn't matter. The market doesn't care about "ethics" or whatever. The market only knows one thing: Demand.

And it will do whatever it takes to satisfy this demand. If this happens to be "subscribing to your awesome streaming service", well then good for you! If not, too bad, the market DOES NOT CARE about you.

So you can now either spend your money on lobbying to get these people into jail or try to expand your market and get the people's money into your pockets. The latter being obviously the better choice for both you and your future customers.

This is mostly about linters, makeprg's and things like Ctrl+P / Command+T, git-gutter etc.

I recently switched to NeoVim and it really _does_ make a world of difference, saving is a whole lot faster when git-diff can be performed asynchronously and the ability to scan directories in the background makes fuzzy searching of files a lot faster.

For smaller projects I definitely agree with having both unit and integration tests, especially for libraries. One thing to look out for is the fact that you can always "cheat" in unit tests, e.g. you can be "lazy" and set up some internal state directly in the test to skip huge amounts of initialization, this of course becomes a problem when there's no actual integration test for making sure that the exact state can also be triggered from the outside when using the API. In my experience, ensuring that these cases are always covered can become pretty complicated once the project grows.

In our special case we have about 100 different endpoints all versioned and all dependent on multiple endpoints from the (rather badly documented) APIs of our customer. Most of the work our API does is spent combining / enriching the customers data and performing integration across the subresources. Setting up individual mocks for every single on of these complex requests flows manually is pretty much impossible at this scale.

So doing black box testing and enforcing a 100% test coverage (best for avoiding dead code) helps keeping us sane. In the end we don't care so much about how the implementation behind our HTTP response looks as long as we return the correct data in the end. The code itself still has to look good though :)

I in part agree with the pinpointing, though in my experience this really boils down to an issue of scope and how much of the data you want to test in each of your tests. E.g. an API returning user data, do you have one test for the whole set of data or one test per field.

For our use case we have some pretty "fancy" deep-equals logic for nested structures and allow to specific fields as "to be ignored" in our test expectations.

When it comes to speed, the most important part is to cut out everything you don't need, for us this means that our testing framework completely throws away the internals of Node.js HTTP layer. We never create a single TCP socket in our tests, which gives an incredible speed up. As a bonus this also allows to test timeouts and low level HTTP errors in < 1ms, since we can just return the timeout directly from the low level APIs and Node.js will invoke the timeout event on the http client handle.

> Running "noir:mock" (noir) task > ...................................................... > 1048 passing (10s)

And yes, that really reads 10 seconds and yes I always get a bit bored when I have to run the tests for one of our Django backends, feels like an eternity... :)

One good way to the limit breakage in such cases is to solely perform black box tests on the API level. In case of our Node.js based Backends we don't ever write a single classical unit test, instead we have a custom Framework built on top of Mocha which performs tests on the HTTP layer against all of our endpoints.

This works remarkable well in practice and allows for large scale refactorings under the hood with little to no impact on the tests. We can also mock databases, memcached, redis and graylog on their respective http/tcp/udp level. This in turn means no custom build mocks which could break when refactoring. The tests itself also contain no logic, they are pretty much just chained method calls with data that should go in and an expected response that should come out, along with a specification of all external resource our API fetches during the request and their responses etc. Any unexpected outgoing HTTP request from our server will actually result in a test failure.

As for scaling this approach, from our experience it works quite well, especially when you have lots of complicated interactions with customer APIs during your requests since the flows are super quick to set up.

Yes, they use AdBlock, but there's still a difference here, right now they're seeing the tweets of their peers in-order, with ads intermixed - which makes the ads trivial to filter out (bad for twitter, good for my friends).

In the future they might see whatever Twitter thinks is important to them, which might still be ads, but in the form of other peoples / companies tweets which just "happen" to end up in their "timelines".

Now, of course they can start blocking just about every company/user they don't care / like on twitter, but the effort might not be worth the gains at some point. And who knows, maybe you won't event be able to block some things from their algorithmic timeline, because that might defeat their monetization goals.

And yes, I realize that I might be reading a lot into Twitter's actions at the moment, but given how they treated their platform in the past year(s), all I'm seeing is that they want monetize it at all costs.

Most of my friends actually use it as a async, direct and realtime communications channel, pretty much like Whatsapp, just with more "social integration" (read: the whole internet).

They don't use Facebook because its algorithmic "timeline" isn't realtime in any sense of the word and they consider themselves more than capable enough to decide on their own what's worth their time or not, they don't want to be fed things / advertisments somebody else wants them to see.

They'll probably all switch to the next best thing available once Twitter's rumoured algorithmic timeline is to be introduced.

Personally, I left the whole Twittersphere way back when the alienated their third party devs, for me that was more than enough indication of the way they were heading. Nowadays they have nobody left who could actually come up with the Next Big Thing (tm) for Twitter, because all of their engineers are mostlikely busy trying to figure out how to commercialize the platform in the shortest amount of time in order to satisfy their shareholders.

The real problem here is the fact that there is missing oversight on these court orders, since it might be the case that the judge handing out the order does not have sufficient knowledge of the matter at hand and so there is a huge potential for misuse by the police or intelligence agencies.

In the end it boils down to the simply dilemma of choosing between either catching all "criminals" or protecting the rights of the people.

The latter way of course makes life a bit harder, since you'll never be able to prevent all crimes and people will potentially die, but people die all the time, since dying is a a basic risk of life.

The former way is essentially a rabbit hole, because it allows you to rewrite the definition of a "criminal" to just about anything you'd like and once you get a court order the "criminal" being is pretty much done with their life. This of course was and is still used in dictatorships of all kinds of sizes and employed by numerous secret police agencies around the world. Once there is a way to criminalize any action and then instantly "get rid" of that person, people who are going to use these powers WILL pop up and take over power.

Now of course in the short term no third party candidate is going to show up on the US politcal floor and take win a majority in the elections over night and then install a dictator system based on all the pre-existing powers by simply outlawing all other parties and anyone who objects to the new rulers claims. But 10 or 20 years from now things might be different and if we don't fight over abuse of the law and protect the general public we might end up in a pretty bad situation someday.

For anyone interested in the talks from the recent RustCamp, the videos are now available: http://confreaks.tv/events/rustcamp2015

Yes, nuclear power does have a safety problem, but not a imminent one. The real problem does not come from operations, but from the waste these operations leave behind.

Minimizing and storing nuclear waste are the far greater challenges than just running the plants.

Another problem is the question, who is going to pay for all that waste in the end? Well first off, most likely future generations and when we look at the current time frame, that's actually not as clear as one might think. For example, the German government has long struggled - and still is - to actually get the power plant operators to pay for the waste disposal. Before that is was pretty much "We get to make the money basically for free, and you pay for the waste." Which of course is also an issue with the argument that nuclear power is cheap, because in most cases the cost of waste disposal and final storage are not included in the calculation, because these things can just "happen later".

Waste disposal was way too long under the radar, so there was no pressure to develop new, better alternatives to the current reactor technologies for a very long time, since "state of the art" was just good enough, and cheap.

> We've also seen a _tremendous_ amount of interest from people who don't strongly identify as a 'systems programmer' at present.

Can't underline this enough, as a long time WebDev with a lot of JavaScript, Python and Lua experience, Rust really feels like a door opener into the bare metal* world.

Especially as a Node Dev I felt right at home with Cargo. And as someone who only rarely touches C/C++, having the compiler scream at me for the first 10 days or so was probably the best "tutorial" about memory management and ownership I've ever "read" :) Rust really made me think a lot deeper about who / where and when stuff will be owned and eventually destroyed.

Overall, the language, cargo and everything around them fit so well together, learning it has been a real joy so far :)

* Well I've also done Z80 assembler on GameBoy before but that's probably not what people today would consider "bare metal" these days.

The whole things feels more like an easy way of putting (more) people into jail than anything else. Since the tech crowd isn't running around on the street smoking their joints (well, for the most part at least) it's far easier for law enforcement to shoot them down via the help of some random audio file on one of their devices.

TPP is as much a political agenda as it is a trade agreement. The US wants their "standards" around the globe, so they can get you anytime, anywhere without you having any chance of defending yourself. You cannot build a global surveillance state if there are still people around which can potentially undermine you by use of technology, so you need to get rid of them in a "nice and clean" way, and charging some cryptographers for illegal music will produce much less public outcry as if you were to put them into prison for doing their everyday work.

How sad it may sound, Cameron could learn a lot from these folks :/

The standard should simply be changed to throw by default, but I guess the train has already left the station and so we're left with "bugs by design" before the spec has even been fully implemented by all vendors :(

But then again, in it's current "minimal" state of design, the Harmony Promises are inferior to any of the dedicated Promise A Plus implementations out there (e.g. Bluebird) and at least under Node there is little to no reason to use the built-in Promise object at this point in time.

Torture is by definition neither open (you're not going to tell the public "Oh we just tortured X") nor idependently verifiable (for this multiple entities would need to torture the same person for the same information), so this kind of evidence would be really hard to obtain.

Also given the fact that you can't know whether the person you're torturing for intelligence actually knows anything, they might (and probably will) eventually tell you "something" you want to hear, just in order for the torture to stop. At this point though, you'll don't know whether the information is actually viable, you still have to confirm it somehow, which might be difficult depending on what kind of information it is. In case of "The weapons are hidden at X" this is relatively easy to do, you send some agents to check that place out. In the case of "Who do we need to drone strike?" it's not as easy, because you can either kill them or not.

They are. Games are not recognized as art here in Germany, so they do not get the same treatment as movies or books and have to remove the references. International releases of these games are actually illegal in Germany and owning them is an indictable act, although actual criminal charges are very rare (since there's hardly a way of controlling the digital distribution).