dmytroi

Being free (or open) source have nothing to do with security: Linux/BSD still have 0day rootkits, yet all source is available, modern JS software have all tracking in the world, yet all source is available (VSCode telemetry). Even RISC-V, being fully open, most likely will be susceptible to spectre attack.

Instead of false promises we need to develop better engineering: verification, computational math, etc. And also laws - no free/open license in the world will stop companies from tracking, but fine as big as 4% of total revenue (EU GDPR) will make them oblige.

I agree, it's not as simple as yes/no. I find that creating new software usually is not that expensive, but maintaining it is: dependencies update, new language versions, new formats, new requirements, etc. In my experience burden of maintenance is often more costly then budget for initial development. Maybe that case could empower more people to consider contributing to open/free projects.

Fully agree with this. I know people who were developing 3G/4G base stations at Ericsson, and as they say: the only right way to check if implementation is correct - to test if your phone connects to it or not.

Honestly, I don't see how open/free software can fix it. For example google analytics is commonly used through web, source code of the tracker is available as raw text in javascript, and where is the promise of open/free software? Sure one can install tracking blocker (like ghostery), but just because the track itself is open source (most pages source code is accessible as raw text) - tracking hasn't been magically fixed for web, and people still play cat-mouse with track blockers. Given this example I don't see how making something open source or free software suddenly fixes that. Indeed, yes, it does makes it easier to audit software, but that's about it. One might say that one can personally audit all the source code, but there is practical limit to how much we can do it - a common system might run 20k+ packages with million lines of source code, and even if we trust all major dependencies, tracking can always sneak-in through 3rdparty libs, downloadable code (aka js), etc.

In my opinion a better tool would be a legal framework to limit companies what they can and can't do. For example EU GDPR is much stronger factor in limiting what companies can do with personal data, and it forces companies to provide opt-out option (and proper opt-out, not like "we use cookies, if you don't like - please leave"). The reason why EU GDPR is not a joke are fees - 4% of global revenue (or 20 million EUR, what is bigger), so companies are forced to comply. I would love to see a proper legal framework for opting-out from tracking, but looks like it will take another 10-20 years to develop it :(

Yes, but it's not as obvious as it sounds. For example let's say we have dev A and dev B and we give them same task. Dev A solves the task in such way that we don't need to come back to the solution at all, it "just works". While dev B solves it in such way that now we need 1+ devs maintaining a solution full time. Any solution that needs to be maintained full time is a form of job security. Sometimes it is needed (like placing a small team on devops), sometimes it is not (like in-house full time development of dashboard frameworks).

Nice post! I worked in a few big and small companies, and from I can see software companies with more then ~40-50 devs don't scale well (I only talk about about single-ish product software companies here). The reason for this is in my opinion is absence of financial liability of devs: if you're a dev in a company with 500 other devs - most likely you have zero financial liability to produce great code, on other hand you have all time in the world to create job security code around you. Also if there is 500 devs on one project, most likely one will see a lot of infrastructure just to get this devs busy with something. This could be seen in companies were one department creates "the framework", and others departments create "features" based on this framework. In this case there is no "market" of frameworks - you basically stuck with it, and "the framework" has zero market competition. Compare it to normal market of middleware - if your framework is bad, I'll just go to your competitor. Free market is much healthier situation in my opinion (could be a strawman argument though). I am not wise enough to say that creating internal competition inside one company is always good thing, though financial contracts make a healthier political discussions.

After moving to Stockholm, Sweden at least 3 espresso based drinks per day (mostly cappuccino), sometimes up to 5-6 cups. Winter is hard here.

Make provides awesome UX: in most cases you just type "make" and stuff just works, but there is a tradeoff: it's nearly impossible to write a crossplatform make file. Why you ask? Try copying a file (or directory) from one location to another, sure "cp", but it's -R is different on Linux and macOS! And then comes Windows - there is no good built-in alternative to "cp" as it's hard to make "xcopy" to ignore failures if target file/directory already exist (it tends to ask if you want to overwrite it or not), WSL might fix that in the future, but currently it's quite slow on IO side of things. So, sure given enough time and kung-fu we can write crossplatform make files ... but even if copying one silly file is such PITA .. it's hard to advocate for make in 2017. Probably the wisest solution is just using make to run something more comfortable, for C/C++ it can be cmake, premake, tup, etc. But then again: if I need to add something, like another build step, do I add it to the tool of choice or make? It's a very hard balance to sustain.

PS. Copying files specifically is such huge PITA that cmake implements crossplatform copy for you, just run "cmake -E copy $in $out" (can be added as add_custom_command in CMakeLists.txt)

It highly depends on a direction, see https://en.wikipedia.org/wiki/G-force#/media/File:Human_line...

