cm3

Concerning external links, I'm surprised that big news sites don't seem to have stable links whereas tech sites like /. do. Go to Wikipedia, and follow a few referenced links to major news organization websites. You'll find many dead links. Given that they use complex, professional CMS solutions, I don't understand why they would break links. It's not like they cannot serve ads for old articles. Wired's old articles seem to be there but barely so with sometimes broken img links.

> If I get email related to my site, I often post it to the site.

But only after consent from your the sender, right?

For a year now Google's reCAPTCHA has been very hard to convince as a human that I selected the correct 3 (or 4) rivers, houses, street numbers, mountains. Most of the time it makes me take the test twice or or more, even though reCAPTCHA is wrong. I feel like, if we're used to help train their neural network, it should at least have the courtesy to not require so many I-don't-believe-you-please-retry iterations.

Given how many sites use Cloudflare, I'd welcome they switch to a more reliable captcha service until Google repairs their scripts.

Oh and other captcha services work in Tor Browser Bundle.

Of course, but shifting the burden onto developers, where most of them aren't professional libc or kernel engineers, leads to avoidable issues.

Rust seems familiar enough to many developers, and forces them to think about resource management before running the code by not allowing incorrect code, so I hope it will lead to more libraries and applications that would have otherwise been easily plagued with issues due to choosing C. Granted, I'm not a fan of how Rust's surface has turned out, but it's a sensible compromise to attract masses of developers into writing less buggy code that operates on the same level as that written in C. So I use it as a C replacement, and for that use case I like it because there's momentum behind it.

C is a minimal abstraction over asm and I wouldn't be surprised if this behavior can be configured in some C compiler, even though it would be odd to do so.

What I find surprising is when people say C is a simple and small language that's nice to build portable programs in. So much of C is undefined behavior or implementation specific that many professional users pin a certain compiler toolchain version for a project. Part of it is due to changing and hard to predict optimizer passes, but most of it is due to the purported portability feature of C. I mean, if I leave a lot of the semantics undefined or to be defined per compiler+target, then it's not really a portability abstraction. Not to mention the missing or, if you consider POSIX, inconsistent across platforms, C stdlib.

It's educational to look into Modula-3 and SPIN. SPIN is like MirageOS but with dynamic loading of components whereas in Mirage everything is compiled ahead of time into the final image. I mention Modula-3 because it's of similar age as ANSI-C and serves as an example of an OS written in a comparatively safe language around the same time Unix won and gave us the hegemony of C (with all the avoidable security fallout ever since).

Even though software isn't like the real world and could be improved substantially unlike world politics, we still continue dealing with bugs due to C, although we have better options. I think as long as new operating systems or libraries and applications are written in C, this won't change. Just the idea of writing kernels for IoT systems in C in 2016 makes no sense from a reliability and high assurance perspective. Getting there half way would be exposing hard-to-misuse C APIs where the implementation is in a safe language (Rust, ATS2, etc). For the moment consuming C APIs is the cross platform library interface we have to deal with, but having at least the implementation be safe would go a long way.

I can't find anything in the manpage about git-am checking the patch file's parent(s), but a patch file is accepted by git-apply as well, and then it's certainly not expected to consider a parent. That said, I've had git-am fail while git-merge or git-rebase would do the right thing, so git-am is probably, judging by the docs as well, not taking the history into account. If it does and I forgot to tell it how, I didn't know what options it is.

I mean when you get a .patch file and git-am that doesn't provide the same associated info (or environment) for git to resolve a merge.

Yes, and it's why running git-am on the isolated commit can fail whereas cherry-picking does a proper merge and is more likely to apply cleanly.

I was referring to the fact that in git you can cherry-pick a commit as the similar mechanism.

git and hg are somewhere between Subversion and Darcs/Pijul. You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. It's all a compromise, and even Subversion gained merge features, leaning more into the git/hg realm. Tracking patches has huge advantages, especially in open source work, whereas it's not really needed if you just commit to master/trunk all the time and merge with a tool and not by tracking patches. Darcs and Pijul are what would be a perfect fit for the patch queue model used by kernel maintainers.

English isn't my 1st language either, but the power of downvotes is misused a lot on the internet, especially when there's no public trail who downvoted. Advise and canon may just carry too strong of a meaning for those who grew up in English-speaking school systems.

FWIW, Gitlab now has DC/OS (Mesosphere) support https://about.gitlab.com/2016/09/16/announcing-gitlab-and-me...

For continued decentralized operations something like https://github.com/google/git-appraise looks good. It's like Fossil-SCM's distributed tickets but for code review. It can also mirror to Gihtub and Phabricator and has a web interface too. Most importantly it doesn't break the decentralized aspect of git.

I never downvote anything, so I'm not sure, but maybe the use of "advise" and "canon" triggered negative votes?

I don't know if you're aware, so this is just a friendly suggestion: if you define these as git aliases instead, you won't use your shell's namespace and have it available for other aliases. As git aliases you would run it like `git s` or `git ca`. If you also alias git to g it will be `g ca`. If you do that, don't forget to call `__git_complete g __git_main` in .bashrc for it to auto-complete aliases for `g` and not just `git`. For example, to define `ca`, run this

    git config --global alias.ca 'commit -am'

