keeperofdakeys

I'm not sure if they're planning on collecting every homepage domain here, or just asking something like "Is your homepage domain in the list of top 1000 domains?". In the former case, just having the domain listed could leak information. In the latter case, I can't see any issues.

They don't plan on collecting URLs, just (eTLD+1). The only real issue I can see here are users who have registered their own domain under an eTLD, and have it set to their home page.

eTLD: https://en.wikipedia.org/wiki/Public_Suffix_List

Another useful command is `git reflog`, which records where the tips of branches previously were. So after a bad rebase or merge, it's easy to get back to the previous state.

It's also good to know that by default, `git gc` will only prune unreferenced objects older than two weeks.

With the way IP Routing works, every router on the path makes a routing decision. So two people on the "new IPv4" would be unable to talk to each other if even one router on their path doesn't understand the new format. Not to mention that to be fully compatible, you'd need a way for a person with the address "0.1.192.168.1.10" to talk to an IPv4 only client on 192.168.1.10.

Then there are switches and routers that make assumptions about incoming packets, so we can't do strange bit hacks with IPv4 packets. http://seclists.org/nanog/2016/Dec/29

Switching to a new protocol is the only real choice at this point.

That's a pretty bad idea, you shouldn't rely on this kind of stuff.

If there are people running OSX or Linux that want Windows downloads, or someone is behind a captive portal or proxy (like squid), they probably won't be able to reach it anymore.

If you have a real problem with bots, I'd look at what IPs they are coming from, and how often they try to connect. Something like IP blacklisting, or fail2ban might work for your use case.

Both git and this git web view allow you to view all the commits that have modified just that file. Eg. https://sourceware.org/git/?p=glibc.git;a=history;f=resolv/r.... So it's a simple matter of looking at the diffs between commits.

Of course that's assuming you know the right file, which is often the harder problem.

It seems to mostly come down to differences in how things are defined. DNS itself can handle almost arbitrary data https://tools.ietf.org/html/rfc2181#section-11, while an Internet Hostname was defined to be more strict https://tools.ietf.org/html/rfc1123#section-2. The same issue also exists with dashes at the end of domain components.

I'm not enough of a history boffin to know how Microsoft came to support it differently (perhaps something from the Netbios and NT era). At this point in time though, I don't see either party changing their default validations to agree on a single definition.

Edit: If you're curious, this is the first commit that appears to be the first glibc commit limiting dashes at the end of URLS https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fa0bc.... I don't know about BSD libc, or windows however.

From a protocol level, NVMe is actually designed for SSDs - just look at the amount of queues it has https://en.wikipedia.org/wiki/NVM_Express#cite_ref-ahci-nvme.... To really take advantage of this, you'd need your filesystem to be designed for many independent IO streams. ZFS metaslabs probably help, but I'm sure there is more you can do in this area.

On the other hand, I don't think many people would be hitting any limits where this matters.

One time I came across a github user with a username that started with a hyphen. I could browse their repos fine, but I couldn't view their github.io site on Linux.

It turns out that Windows and OSX allow domain components to start with a hyphen, but Linux does not. There is at least one DNS RFC that disallows this though.

Relevant Ubuntu bug. https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/66...

Each DNS zone (azure.com, mydomain.azure.com, otherdomain.mydomain.azure.com) is separate, and they can all be given independent TLS certs. The only relationship between azure.com and mydomain.azure.com, is that the azure.com name servers delegate DNS for mydomain.azure.com to the name servers of mydomain.azure.com.

So you can turn on encryption at that level, and using Let's Encrypt, the private key for your cert would be unique for you. So private keys for azure.com won't be able to decrypt traffic for mydomain.azure.com.

For a new transport layer protocol like QUIC, this can work. However when you start talking about IP, you need to update/replace basically every device on the internet. If a device in the path doesn't know about the extended address space, that packet probably can't reach it's destination.

One disadvantage of zfs in this case is that it uses its own caching layer, since it's basically an OS subsystem in itself. So on a memory constrained host (eg. rpi), you might have some issues with the zfs and linux buffers competing for RAM.