Great question! To make things even more annoying - C doesn't have namespaces. So people are forced to write long names like "my_struct_hash_map_t" everywhere, which makes all modern C code look like wall of text (compare too older style code "mshm_t*a = hmalloc()"). To answer honestly - I'm asking myself very pragmatic question: "do I really need a generic code?" much more often compare to C++. In game development C++ templates were used mostly for math libraries (2d/3d/4d vectors, matrices, etc) and containers (hashmap, lists, etc). If we look closely on math libraries we can make a compromise "just float is enough", and if we make such compromise then everything is simple - one don't need templates for math lib anymore, I'm currently using "gb_math.h" [1] and it works pretty good. Containers on the other hand are more challenging, the key here is to understand "can I make this work with linear (maybe static) array?" - and in most cases yes, then you don't need any containers because just arrays will do. If algorithm specific do require a hashmap or list, well, gonna use what we have: macro! It looks weird, and it is weird, but something like khash.h [2] works fine in production.

In reality what it means for me is that I need to spend time making decisions about containers, which is good for game development, as what makes games fun doesn't have any connection to templates. But it also bad for casual non-game related code. I find it much faster to just "hey load this json, do some processing, and save json back" do that in Python than trying to do in C just for sake of C. Ideally namespaces/templates and operator overloading in C would solve all this struggles, but then where C ends and C++ starts?

- [1] https://github.com/gingerBill/gb/blob/master/gb_math.h - [2] https://github.com/attractivechaos/klib/blob/master/khash.h

One of the reasons why I switched from C++ to C professionally (I do C for living) was build times: previously kind of big casual game took 5-10 minutes to compile and around 10-20 sec incremental build, and now my C project takes 5 second to compile from scratch and around 1 second to do incremental changes.

Another reason being that I don't need to waste time discussing and arguing which OOP patterns to use - in C it more or less fixed how you write code. Of course one can go extra mile and reinvent VTable and Dependency Injection, but it feels all foreign to C.

So maybe give C a try, it's amazingly fast to compile and link, yet you feel almost at home after C++.

This! I've started to look for usable vector image format for game development somewhere in 2004, now it's 2017 and there is still nothing available. For SVG you literally need to pull-in whole browser engine, which is most likely 2-3 times the size of your whole game.

But can you reuse UX? UX on Android and iOS are completely different, which implies different UI, which in the end of the day implies different codebase. I do believe that it's possible to implement an app indistinguishable from native with any technology given enough time to implement all UX guidelines (voiceover support, animation dynamics like scroll list velocity constants, disability stuff, etc) but than we spend too much effort reinventing Cocoa Touch, so ROI of this endeavor is highly speculative. I hope in the future iOS and Android will be closer UX wise, which should simplify code reuse and make everyone happy.

Glad to see one of the best C++ IDE's getting even better. The best part of it: even after all this years of active development and improvements it still feels very lightweight, it's more like sublime in terms of speed, when other comparable (by features) IDE's are feeling very heavy and bulky (like Visual Studio for example).

The only thing I would love to dream of is to Qt Creator have a better stand-alone support, now it's completely and fully integrated with Qt ecosystem, and that's really nice if you use Qt, but when I'm trying to convince my co-workers to give it a try, the getting on-board curve is a bit too much. Though this being said: it become much better in last years.

You can make a pong game easily on FPGA and VGA output, no CPU needed :)

Awesome! This is also very visible in touch based interfaces, especially in scrolling. I did a video with high speed camera to show how laggy real interfaces are https://www.youtube.com/watch?v=8EhJo2OPR44

Uber as an experience is nothing new, IIRC eastern Europe had this model for ages: the company accepts client requests, the company posts request to drivers, fastest driver accepts and gets the requests, after the ride client pays drivers directly (usually cash only), driver pays % to the company. This was first implemented with pagers + mobile phones, than with sms, than with j2me apps, and nowadays with android apps usually. So the taxi company is just a proxy, and there are all kinds of flavor available: illegal taxis, virtual companies, etc.

The only things Uber did: great UX, wide availability in the world (you use the same app everywhere), possibility of deferred payments (aka ride now, pay at some point before next ride) and driver ratings.

As usual with any infrastructural international project: whoever goes first and behaves boldly - will stay for quite some time, see PayPal, Visa, eBay, etc. One can argue that Uber is not perfect ideologically on paper, but any reasoning "why we should make replacement for Uber" are doomed because ROI is simply not there, while struggles to forbid Uber are also doomed - you may block the company, but you cannot forbid better UX, so Uber is already here to stay.

In the end would be better to change discussions from "top 100500 reasons not to do something" to "top 100500 ways to make something better". There are concrete things available how to make Uber better, but instead everyone is just trying to forbid/destroy/etc.

Not a blind dev, and would love to help community as much as possible, though I don't even know where to start :( Would be really helpful to have centralized place which directs developers effort to valuable open source projects.

Another interesting idea: try using braille screen for ourselves, so we as dev's will be able to work at complete darkness without any light :)

