Hacker News new | comments | show | ask | jobs | submit | zokier's comments login

On a quick glance Meshbird seems to be closer to Tinc than OpenVPN.

I'm author of Meshbird. Big different between Tinc and Meshbird. When you start Tinc you have to specify other node addresses. When you start Meshbird you have to specify network secret key only. Meshbird's node will find each others automaticly.

I'm immediately reminded of Bret Victors work: http://worrydream.com/#!/LearnableProgramming

I hope this is really the future


The 2 minute primer and motivation: https://www.youtube.com/watch?v=rskUgwq5N2A

Yes, it does remind me of Bret Victor's work. Seamlessly moving between coding and manual modes is really cool. I think it requires learning a new LISP like programming language called little.


Great resource, thanks for sharing this!

For me, transparent meaning is far easier for understanding systems than, for example, visual programming (I'm thinking the Unreal Blueprint[1] system)

[1]: https://docs.unrealengine.com/latest/INT/Engine/Blueprints/i...


How much overhead does std::mutex add in the single-threaded case for std::map? Because its kinda curious that this new map is more than twice as fast as std::map even on single thread.

Overhead of std::mutex depends a lot on contention patterns. Assuming one x86 CPU socket, usually you can take + release an ideally optimized contended mutex about 10M-25M times per second, if that's all you do, 100% CPU usage on all cores. That's simply limited by how many times you can run contested LOCK XADD (x86 atomic fetch-and-add) / LOCK CMPXCHG* (x86 atomic compare-and-swap) instructions per second.

Mutex generates a lot of cache coherency traffic and saturates the CPU internal ring bus. NUMA case it'll of course quickly saturate lower bandwidth CPU external QPI link(s).

Contested mutexes perform a lot better on a typical laptop than on a server.


good analysis, but you probably meant "ideally optimized uncontended mutex".

edit: spelling


To be exact, I meant code that just repeatedly locks and releases same mutex on all CPU cores.

(Counting is a bit tricky, atomic counter on each lock would invalidate the results. Best to only update the counter, say, on every 1000th result or to use some parallel counting library.)

  for(;;) { 
    mutex.lock(); 
    mutex.unlock();
  }

OK, now I see what you are saying. It would certainly be true for a spin lock, but it seems to me that, for std::mutex, the kernel transition required to arbitrate contention would dominate even on the coherency traffic, right?

Yeah, I was talking about spinlocks.

You're right that context switches would dominate std::mutex. For some reason I was thinking std::mutex uses spinlocks, even though I knew better. Too much kernel side coding lately - context switches are often not possible there, so mutexes are often not possible as potential synchronization mechanisms.


You might still be right. The implementation of std::mutex is unspecified, and real world implementations will probably spin a bit before going into the kernel, so for your test case with a tiny critical section it might behave like a spinlock.

std::map is a RB tree, not a hash map.

I'd be interested in the answer for std::unordered_map, then.

ANSI C++, section 23.4.2 and 23.4.4, doesn't specify the implementation only the complexity requirements.

Any C++ implementation is free to choose their std::map implementation as long as it meets the requirements, it doesn't say anywhere that a RB Tree is required.


libstdc++, libc++, and MSVC's STL all implement it as a red-black tree.

Even if it's not required to be a red-black tree, it is de facto a red-black tree on every major compiler.

Moreover, this doesn't really change the parent's point. It must be some sort of ordered associative container, meaning that it's not going to have the performance characteristics of a hash table.


Clang, gcc and MSVC are hardly "every major compiler", as there are many others to choose from specially in the embedded systems, real time OSes, classical commercial UNIX and mainframes.

We don't have always the luxury of choosing which compiler to use.

Relying on implementation details of the compiler or provided library is the first trap to writing portable code across OSes and compiler vendors.


I recall hearing/reading that there are sections of the standard which mostly suggest that a tree is the only valid map data structure. I think something to do with iterators and was mentioned in a CppCon talk or blog article. I will try to dig this up.

Sure, it might be that only a tree based structure is able to fulfill the required complexity, but it doesn't need to be a RB one necessarly.

On programming languages with ISO/ANSI specifications, relying on implementation details is a trap for writing portable code.


I imagine that sort of issues would (mostly) be solved by a monorepo approach. Of course that is also drastically different in many other ways too.

That was my thought too. It sounds like having an issue tracker tightly coupled with the code/repo structure would be extremely useful in monorepo's.

The problem might not be that it's hard to figure out which issue a repo would belong too, but rather, having multiple (separate) repositories that have things in common.


There is no fundamental reason why native apps can not expose shareable links just like any other. And on the other hand with the prevalence of single page webapps etc its far from guaranteed that you can get usable links from webapps.

A web link is easily shareable on the assumption that anyone you send it to has a web browser. A link to a native app requires you to assume that the recipient has the app installed and is on a platform where app URL schemes are well-supported.

Direct linking inside apps has been enough of a pain in the mobile world that entire companies have been built around it -- and the solution that those companies tend to use is built on web links. Android and iOS have also been moving in that direction.


What popular platforms don't deal with app URIs well?

None of them are great. Android and very recent iOS are doing OK. Desktop OSes are still pretty bad. Clicking a non-HTTP protocol link in Chrome pops up a huge, user-unfriendly "External Protocol Request" dialog that warns of a possible attack on my system. That's pretty par for the course for desktop browsers.

Hyper-V also ships these days on client Windowses too. I personally was quite pleased that I didn't need to install third party virtualization solution anymore on my workstation.

How is the graphics performance on Linux and Windows guest VMs?

Pretty poor, right now, unfortunately. I was looking at replacing VMWare Workstation with Hyper-V. However, when I installed Ubuntu Desktop on a brand new Hyper-V VM, I had to do some grub hacking to pass kernel parameters to get the display resolution right. Even after I got the display resolution right, there was a noticeable lag in the GUI refresh. I know that maybe with some more hacking I could have gotten everything to work just as well as it does on VMWare Workstation, but that proves my point. In VMWare, everything Just Works, out of the box. In Hyper-V, you need to tweak things to to work, and it's not clear what all things you need to tweak.

Allegedly that will be improving with Windows Server 2016, which is supposed to have better support for GPU acceleration for VM guests, but I'm waiting to see what actually gets delivered before I get excited.


This might not be the answer you like, but for "serious" fighter jet simulators there is pretty much two options, both of them Windows only.

There is still a community around Falcon 4.0 keeping it on life-support. But I wouldn't really recommend it as a starting point, considering the significant effort it takes just to get it up and running.

The other alternative, more modern and my recommendation, is DCS family. It consits of (gratis) core DCS "World" engine, and a selection of (paid) add-on modules (=planes etc). The nice thing about it is that you can just download DCS: World to try it out, it includes two planes you can fly. The not so nice aspect is that it is quite heavy, both in terms of hardware requirements and in terms of gameplay/learning curve. Its very much jumping to the deep end.


I suspect the number of cars (per capita) has dramatically increased too, hilighting the improved safety even more.

I think one of the most notable cases is the Prince of Liechtensteins (former) estates in Czechoslovakia/Czech Republic. Here is an overview of that story: http://www.minorsights.com/2014/09/Czech-Lednice-Valtice.htm...

Have you considered adding an option for saving/archiving the pages without cleaning them? Maybe utilize WARC somehow.

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: