dmytroi

Some parts of anti-nuclear movement hold a position "ban nuclear no matter what". But for example, what happened in Germany, is nuclear plants being replaced by coal and gas plants.

Then discussion moved to if nuclear plant will be replaced by coal plant, is it really that better in the end? When faced that question, it was observed that anti-nuclear movement splits, where one side thinks that nuclear makes sense to stop coal, while another thinks that we must ban nuclear even if whole planet will die from climate change.

This is why, at least in Germany, some parts of anti-nuclear movement can be perceived as somewhat radical.

I've took it from [0]. It does seems like numbers are very approximate everywhere, but even than, let's take 29 trillion and distribute it between 327 million population: we get 88.6k$ per person, still not enough to buy housing in most parts of US.

- [0] https://www.businessinsider.com/the-1-percent-dont-know-what...

Numbers don't match though. It looks like there is physically not enough money to buy everything that is sold. For example:

- There is a ballpark estimate that sum of all physical money in the world is 90.4$ trillion, let's distribute it equally to all 7.53 billion people: we get 12k$ per person. This is not enough to buy an apartment in most parts of the world.

- There is an estimate that 1% has 303.9$ billion, let's distribute it equally to US population of 327.2 million people: we get 928$ per person. Barely enough to buy status smartphone.

So I don't see how wealth distribution can solve anything. Even if we equalize wealth and prices at a same time, free market will quickly spiral down to similar pricing that we have today (things are barely purchasable, or not at all).

I'm learning how to fly, and tell you what, cognitive overload is real. At first students have a hard time to coupe with stick/pedals, airspeed indicator and looking around for positioning / avoiding other planes. Having a "moving map" that tells you in which airspace you are exactly and where you're going - priceless. Simply because beginner students don't have cognitive capability to comprehend everything at a same time. And as experience grows, cognitive load required decreases, so people have easier time to read paper maps as they progress. That being said, in emergency fewer things to worry - the better. If primary instruments fail (airspeed / attitude / etc), one doesn't have mental capability to deal with instrument failures AND deal with paper maps at a same time.

This is directly transferable to road driving. For example when switching sides of the road: going from France to UK, and suddenly it requires immense cognitive load to adapt to drive on left side (unless previous experience). Or different road standards, for example in Italy highway on-ramps are like 50 meters long (and road switches from 30-50 to 80-120 kph), which most people are unprepared to.

So while yes, GPS might take away some, but it's very nice to have under high cognitive load.

Maybe. What we know factually at this point in time: osxfuse was BSD licensed, Google used it and haven't contributed back. osxfuse is popular project.

If it was GPL licensed, do you think Google would bother to use it? Or would they write their own instead? Would we even know about osxfuse then?

MIT/BSD is amazing on bootstrap phase, when getting code used and building user base is top priority. Monetization always comes later. Using GPL from the start might just turn your first users away and you might never manage to get critical mass of users to be able to monetize product at all.

In this particular case we don't know if there were any other previous attempts at financing it, like have maintainer contacted Google to provide consulting services? Or provide enterprise support to other parties? etc.

I'm starting to use TLA+ to verify lock-free algorithms. The tool is essential when all your code fits on the screen, yet you can't comprehend what is going on and miss a race here and there.

So far it's more a personal interest, but I'm advocating for spending more time verifying critical pieces of our code base like MPMC containers, synchronization primitives, etc.

PS. Doing C/C++/C# in gamedev.

I'm referring to a fact that before economical needs created unified time / measurement system / language, each region had their own language-dialect. For example Gallo-Romance languages and so on [0].

- [0] https://en.wikipedia.org/wiki/Languages_of_France

As someone living in EU, there is a practical limit to this. Languages NEEDS should be satisfied: For example, a translator should be provided to someone not speaking common languages (for the area) trying to get medical care.

But language WANTS might not be economically viable. For example in Scandinavia, Sami people (estimated population <100k) demanded all government interaction (documents, services, etc) to be translated in all their dialects (there are 11+ dialects, which are different in writing). Amount of work to be done to support that request would be astonishing.

Ironically the same true for French. There are 20+ very different dialects, is Quebec ready to work in all of them on government level? Or are we talking about le français standard?

So there is some practical limits to this, and so far EU is handling it's ok-ish. EU-wide systems are available in all official languages of all members, and minority languages are embraced when practical.

Quick google shows that recycle rate is ~30% for PET bottles in US in 2015 [0]. Not obvious if the problem is that customers not returning/recycling bottles or that garbage just gets landfilled.

Compare that to Nordics, where Norway achieved 95.4% return rate of PET bottles (~0.3 USD return cash-back), and Sweden 84% (~0.15 USD return) [1]. Most countries in EU have landfill ban [2], so most of waste is either burned or recycled. Diverting bottles/cans to return scheme solves garbage sorting problem, which makes it possible to process/recycle 100% of it just by improving recycling facilities.

