nemanjaboric

The old website for Gyros stand in Berlin: https://grandegyros.de/alt/standort.htm There's also a new one https://grandegyros.de/

There's a sizable portion of people believing that spherical coordinates can be directly converted to planar coordinates :-).

There's a proposal to add fibers (akin to Boost.Fiber) to std C++, and of course, don't forget about coroutines :-)

This is very common in Germany. I worked (and work) with several people across different employers that worked 2, 3, and (this is the most common variant) 4 days per week. All folks that worked 2 and 3 days, in reality though worked 7 days, because they were working on their personal project.

I've heard (but never checked, although I did find some resources: https://www.hensche.de/Rechtsanwalt_Arbeitsrecht_Gesetze_TzB...) it is mandated by law that employer (as long as it has more than 15 employees) must allow you that.

Generally Available

According to https://news.ycombinator.com/item?id=22865842 #embed proposal is in the review process http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2499.pdf . This similar (same?) proposal is also presented and in the review at WG21 to be included in C++ standard.

The author puts a lot of work towards making this proposal a reality (as far as I as a casual twitter/slack observer can see) and I'm looking forward to it.

Small note that this is fixed in C++17: https://stackoverflow.com/questions/38501587/what-are-the-ev...

This is similar to idx/sub files from DVD which are just images and they are OCRd to text sub/srt file. I assume it's just easier for them to render the image than to mess up with text rendering/code page issues/whatever complication coming from huge diversity of devices they support.

I used to go to stackoverflow.com to check for the new questions and write answers.

Given his user name he may be from the Funkwerk: https://dlang.org/blog/2018/03/14/user-stories-funkwerk/

Yeah, the article is somewhat confusing, or wrong? I didn't see much people driving on pavement as well (I can't recall any), but had to move four of these to the side so that the lady with a roller can go through the pavement. The parking is literally - just leave them anywhere. And then they fall on the side, making them unwanted since nobody wants to drive scooter that's on the ground, so they stay there for days.

> She said parking in such a way as to obstruct traffic or pedestrians will mean a 35-euro fine -- but the Paris city council has pledged to build parking spots for 2,500 scooters.

One of the available garbage collector implementations in D (version 1) (and there's a work in progress to port it to D2) is a concurrent garbage collector which performs a mark phase in forked process going over the address space.

Also I've seen a project which persists large amounts of data to disk by forking and using a consistent snapshot of the data structures (which the new process will not mutate, so there's no need for locking).

I have (and I wear them at the moment) a single pair, while my wife has several pairs, so it might be we're biassed, but... here in Berlin, pretty much you can see them everywhere. In public transport, stores, on a street, in summer and in winter. They are _everywhere_, it's incredible.

It seems that the author followed the same logic as the author of the "English As She Is Spoke"[1] phrase book between Portuguese and English, with the French dictionary in between.

[1]https://en.wikipedia.org/wiki/English_As_She_Is_Spoke

I guess this would be in line with the Linus' description of GitHub:

> I think github does a stellar job at the actual hosting part. I really do. There is no question in my mind that github is one of the absolute best places to host a project. It's fast, it's efficient, it works, and it's available to anybody.

https://github.com/torvalds/linux/pull/17#issuecomment-56546...

> By default, docker containers run as root which causes a breakout risk. If your container becomes compromised as root it has root access to the host.

Is this really true, unless you start container with `--privileged`? Incidentally, I just read plan for better security defaults to avoid `--privileged` (which is not default, AFAIK) on lwn: https://lwn.net/Articles/755238/

Nevermind. If you check `vim-use` mailing group release email, you can see that there's `help version8.1` command which discusses the new release in more details.

Where can I find this "terminal debugger plugin"? Btw, terminal can be opened using `:terminal`, in case you're wondering (the release notes should really show how to use the new features).

> Luckily it's easy enough to support IPv6: just replace AF_INET by AF_INET6 and it will work with both IPv4 and IPv6! So don't you dare to ever use AF_INET anymore without a good excuse

(emphasis mine)

AFAIK, on many systems (think FreeBSD) this is not true:

https://www.unix.com/man-page/FreeBSD/4/inet6/

