bennofs

Can you summarise how modern C++ database design differs from C-style design?

Userland heap randomization on windows is something different than ASLR. Windows 10 actually randomizes heap layout, not just the offset, by filling larger chunks in random order. So even offsets between allocations don't stay constant.

How is that different from the different caches already present in the linux kernel? For example, `struct cred` is always allocated in the `cred_jar` cache and nothing else goes there.

It's still using Google's push notification server. There is also no way to get around this, as apps backend server talk directly to Google to send notifications.

You're assuming that "math problems" is a well-defined set of problems. But depending on what you want to test/teach, there's also going to be different problems that students will do well on.

As an example: do you consider solving 579×46 quickly a "math problem"? I will solve it (relatively) quickly, since I was thought how to solve that exact problem algorithmicaly.

But if you hadn't thaught that algorithm (you could argue that nowadays we have calculators for this) then it would probably take you a bit longer to derive some form of this algorithm. But it doesn't necessarily imply that you're bad at math, just that you have not practiced this exact task before.

In my experience, doing really well in tests requires more adaption to the tasks of the tests than actual understanding. Most tests are limited on time, and stress does not exactly help you to deal creatively with completely new tasks.

Note that I don't want to say that teaching algorithms is bad. It surely helps to do some basic calculation without having to think much about it. I just want to point out that the tests are often testing a specific understanding of math, and different teaching methods often also differ in their goal of what they want students to learn well.

Lenovo T460 here works flawlessy. AS for Bluetooth it's unreliable in Windows as well but usually just works? I don't use Bluetooth much, it probably also depends on the Bluetooth profiles that you're using.

It's interesting to note that the improved algorithm also has a downside. With the VisiCalc algorithm, it is possible to model iterative fixpoint computations, so you could have a process that "converges" to a value, even having cycles in the computation graph. This is not true for the topological-sort based variants.

I have started to write links like this as a caution against this: https://github.com/lyft/cartography#. For most sites, the trailing point at the end then doesn't make a difference. Doesn't look clean but works well.

Isn't SSE the abbreviation for Server Sent Events?

Does it need to be the public that funds this iniative? I am not against that in principle, but such public funding would probably have to have some wider scope in order to benefit members of our society which are not planning to be working in web dev as well.

Why can't there be some sort of industry association that pays for shared goods that everyone in the industry benefits from? Are companies just unable to see the benefits gained from this?

The problem is that the unsafe-safe boundary needs to be specified. Unsafe code often relies on invariants ensured due to safe rust's checks. Also, there are properties that unsafe code has to satisfy which are special to rust, for example involving rules around special traits like `Drop`. So even if the unsafe code itself could be proven to have no memory corruptions, if it does not satisfy these invariants, it could lead to wrong behaviour in other parts of the program.

I was about to comment that these chu spaces look vaguely like galois connections. Turns out galois connections are just a special case of adjoint functors as well, so thanks for making that connection!

In the gzip case, the reason is that the compressed stream format is inherently sequential: you need to decompress everything before a byte before you can decompress the next byte. So parallizing is not really possible, without changing the format.

Newer compression formats have multiple streams that can be decompressed in parallel, or have blocks that are compressed independently without dependencies (bzip2 can be decompressed in parallel due to independent blocks).

At this scale, collaboration would probably slow things down more than it helps. Finding a consensus among so many parties is hard. Building separate solutions first and then unifying them later might be better.

Modifying a string in ELF is hard. As long as the string has the same length as the original one, it has a good chance to work (but still fails for compressed data). But if you want an arbitrary directory, you need to replace it with a different length path, and that will probably break a lot of things.

Having these "very special features" means that there are some things with are added to the language but rarely used. That means that you might come across code in a library that you don't understand, especially if you're not using those features in your own code.

So, I think the argument that "very special features" shouldn't be counted toward language complexity/growth is wrong, IMO. I would even say that there needs to be even more focus on those features, since they tend to be not widely known, not familar, and often there is less documentation about them, so the likelyhood that they make code hard to understand is even higher.

This is not to say that those features are unnecessary. I just don't think the justification "they are not what a pragmatic programmer will see" is good.

And where do you get your certificate from?

This sounds like you want https://k3s.io, a kubernetes distribution specially made for single node and probably much simpler.