In my personal opinion, closed loop systems (full ban on landfills) are better for everyone, but require deep systematic changes, potentially using "dirty" psychological tricks, to get done what's really needed. Adding deposits may sound negative from NIMBY/corporate, but it leverages human psychological on last mile (where garbage sorting is easiest) and from empirical evidence achieves what needs to be done.

- [0] https://www.epa.gov/facts-and-figures-about-materials-waste-... - [1] https://en.wikipedia.org/wiki/Container-deposit_legislation - [2] http://www.cewep.eu/wp-content/uploads/2017/12/Landfill-taxe...

Using heap as sole savior of stackless coroutines just doesn't scale. I'm working on a game engine, we can have 10-100k+ jobs running per frame, modern monitors have refresh rates of 144/240/300 Hz, so worst case: 30 million jobs per seconds! There is no time for heap - is just too slow.

So we need to preallocate everything for all systems, but hey, if you preallocate everything for worst case - you are out of RAM (on PS4/Xbox/etc).

What we need is a mix: scratchpad memory that lives longer than stack, but costs as cheap as stack. Tagged heap with stack/arena allocator comes close performance wise but not ergonomics wise.

Ergonomics of writing code with such constrains is very painful. Stack is the most ergonomical/fastest scratchpad you can have, and as soon as you have async/await/etc in a middle of your function - you need to think about unwind/rewind of every stack variable.

I guess that is an artifact of 5 bit encoding (invented in 19 century), as all zeros define NULL, see [0].

- [0] https://en.wikipedia.org/wiki/Baudot_code

Yes, but users rarely see real amount of virtual memory used (reserved, committed, etc). For example Chrome rendering process right now on my machine uses 267 MB of physical memory, 478 MB of committed virtual memory, and 2.1 GB of virtual address space.

So as you can imagine, total address space reserved on a machine can easily go into terabyte range. But that doesn't matter because every process get it's own lookup table.

If by aio you mean Posix aio - on Linux it's implemented with user space threads and blocking I/O. Posix aio on BSD systems is implemented as kernel space thread (aio_write/etc are syscalls on BSD, and glibc functions on Linux).

If you mean io_submit, then yes, but in vast majority of cases, actual `io_submit` syscall will block, because of metadata updates, unaligned reads, etc ...

Yes, IOCP looks like true async I/O most of the time. While in reality it will block if file is cached, in cases if code tries to read something like 100+ MB at a time ReadFile calls can take 200ms+. So most "async I/O" frameworks have to wrap IOCP into a user space thread ...

Except that io_uring is threads running in kernel.

There is no true async I/O on most (if not all) current platforms - it's all threads, either in user space or in kernel space. Sometimes even deliberately, for example polling disk will give better latency compared to waiting for IRQ.

I also started to fly gliders, and it would be lovely indeed to have electric self-launching glider, though unfortunately atm there are just too few of them, most popular are Arcus E and ASG 32 El, both are too new (cost a lot of money) and too rare. I wouldn't mind if our club get one, but it might be more economical to get a few other high performance gliders instead (like get two ASW 27 instead of one ASG 32 El) as it much easier to deal with them in a club context (doing 5+ launches per day, maintenance, etc).

Most likely a first viable step would be to get electrical tow plane first.

This is quite nice! I like the error handler monitor thing. Also quite amazing that they placed whole platform-independent (sort of) thread local storage implementation there.

From my understanding, post processing is completely different, like anti aliasing used, HDR pipeline used, shaders overall used, etc. [1] goes into detail what exactly might differ.

It's not like mobile phone is superior by any means to PC. One can compare TDP and figure out difference in raw performance. Is more that rendering techniques that give "diminishing returns" (in some peoples opinion) are exponentially more resource heavy, for example lightmaps (almost free even on mobiles) vs dynamic shadows (can be insanely expensive).

- [1] https://docs.unrealengine.com/en-us/Platforms/Mobile/Perform...

IMHO Depends on the use case:

- If glyph sizes are known ahead-of-time. Then use character atlas, generated either with CPU things or GPU things. This can be optimized for power consumption.

- Glyph sizes are not known, or text is animated (rotation, etc). In this case Distance Fields are a good trade-off, as their shader is fairly trivial, hence battery consumption should be quite good. On another hand runtime vectorization is viable only if you have a good GPU and connected to the power outlet.

You can easily have 1 million coroutines in-flight (my humble testing was showing that PyPy Stacklet on i4980hq has speed around 10-20 million switches/per second/per core). While with native threads I think it's in ballpark of hundred running threads, maybe single digit thousands. After that it looks like performance degrades too much.

But it all depends on an usecase, spawning a thread per user in a webserver would be slower than thread per core.

Would be nice to compare performance with others libraries! For example Stacklet [0] and Boost Context [1].

