temprature

https://en.wikisource.org/wiki/Copyright_Act_of_1976#%C2%A7_...

Further recommended reading: Lenz v. Universal Music Corp.

Makes the calls shorter and easier to read. Consider:

    if (pledge("stdio rpath tmppath proc exec", NULL) == -1)
        err(1, "pledge");

    if (pledge(PLEDGE_STDIO | PLEDGE_RPATH | PLEDGE_TMPPATH | PLEDGE_PROC | PLEDGE_EXEC, NULL) == -1)
        err(1, "pledge");

And really, unless you're using pledge wrong, ie. by using it outside of the startup path and/or not checking the return value, what does compile-time checking get you?

You'll find out in a couple of months why they did this. I hope you'll remember the comments you've written when that happens, because you might learn something about what OpenBSD means when they say they "strongly suspect" something.

What signing keys? Wordpress's automatic updates aren't signed, so your trust is horrendously misplaced.

Someone already did the work for them to implement it[0], and rather than commit it, a Wordpress developer wrote a blogpost saying signing isn't really that important[1].

[0] https://core.trac.wordpress.org/ticket/39309

[1] https://medium.com/@photomatt/wordpress-and-update-signing-5...

Creating two files with the same MD5 is a very different beast from creating a file with the same MD5 as an arbitrary pre-existing file. These third parties would need to have colluded with the DragonFly developers to make what you're proposing possible.

Yes, it is possible that the DragonFly developers could collude to create two ISOs with the same MD5, one good and one malicious. No, it is not possible that random, evil ne'erdowells could replace the ISO with one with the same MD5, unless the DragonFly developers have conspired with them to make that possible.

If you don't trust the DragonFly developers not to collide the MD5s, you probably shouldn't trust them with the code running in your kernel anyway.

He would have had a much better time using C99 than C++11, especially since he didn't want to install a newer gdb from ports.

[0] http://lists.dragonflybsd.org/pipermail/commits/2016-June/50...

The main debate over the incompatibility isn't about GPL vs CDDL; even Canonical isn't arguing that the licenses aren't incompatible. It's specifically about the Linux kernel vs ZFS; ie. does linking the ZFS module with the Linux kernel make the ZFS module a derivative work of the Linux kernel.

If yes, it has to be able to have the GPLv2 applied to it, which it can't. If no, then the incompatibility is irrelevant, and the kernel and ZFS can be distributed together and under their own separate licences. This is where opinions (by legal experts, not people on the internet) differ, the FSF and SFC's lawyers say this makes ZFS a derivative work and you can't distribute them together, Canonical's lawyers say it doesn't and therefore you can.

There was another "incident" with the KRAK embargo, where OpenBSD got permission to silently patch it early and then the researcher who found it regretted giving them permission.

I think people put these two incidents together, combine it with the developers' attitudes towards embargoes and come out with: OpenBSD doesn't honour embargoes!

From https://www.krackattacks.com/#openbsd :

> As a compromise, I allowed them to silently patch the vulnerability.

Receiving permission to patch is the opposite of breaking an embargo.

Which doesn't make a difference if OpenBSD still gets their patch out at the same time as everyone else. Unlike other vendors, it doesn't take OpenBSD four months to go from vulnerability notification to patch release, if you look at previous disclosure timelines they typically have a patch out in days.

There shouldn't be any policing at all of which domain names are allowed to have certificates.