It's worth noting that eval in perl5 can be used with a codeblock to give basic exception handling, in perl6 this functionality has been moved to try. So while it's quite common to use eval in perl5, I'd expect much less usage in perl6. The name change is probably a good reminder of this.

There is the concept of a "hidden master", where the public nameservers are slaves to the real authoritative server, which is kept hidden. Some people put their hidden masters in their public NS records, which I've always found odd.

Why does it require using hardware raid for optimal cooling? I set up one of these recently using AHCI (disabling the hardware raid controller) with mdadm.

They need to live in the same namespace, otherwise you'd practically need different syntax for importing something from a crate, or a module. You can use `extern crate foo as bar`, if you are having namespace issues.

In git the SHA-1 hash is simply an identifier for an object - it's used in the filename, but not stored in the object. And when a commit or tree object references others, it's just a name that can be looked up in the database. So a commit object hashed with SHA-256 can easily reference a previous commit that was hashed with SHA-1.

During the switch, a bit of deduplication may be lost. But the only interesting issue I can see is how git fsck will tell which hash an object was created with when verifying the hash (maybe with length?).

There are no known attacks which make SHA1 insecure in this context. Also according to this announcement, they will be signing the builds, which is vastly superior to any unverified checksum.

Getting it working correctly can be annoying. There is actually a HTTP status code for captive portal redirection (511), but nothing supports it. So if you use it, captive portal detection stops working.

Except that for some reason Australia picked MPEG-2 for our digital TV, and so HD was almost unwatchable. Though it seems we've moved to MPEG-4 now.

CentOS is managed by Redhat, but it's still a separate project. The RHEL 7.3 release that this is based on was released over a month ago.

There are a number of security issues which can come with symbolic links, especially with how user/group permissions are handled. There is also a lack of support for them in the ecosystem, which could introduce some strange problems (for example, whether specific apis follow them, or not). So I can understand why they're putting this behind a flag.

In my tests I was getting around 70MB/s routing with a few dozen firewall rules. However I'm not sure if this was a limit of the APU2, or the devices I was using to generate the traffic.

It also has accelerated crypto, so ipsec/openvpn shouldn't be much slower than routing.

The github mobile site doesn't have search. If your mobile site doesn't provide all the features your desktop site does, you're asking me to make a choice between features and usability - and I'll usually choose features.

To put it simply, yes. You have multiple NS records, and each points to a server that can act as an authoritative name server for your zone. When clients query for your zone from parent zones, they'll get all your name servers. The hard part is how you keep those name servers synchronised.

IIRC, bind has multiple built-in methods of keeping zone files synchronised between boxes.

You might try The Algorithm Design Manual, the second half of the book is a giant index of algorithms. The first part is a guide on what algorithms you should pick depending on what you're doing.

I wrote a small ps clone as a side project, and "man proc" was invaluable in understanding what everything meant.

There was interesting work happening on a proposed newer api though, "task_diag" https://lwn.net/Articles/685791/ https://criu.org/Task-diag.

The article mentions power usage, and I would bet cost is also a factor - this is the reason many cheap SoCs only have USB2. One day I'm sure the cost will be low enough such that it will start appearing on "prosumer" equipment, then filter down.

However sometimes cost isn't the only factor, like in the case of two-pair gigabit https://en.wikipedia.org/wiki/Gigabit_Ethernet#1000BASE-TX.

Here is a quick tutorial showing what uMatrix can do https://github.com/gorhill/uMatrix/wiki/Very-bare-walkthroug.... As you can see, it gives you an easier way to have fine-grained control of each individual type of resource. It also allows you to configure third-party domain resources globally, or per domain. This allows you to do something like allow youtube embedding (js + xhr) on all websites at once.

It's a mathematical definition, of course it will break down a bit when you introduce it into the real world. I guess a more pragmatic definition would be "The ability for a runtime to delay, or repeat the execution of a function (with its arguments), and always get the same result".