jgalar

> proved Electron-apps could have near native performance

I don't think that's true at all. Try running Zed or Sublime.

That's not the reason why I publish OSS. I also publish that software under specific licenses that impose specific obligations (e.g., making the source available to users and attribution being given to the original author(s)).

My worst close-calls were a result of ABS engaging at very low speed. In all cases, I reduced the speed to 2-3 MPH approaching a snowy intersection, but the car refused to let the wheels lock and "sink" in the snow.

Instead, it's all too happy to drift into oncoming traffic at a glacial pace. It could be specific to the various Toyotas I have owned...

In my experience, having to explain a software's design in plain English often reveals that some aspects were poorly thought-out in the first place.

To provide some context for this release announcement, the LTTng documentation has a nice intro to tracing and an explanation of how LTTng relates to other Linux tracers.

https://lttng.org/docs/v2.13/#doc-nuts-and-bolts

That's not true.

For example, the microphone of the X1 Carbon 7th generation still doesn't work out of the box. You need to blacklist a handful of kernel modules and edit your PulseAudio configuration to force the loading of an ALSA source hooked to the correct device ID.

The Arch wiki has an article cataloguing issues and workarounds (with various degrees of success) for every generation of the X1.

I would guess memory map the whole file, then do the equivalent of:

memmove(beginning_of_file, beginning_of_file + 300_m_line_offset, file_size - 300_m_line_offset);

We have very different experiences; I hear baladodiffusion (or balado) very often in Montreal.

I'm from Montreal. It's not "chambre-a-montrer", it's "salle de montre". Also "coussin-a-gonfler" is "coussin glonflable".

As for computer-science related words, I think the OQLF (French Language Office) does a great job overall. "Courriel" (e-mail) is one of their best contributions and is used regularly.

It's very ugly, but at least it doesn't seem to limit you to 15 characters like on Linux (prctl/pthread_set_name_np).

That limit makes it pretty hard to provide meaningful identifiers in a non-trivial application.

Yes, and they will also move the goal posts when you explain why their solution doesn't work.

I feel there is something missing in this whole discussion and that's the question of unsolicited advice. I don't think anyone will feel insulted if the j-word comes out after they have asked for help on a problem.

On the other hand, It's hard not to feel like that question is condescending when it is unsolicited.

k8s feels much more like an effort to commoditize this space through standardization. It's a pretty common business strategy [1].

[1] https://www.gwern.net/Complement

Full disclosure, I work on LTTng and a 20% improvement is a huge deal to our users, so I'm certainly biased here.

As far as I know, the thread-local write only occurs if a rseq region is set. The added cost to a context switch seems essentially limited to a branch: https://github.com/torvalds/linux/commit/d7822b1e24f2df5df98...

The other benchmarks that were posted in the various threads leading to this merge looked fairly impressive to me.

Of the top of my head, jemalloc benefited a lot from this patchset, and not just on the run-time front: https://lkml.org/lkml/2016/10/10/332

Not necessarily. Applications may choose to retry a certain number of times and fallback to another mechanism if the critical section can't complete.

A problematic case that was brought up on LKML was the interaction with debuggers and unexpected page faults, see this comment: https://lwn.net/Articles/738119/

Mathieu's (patch author) main motivation was removing atomic operation from the LTTng userspace tracer's hot path.

In that case, the per-cpu data is the 'reserve' and 'commit' counters that must be updated when the tracer saves an event to the per-CPU buffers.

Other uses that I'm aware of include memory allocators that maintain per-CPU arenas.

Then why not ban friendships in the workplace? Surely they could result in the same kind of perceived biases (e.g. cliques).

I would guess cable video is multicasted once to many customers while online streaming has to be served one-to-one.

From the viewer's standpoint, the bandwidth usage is roughly the same, but the broadcaster and CDNs have a lot more data to deliver.

Even the kernel occasionally breaks interfaces. Case in point, FUTEX_FD was introduced in 2.6.0 and retired in 2.6.26 [1].

I don't think anyone working on glibc is intent on breaking user space. Sometimes it's just the most pragmatic solution.

[1] http://man7.org/linux/man-pages/man2/futex.2.html

Pure speculation on my part, but could this be a way for Apple to segregate Chinese account data from the rest of their customers' data?

That would seem to limit the scope of what Chinese authorities can access.

Are there good DOM "bindings" available for other languages compiled to wasm?

IMO, it really depends on the context. If you are working with people who share your assessment of the current situation (both business and technical folks) and want to improve it, you'll have a great chance to learn from others' (and your) mistakes.

However, constantly putting off fires, under the gun, in horrible code bases, is probably not a good way to learn how to design software... It's a good way to learn how to debug and reason about problems, which is also a valuable skill to develop, though.