HN user

nemanjaboric

75 karma
Posts0
Comments29
View on HN
No posts found.

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.

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.

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.

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).

Linux Raw Sockets 8 years ago

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.

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.

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.