Currently Sweden is on a race to be first cashless society: many shops completely stopped accepting cash (many also started to use iZettle [1]), people usually simply don't carry cash with them, and if it happens that you need to send money to other person: Swish [2] is to the rescue, which is direct bank-to-bank money transfer system for small amounts.

On other hand everything is traceable, you can call tax office and ask who is get paid what, if you want to know where the person lives: just hitta.se them by name, you will also get avg income for household there.

- [1] https://www.izettle.com/ - [2] https://www.getswish.se/

C already survived 44 years, so only 84 to go :)

Well, considering game industry experience with OpenGL on Windows (which is in short - it doesn't work on production scale) as a game developer I, unfortunately, really doubt that it will gain any traction on Windows based platforms.

I might be harsh to say it, but current vulkan/spir-v tooling is more like a toy than production ready. If one need to convert HLSL to GLSL then one probably will use something like https://github.com/James-Jones/HLSLCrossCompiler and IIRC one place just used advanced macros magic to make HLSL and GLSL from the same source code :)

So first you develop your game for Windows on DirectX, and than you make a port to OSX/iOS/Android using OpenGL, and than if you're lucky you make a port to XBox and PS4, maybe WiiU. Graphics pipeline rendering code is really small and simple part of any game, usually in big games you do have different render code for different GPU series or/and platforms, but it's much smaller in comparison with everything else.

What's big and bulky - shaders themselves, but there are solutions to translate them between different available languages.

Of course they do, but under NDA, just ask. OpenGL on top of whatever GAPI is on target platform is usually <100 KLOC, so completely possible to write your own if you REALLY need to (really is when your 1kk+$ budget game will fail just because there is an engineering problem).

And if you don't have resources to ask/communicate than just use something like https://github.com/bkaradzic/bgfx/ which is an awesome API agnostic rendering library.

What's annoying for me that's for other people (non-asylum, non-EU) the system is very bureaucratic and usually not so supportive, for example for someone from post-soviet country it might take up to a year to get a working permit in Sweden. Even if you apply for EU blue card it doesn't help much. But for asylum applications there is a "fast track" with all support possible, sure some part of them are fleeing from war, but some (or even probably most) of them are just economic asylum seekers, just check last statistic from Sweden [1].

It might be safe to assume that economic asylum seekers are looking for better life, which is fair and reasonable, but in this case the system is broken : why economic asylum seekers should get easier/faster/priority process over workers from non-EU countries, or why workers from non-EU countries should even bother with immigration process if they can just apply for asylum and be done with it?

- [1] http://www.migrationsverket.se/Om-Migrationsverket/Statistik...

I might be too old fashioned, but the only case where some sort of memory management is pleasant and comfortable - constructing/modifying strings, though even here many languages separate mutable and immutable strings into different beasts.

In all other cases just allocate virtual page from OS (way too old school I understand, people usually don't use this one and believe that C Runtime Library with malloc is the only "approved" way to allocate memory), you get from 4kb to many megabytes of continuous memory - do whatever you want there, and deallocate whole virtual page later on, no leaks, no problems. Sure I do understand that manually managing millions of objects on heap is hard, but managing 1 to 10 virtual pages? it's simple and easy, just forged about generic allocators and use specialized ones (like block allocator for example).

Also it's good to know if you even need to deallocate at all ... for example ninja build system (https://ninja-build.org) simply doesn't deallocate memory after build is done, just because it's too slow to do it (though they do use heap allocations), just kill the app and OS will clean up after you.

PS. On other hand what I'm saying is just a personal rant. Reality is that the industry is mostly moving to tools that don't allow writing unsafe code (for example languages without pointer arithmetic), and this might be very limiting in language expressiveness. There is an another approach - statically proving that unsafe code is safe. This is what "Checked C" is all about, and this is how Windows drivers are working without crashing the kernel (at least BSODs are pretty rare on Windows nowadays). But I do agree that tools for statically proving unsafe code are so non casual that only greybeards are interested in them nowadays :(

Might be unpopular opinion, but I kinda like to look how people introduce will-be-a-problem-in-the-future things (let's say GC) and than heroically are solving following problems (pause-less GC), it's like Don Quixotes of modern age, except you build windmills yourself.

Qt was really stable for last years, indeed Qt 3.x -> Qt 4.x was a painful migration, but they learned their lesson and Qt 4.x -> 5.x was pretty much as smooth as it gets. For simple apps you can mostly migrate from 5.0 all the way up to 5.6 without changing any lines of code.

Far Manager http://www.farmanager.com/index.php?l=en - works perfectly, still have this Norton Commander feeling from 80-x.

Yeah, but there is no "fast JIT" on iOS and PS4 (not sure about X1) at least because they forbid creating memory pages with "Executable" bit, so usually AOT compilation is still ftw in game dev.