Tried lsp-java with a gradle-based project, and couldn't get it to properly figure out the project model (so imports wouldn't be found and nothing worked). Tried with both Emacs and VS Code, no luck.

You can build docker images with Nix (https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools), but right now it wouldn't make much sense to use the NixOS modules (like nginx) for that. The modules in NixOS assume a systemd based environment and are thus not suitable for use in containers (in the end, most service modules generated systemd units).

What you can do, though, is use Nix to build a container image with an nginx config. You just can't use the abstractions present in NixOS as-is to generate the nginx config, you'd have to write the nginx config yourself (just as you would if you use a Dockerfile). You could perhaps re-use parts, or modify the NixOS modules, though.

An overview is given in their blog post: https://blog.zoom.us/wordpress/2019/06/26/zoom-can-provide-i...

However, I would also like to know if there's more to it. Do they do any server side transcoding? Do they get an advantage by having multiple backend servers connected through good links, having clients connected to the nearest one and routing efficiently through their network? It appears that they use(d) H264 as their codec, are there some technical tricks they use to cope with variable bandwidth (do they use scalable video coding or simulcast)?

They are working on it: https://github.com/jitsi/jitsi-meet/issues/4758. Unfortunately, I think WebRTC support is still not 100% uniform across browsers (there seem to be a range of browser-specific behaviour and bugs), making it hard to easily support all browsers. And Chrome appears to be the browser which implements new WebRTC features the fastest, so I can understand Jitsi Meet focusing their efforts on that platform.

You don't need chrome though, chromium should be enough.

I think they added people manually. They had a lot of manpower.

Signal's desktop app does not tether to the phone permanently. After connecting the desktop client, youc can use it fully independent ly from the mobile phone. WhatsApp doesn't allow that.

rules_foreign_cc appears to be something different: building projects with other build systems as part of a bazel build. The README does not talk about using prebuilt system libraries at all.

Additionally, adding lots of additional customization on top of the build system itself defeats the purpose of using a popular system in the first place.

Comment on the associated talk page, or edit it yourself to make it better?

https://en.m.wikipedia.org/wiki/Wikipedia:NPOV_dispute may be relevant as well.

Hermetic build systems make a lot of sense for companies, where you often want to control your whole stack and might even use a monorepo with all external dependencies vendored.

However, there are at least two cases where you do not want real hermetic builds:

- in the case of open source software that needs to be packaged for distributions, vendoring all the dependencies is bad. As the name already says, distributions remix software components and thus might want to compile your software against a different version of a library than the particular version you pick. - for libraries, consumers use your library just as a component and might want to combine it with a specific version of other libraries, so vendoring also sucks.

Unfortunately, many declarative build systems make it hard to separate the "building a component" part from the "composing a product" part. I could find no way in Bazel to depend on system software (using for example pkgconfig).

In my opinion, build systems for open source software (as I mentioned, for companies Bazel makes sense since you often want to vendor all your deps anyway) need to have three aspects:

- build rules for just for this component - dependencies on other components/libraries - a method to lock down components/libraries to a specific version, creating an offical "product" with an official supported combination of all dependencies.

This still makes it possible for distributions to create their own "product", without having to rewrite most parts of the build system. At the same time, developers can work with the official library versions (for compat, maybe you should even have multiple "sets" of dependencies), so getting started is easy and you don't need to install lots of dependencies first before you can hack on the project.

Often, build systems do things that are nice for onboarding (like "build systems" that pull git repos of dependencies during build, in order to have a single command to build the product from scratch after checkout). But those things directly conflict with the needs of distributions. We need to separate the "instructions to build, supplying all deps externally explictly" (in the context of building a package for a distribution) from the "just build it from the command line on a dev machine" (here, dependencies should be implictly fetched automatically, to give a nice user experience).

Actually, you can have multiple github pages sites: just create a new repo with a branch named gh-pages. You can then add a CNAME to that as well.

Runc used by Docker actually does this. The reason is that you don't want /proc/self/exe to refer to any host path when spawning the container process (see https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-fr...). The way to fix this is to reexecute the runc binary through a memfd so that /proc/self/exe is that memfd.

You need to consider that flying is still somewhat uncommon, if you consider the whole population on earth. From a quick search on google, less than 20 percent of the world's population took a plane in their entire lifetime.