- [0] https://github.com/mozillazg/pypy/tree/master/rpython/transl...

- [1] https://github.com/boostorg/context/tree/develop/src/asm

How does one control runtime operations with this? Ok compiler/optimizer might have a notion of "fastest execution possible" (which most likely have some local time minimums). But what about latency/bandwidth relationship? What do I do if I need minimal latency possible? Or maximal bandwidth possible?

With MacOS 10.14 / XCode 10 now it's 2012+ models only.

> Lambdas are actually the only way to define functions.

Oh, missed lambdas, that's great!

> You can already link to C

I mean, only on Nix-es, only in Sys-V-like ABI. What if I'm under Windows? What if it's not Sys-V? What if I want Javascript (aka emscripten)?

My use case is game development, I could have a need to ship to wide variety of platforms (for some you don't even have publicly available specs, like PS3), and this platforms only provide C/C++ compilers. Why Myrddin compiler take a burden of supporting all C ABI's out there by implementing it's own asm code generation? Easier way out code be just generating higher level code like C or LLVM IR, and using libffi to implement FFI.

I would love languages like Myrddin to succeed, but let's be pragmatic, it is nearly impossible to support asm code generation with all C ABI's without having a full time team working on it. It is a huge time investment (not even speaking of financial investment connected to it). So I find it's hard for languages to get traction because they keep getting stuck inside Sys-V/Windows realm :( While something that compiles to C somehow magically just-work on everything, even web.

Looks very interesting from ergonomics point of view: it is indeed does introduce useful tools like generics, type inference, pattern matching, which are very painful to do in C. Though it seems like the language misses on popular nowadays generators, lambdas and coroutines. So I would say give it a plus on language design, and there is a space to grow.

Memory model looks C-ish, there are pro's and con's to it. Guess it works for the niche that language aims for.

What I think could be done better: compiler infrastructure / FFI. In this day and world interoperability with other languages is a must, and there is usually a need to provide standalone and embeddedable implementations of a language. IMHO would be great if Myrddin just compiled to C (like Chicken Scheme), that would broaden possibilities to use Myrddin as script language, or just use it side-by-side with C/C++. It can be done with the current Myrddin compiler implementation, but overhead of maintaining whole separate compiler/toolchain might be too big to enable wider adoption.

---

Edit: I was wrong, all functions are lambdas! Which is really great.

The post indirectly suggest creating domain specific language for solving dashboard presentation problem. In my opinion this shifts engineers focus to solve problems with-in provided domain specific language, which in the end resolves in job security, as non-senior engineers will not "dare" to touch "the framework". Whole situation, in my opinion, results in "everything working on paper" (aka tests, good design, etc) while in reality nothing works and as project progresses engineers get a feeling that "nothing can be done". I would just remove "numWords = countWords();" line and move on. There is no need to invent domain specific language when just programming language is sufficient. I would love engineers to be more reasonable and aware of DSL's trade off.

Depends on a country, in Sweden you can move your mobile number to any telco, and anyone can look up your number and your home address using something like [0]. But yes, it is still tied to a country.

- [0] https://hitta.se

It is not AFAIK, this chip contains E51 and U54 cores, E51 from what I seen (when prices were public) costs $595000.

--- Upd: some news articles still mention launch prices [0]

- [0] https://www.eetasia.com/news/article/chinese-start-up-sells-...

You can get their MacBook Retina with low TDP cpu's already (A1534 model). Reality is - usage experience is hardly acceptable, everything is way too slow.

Intel seems to be way above everyone in pushing performance/TDP. Apple might have comparable CPU's in iPhones, but they are only comparable for first 10 seconds - then they overheat and throttle. If we put good cooling on their CPU's then you have TDP in 15+ watt class which means poor battery life regardless of who made the CPU (Intel or Apple).

The only reason why all of this works with iOS in a first place is super insane power awareness on OS level: as soon as an app is not in view it basically stops almost all work (except for background handlers), and also their browser capabilities are very limited. To achieve 20h+ class of performance on laptops we either must accommodate the same principles (but hey that will probably kill almost any background web apps, like soundcloud) or invent better battery tech :(

As much as I would love to believe that I personally can sanely inspect all the code I run - I can't. One day I run apt-get install git and I have to trust all code that is being pulled to my machine (and there is a lot of code there) simply because my lifespan is probably shorter then time required to audit all the code in git dependencies (ssl, crt, kernel, etc). So given I can't possibly audit everything, then I need to trust, and if I need to trust, then being FOSS might make me feel a bit more sure about safety of the code, but in reality it might not even make such a difference - apt-get pulls-in binaries, who knows what/how/where this binaries are made ... trust chain is simply not there.

I personally trust FOSS software more not to do dumb things (like, hopefully my password manager doesn't report all my passwords to NSA), but simply being FOSS doesn't make it any more secure :)