> By default, FreeBSD does not route IPv4 traffic to AF_INET6 sockets. The default behavior intentionally violates RFC2553 for security reasons. Listen to two sockets if you want to accept both IPv4 and IPv6 traffic. IPv4 traffic may be routed with certain per-socket/per-node configuration, however, it is not recommended to do so. Consult ip6(4) for details.

I live and work in Berlin for years now, working in startups, and I haven't met anybody that (openly) uses anything harder than tobacco or coffee, nor I met anybody who said they knew somebody to do that.

Beer is common after work, once in a while. However, what you describe is definitively not normal. Not that I find that problem, or high-risk, or anything - it's just the fact that it would just surely catch attention if anybody from my work environment (30+ close coworkers) notice somebody like you're describing.

We're using this technique to stuff the file descriptor with the accompanying object for the epoll registration, so one can check if the (reusable) object was reused for something else while registered with other file descriptor in the epoll: https://github.com/sociomantic-tsunami/ocean/blob/ee4f78d527...

I think the point is high CO_2 exhaustion rate of the gasoline cars, so that entire industry (and customers) switched towards the diesel engines, actively promoting them to be superior and eco-friendly variant of gasoline engines. Turns out they were wrong (just the other type of the pollution - Feinstaub) and to make things worse, they kept silent until the entire thing broke viral.

Thanks!

Yes, sorry, I've missed the point that you can move them across the threads (was sidetracked by the usual notion of them running in the same thread).

Oh, I'm aware this is a late reply, but it's better than nothing.

Yes, what you describe is exactly the kind of load we're addressing, and we're not getting GC to be in the way, simply by making usage of the reusable memory buffers, which are allocated in the first few requests, and then always reuse/recycled & fetched from the pool, so that we're not giving a chance for GC to kick in (as explained in the great blog post series, in D, GC mark&sweep will kick in only on allocations, completely deterministic: https://dlang.org/blog/category/gc/). Ocean provides some help here: https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src... https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src..., etc. This makes D completely suitable for these kinds of applications, and from my experience, none of D's features or the misfeatures is making such implementations hard.

D2 move is not yet completely done. We're still writing code that's compatible in both D1 and D2. For example, DHT node project (https://github.com/sociomantic-tsunami/dhtnode) and libraries on which it's depending on such as ocean (https://github.com/sociomantic-tsunami/ocean) and swarm (https://github.com/sociomantic-tsunami/swarm) are able to run in D2 with no performance penalties, but they still don't use D2-only constructs.

No, sendfile is not necessarily non-blocking (note the difference between async and non-blocking IO), it still blocks the caller if the reading side is a disk device. The advantage of using sendfile is that you need to copy the data from the kernel-space (source) to the user-space (program) and then back to the kernel-space.

Yes, the trick is that disk device is considered "fast", so it's not selectable - it's always ready to read/write, which is a lie. I _feel_ (and think, I don't have any data to prove this) the main problem here is the file system layer, which may or may not need to block _after_ the operation is performed, and this complexity doesn't occur with sockets/pipes.

Having a always-ready state on regular files is a problem since Linux's non-blocking is going around readiness. On Windows (and I believe on Solaris/FreeBSD), completeness model is in place, so you schedule an operation, kernel does _everything_ and then you're resumed upon completion of IO.

Which API are you referring to? If you're referring to `aio_` that's just glibc's user-space thread-pool emulation of the POSIX's asynchronous IO + many operations needed for the truly async IO are not supported (such as `stat` and `open`). There's `io_` syscalls family, but that's not in the ready-to-use state yet, judging by the manpages and various patches being submitted every month.

Trick is that nginx uses thread pools for non-blocking reading on the "fast" devices - you can't use coroutines/fibers, because on Linux is not reliably possible to read the regular file in a non-blocking way, as far as I'm aware, so that means that `read` in a single fiber would block entire thread until the data is fetched from the disk.

In the storage engine I'm developing/maintaining, I've been using fibers, for both network and disk IO, until people started noticing that, if number of the client grows, and if they ask a lot of data (generating a lot of disk traffic), the performance drops severely. I've moved to the thread pools, dispatching my disk IO operations there (although it's much problematic for the reads, as writes would be performed by kernel anyway, `fsync` and `close` would be operations that you still want to do in the separate thread): https://github.com/sociomantic-tsunami/dlsnode/blob/master/s...

edit: used right link for the freshly opensourced repo.