Both GitLab and GitHub do in their SSH implementation.

Agreed, and if you run on a microkernel, then pretty much everything is in userspace and any boundaries are those of, say, a capability system for security purposes. I still cannot wrap my head around the fact that we're adding ways to avoid the kernel network stack and other exceptions to the rule, while ignoring microkernels as the sorely needed feature for mainstream computing it is.

The last time I used Spotlight (no mac at the moment), it was so slow that I had to disable it globally. The metadata integration in BeOS was different. For example media and email storage in BeOS.

The filesystem metadata queries were real-time back when spinning disks were much slower and neither the processing power or ram was comparable to what we have today. With today's machines we do not have the same experience under Windows, macos, GNOME, KDE. Feature-wise yes, performance no. Is there a technical reason we couldn't have the same filesystem integration? No, there isn't, it's just incompatible priorities and half-baked 2nd system syndrome in effect and repeated all the time.

> I need to revisit mutt-kz

I haven't used it myself, but there's also https://www.neomutt.org/.

> That's an awesome demonstration of how easy it is to swap out the libc in Rust. :-)

Now I have to look up how I use cargo to build a static binary on FreeBSD, where I don't have to swap out libc.

> Note that I also distribute statically compiled executables with musl and SIMD enabled (using target-feature=+ssse3 instead of target-cpu=native): https://github.com/BurntSushi/ripgrep/releases

I took the flag from your blog post, thanks for pointing out the explicit feature flag. That will allow the binary to run on more cpus.

To build a static Linux binary with SIMD support, run this:

    RUSTFLAGS="-C target-cpu=native" rustup run nightly cargo build --target x86_64-unknown-linux-musl --release --features simd-accel

That's right, but I know several project maintainers who are looking moving to it because BoringSSL's scope is smaller and is sufficient for their projects' needs. That's why I think the BoringSSL's API status will evolve with time. And Ring is based on it, so...

Then there's ocaml-tls which aims to provide a drop-in implementation of the OpenSSL API too.

We're finally seeing much activibity, and in that sense, I'm glad that Heartbleed happened, but it should have been earlier :).

My reply is to this

    Who actually takes software licenses seriously in their own home?

If this doesn't imply one's okay with stealing, then I take my comment back.

Because you seem to assume I use a mac, I must confess to not owning one and therefore not using macos.

I write software for free and as a living, so I surely take it seriously. How can a software developer justify stealing software, unless they're trapped in a poor or technologically restricted situation (Cuba)?

EDIT: There's some confusion as to what I replied to:

My reply is to this

    Who actually takes software licenses seriously in their own home?

If this doesn't imply one's okay with stealing, then I take my comment back.

Short answer: unlikely to end anytime soon, but likely that we start to focus on higher level bugs more than lower level issues.

Long answer: If Unix and C hadn't won the fight in the 1980s like VHS did, we wouldn't deal with such low-level bugs. It took 30 years, but we're finally getting CPUs (like lowRISC) that were inspired by BS5000 or i960 and the languages to go with it are getting mainstream. To be fair, had we as an industry taken security more seriously decades ago, we would have written critical pieces of the stack in a high-assurance Ada profile, and put microkernel design capability kernels into production. We can extend 1960s kernel designs with all kinds of features, but without a coherent design it's impossible to provide the same assurance. This is why it's great that we have L4 descendants that incorporate a capability scheme and also support a multikernel scheme (ala Barrelfish) for making better use of a cluster of cpu cores.

Assuming we stay with a library written in C, a better approach would be for everyone to try to move to what's in BoringSSL, which deliberately removed most stuff, more than LibreSSL.

If we still stay with C, Ring would be a good replacement, which is partially/primarily written in Rust.

That said, LibreSSL's TLS abstractions look like a welcome improvement if you need a C API.

Genuine questions:

Is it commonplace for a bank to be a British Ltd, and are they part of a separate banking emergency fund to accommodate for that because they have a banking license?

Also where do I have to look to find a real world address for Focus FS Ltd (company behind Mondo)? Looked around the internet after finding nothing on monzo.com. I know startups do not list contact info these days, but whois info is also opaque. I'm asking this because they advertize themselves as a modern bank, but I cannot find a real world address after 5 minutes of searching.

I've been wondering why AC units for buildings don't come in solar cell combi packages, where if it's hot, it's sunny, so the ac can be powered by the sun, ideally making it a zero sum calculation.

Yeah, also the STM support is often overlooked and is a good fit for some tasks where everything else is much harder.

Thanks for the pointers. Yeah, after you've bootstrapped once, you have a version to bootstrap another, especially since the new requirements to not depend on a nightly snapshot. rustup should be able to provide images that way which work on both alpine and void. The default would be a dynamically linked against musl rustup image which may still expose musl-static as a target just like it does on glibc hosts. I wouldn't complicate matters as a first step with questions of whether a musl image should be statically linked.