When you run ./configure or cmake for a C program, it often prints something like "configure: checking size of long long" or "-- Check size of long long". This is done by generating, compiling and running a short C program that prints sizeof long long. The result goes into an autogenerated config.h.
In Rust the first example of build.rs usage [1] compiles and runs a C program during the build of the crate, and the next page [2] shows how to use autogenerated Rust code with include! macro.
Lisp is more similar to C or Rust than you might think. Code generation typically happens while the library or program source code is being loaded, and it is orchestrated by a declaration in an .asd file, which is analogous to meson.build, but looks more like Cargo.toml, e.g. [3]
Some Common Lisp FFIs have opted to coax this information out of the compiler. https://github.com/rpav/c2ffi is a C++ tool that links to libclang-cpp and literally outputs JSON with sizes and alignments. (It is then used by https://github.com/rpav/cl-autowrap to autogenerate a Lisp wrapper.) The older CFFI Groveller [1] works by generating C code which is compiled by the system C compiler (e.g. GCC or Clang) and, when executed, prints Lisp code that contains resolved values of constants, sizes, alignments, etc.
The attack relies on the fact that when downscaling by a large factor, the tested downscalers (except Pillow in non-nearest neighmode mode, and all of them in area averaging mode) ignore most of the pixels of the original image and compute the result based on the select few which are the same in all modes, making the result look nearly the same regardless of the mode.
Gentoo (actually Funtoo) was the last distribution I used on my main laptop before switching to NixOS. (I have tried Guix, but not GuixSD, so won't talk about it.)
> 1) Are these kind of systems overkill for the desktop user?
There is more to learn to be free to do everything — for some this might be too much (even though it is easy to start and the learning is mostly gradual), for others this is fine (especially those viewing the obstacles as opportunities to learn rather than distractions), and many others can be satisfied with their systems before achieving such freedom. While efficient usage of NixOS requires more upfront involvement, once settled or learned it becomes the easiest to maintain, and brings the piece of mind I had with no other OS with its easy global configuration, nondestructive updates, and manageable malleability (adding and customizing packages, effortlessly offloading their build to your other machines with Nix, even without NixOS).
> 2) How easy is it to customize/tweak these systems in the manner that Gentoo does? So, building from source by tweaking the software options on build time?
Nixpkgs have close to optimal balance between the ability to use prebuilt packages and the ability to extend them, and it's more customizable (thanks to Nix and Nixpkgs designed to allow reaching into the old definition of a package, writing tweaks just for the parts you need, while keeping automatic updates!), although it's geared towards users that want most of their packages prebuilt (in particular it does not have cross-cutting USE-flags). You can either replace a package (and cause dependent ones to be rebuilt against it), or override under a new name (and install it alongside other packages that may depend upon and actually use the non-overridden one).
Surprisingly I also got 292 (156+136 bonus) on the first try on Lenovo X1 gen 4 (NixOS, Xorg). Both synaptics and libinput powered touchpads have always felt perfect for me, with minor to none customization. (Currently my only setting for libinput is to enable natural scrolling.) However, I have no experience with the Apple laptops.
> Given a choice between only two extremes, I'd far rather have Linus Torvalds telling me I'm an idiot and my code is shit, then exist in an offense taking culture where various forms of criticism are re-branded as "harassment."
An interesting alternative to SMS over XMPP/IRC over Twilio is SMS over XMPP over your Android phone. This lets you send and receive SMS on the computer and share the history with the phone. For this I'm using MAXS (http://projectmaxs.org/), an open source modular system available on F-Droid and Play store where each module is installed separately and provides a specific service over XMPP, such as receiving new messages, reading old messages, querying location, etc.
You can copy the output of "vgo list -m" (the list of transitive dependencies with the selected versions) into the "require" section of "go.mod" and increase the versions that you want to change. (The next invocation of "vgo verify" will delete the lines with versions that you did not change because they are implied by the lines with versions that were not deleted.)
> And then the tool does not even have a proper feature to enable you fixing it on your side (e.g., by pinning a whole dependency tree).
vgo allows you to pin your transitive dependencies to the exact versions of your choice, as long as non of them require a dependency with a higher version than you prefer. (But then, do other dependency managers let you disregard version constraints of your dependencies?)
vgo trades some safety (by not supporting upper bounds) for some utility (by not artificially limiting the lifetime of a released library). Yet package managers that do support upper bounds do not guarantee safety, because libraries may not specify upper bounds or they may specify too broad bounds. This is a trade-off, and I have not seen anything convincing about why vgo position on this trade-off is unreasonable.
Can you give an example where vgo prevents use of a library where another approach does not? The main difference in the expressive power between vgo and traditional approaches is that the latter can restrict your use of libraries together more. vgo does not need a perfect world: it is practical in the imperfect one.
> MVS does use a maximum. It's the major version number in SemVer.
So, we can not force a library that wants dependency v3 to use dependency v2 (and vice versa), even if the author of the library knows that it works with either v2 or v3. This is a loss of vgo. On the other hand, if another library can only work with v2, and yet another can only work with v3, vgo allows the use of both in the same application. This looks like an acceptable win for the price of that loss.
vgo was explicitly designed to balance out two needs: (1) the need to use known good versions of the dependencies, and (2) the need not to burden dependency consumers with meaningless constraints (especially with an upper limit on the version). This article shows* why the first need is important, but it does not give vgo the credit for satisfying it with its minimal version selection (and, indeed, for providing a more stable and hence reliable solution than maximum version selection), and it misses the value of the second need. In my experience, the upper limit on the minor version is most often arbitrary, and in some cases when it is not, a future minor version reverts the mistakenly introduced incompatibility. Therefore vgo approach has unique advantages over other version selection methods, and it should not be discounted for the lack of a feature necessary to provide them.
* The article says that "Prior to 1.4.0 there was one function of MaxMsgSize" which "had previously set the size on both send and receive" but it does not substantiate this claim, and it may be false since go-grpc 1.3.0 documents that "MaxMsgSize returns a ServerOption to set the max message size in bytes for inbound mesages" https://github.com/grpc/grpc-go/blob/v1.3.0/server.go#L166, and it has not changed in go-grpc 1.12.0 https://github.com/grpc/grpc-go/blob/v1.12.0/server.go#L228 which strongly suggests that this is not a bug.
I believe I can quote the response to my support request:
«We added iptables rules to hijack all DNS requests on port 53 going via the VPN tunnel, this is to protect users having set a DNS server unknowingly (or by malware). We are aware that not all users want this behaviour, and we intend to add an extra port that OpenVPN listens on, where DNS hijacking will not happen.»
Some VPN providers (including Mullvad) have a client-side feature called DNS leak protection that configures the system to use the provider's DNS server. I don't know how Mullvad decided that this was not enough, and they are justified to intercept DNS. (Note that for the server-side intervention to work, the client side must be configured not to use ISP DNS, hence the client-side DNS leak protection is a prerequisite.)
I'm using Mullvad. On the plus side, their servers are the most reliable I have seen, and they provide IPv6 addresses (behind NAT, which is reasonable for privacy). On the minus side, since November 2017 they intercept DNS queries and answer them themselves (hence you can not use DNS service of your choice), unless you connect to a specific undocumented OpenVPN port (1400 or 1401) available on a small but diverse subset of their servers.
> Use Mutt carefully or copy/paste into GPG for now.
According to [1], Claws Mail is also unaffected. I don't know if it was tested with or without its HTML plugin, but this should make no difference as long as the plugin is not configured to access remote resources. (By default it can not make network requests.)
When you run ./configure or cmake for a C program, it often prints something like "configure: checking size of long long" or "-- Check size of long long". This is done by generating, compiling and running a short C program that prints sizeof long long. The result goes into an autogenerated config.h.
In Rust the first example of build.rs usage [1] compiles and runs a C program during the build of the crate, and the next page [2] shows how to use autogenerated Rust code with include! macro.
Lisp is more similar to C or Rust than you might think. Code generation typically happens while the library or program source code is being loaded, and it is orchestrated by a declaration in an .asd file, which is analogous to meson.build, but looks more like Cargo.toml, e.g. [3]
[1] https://doc.rust-lang.org/cargo/reference/build-scripts.html [2] https://doc.rust-lang.org/cargo/reference/build-script-examp... [3] https://github.com/rpav/cl-freetype2/blob/b7871aed0c5244fc3b...