HN user

286c8cb04bda

414 karma
Posts1
Comments152
View on HN

It's sending the "wrong" one --

    $ curl -I http://lcamtuf.coredump.cx/squirrel/
    HTTP/1.1 200 OK
    Date: Thu, 11 Aug 2016 05:18:00 GMT
    Server: Apache
    Last-Modified: Mon, 19 Sep 2011 23:31:49 GMT
    Accept-Ranges: bytes
    Content-Length: 135938
    Content-Type: text/html

anki is good, but for some reason they have a self signed certificate on their site, which I haven't checked out yet, so I won't link to it

It's not self signed, it's the wrong domain (Error code: ssl_error_bad_cert_domain) HTTPS requests to ankisrs.net get a certificate for *.ankiweb.net, which is the domain the app uses for the sync web service.

1470 open issues

That's a really weak argument. Here's 5000 Firefox bugs:

    https://bugzilla.mozilla.org/buglist.cgi?component=General&product=Firefox&query_format=advanced&resolution=---&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0

The biggest recurring issue was deadlocks in the garbage collector. It would start cleanup in a subvolume and trip all over itself. After that, any I/O to that specific directory would never return. The only solutions was to reboot the server and fsck for a few hours.

Second frequent problem: Hitting 90% capacity in a filesystem has a non-trivial chance to ruin it forever. Hit the wrong code path, and, even if you immediately delete a bunch of things, I/O to that filesystem would be forever 3000% slower.

I've used btrfs (at several-petabytes-of-data scale) and wouldn't trust it any more than HFS+.

Use ZFS if you like, or XFS, or even ext4 instead.

Though they provide RSA and DSA signatures how would I verify the signatures themselves?

Ideally, it goes something like this --

1. Start with the master keys. Download them from their website & import them into your keyring.

2. Fetch signatures for those keys from some key servers. (E.g. gpg --recv-keys 6A93B34E).

3. Examine the signatures (E.g. gpg --list-sigs 6A93B34E). Do you trust anybody in that list to have verified the ownership of the keys?

If "yes", then import the release keys and verify that _they_ have been signed by the master keys. You can use the release keys to verify the downloaded binary.

If "no", then you might recurse down those keys to see if you know anyone who signed any of _them_. At this point, you'll need to consider very carefully what your trust policy is going to be.

Presumably in this editor "_" represents the "whole line" region, which leads to also "c_" and "y_".

That's not specific to this editor. In vim _ goes from the cursor to the end of the line (but does not include the newline at the end like $ does).

That's kinda close. In sign languages, individual signs can be decomposed into different elements: Hand shape, motion, position, et al. Related terms or ideas will use some of the same elements.

I'll use a couple of examples from American Sign Language:

1. The gender of a subject in a phrase is sometimes communicated by performing the corresponding motion with the specific hand shape in front of your forehead (for male) or in front of your chin (female).

2. A signer could communicate "a chair", "then he sat down", and "so help you god, jimmy, you better go sit down right now or i'm going to make you wish that you were never born" with what is basically the same sign (first two fingers on right hand tapping top of first two fingers on left hand), just by repeating it more times and with more emphasis.

Why do they do this?

This short form is "for historical reasons". That's not "they're too lazy to fix it" reasons, rather there is a very large amount of hardware deployed elsewhere which you might have to interact with making assumptions. You have to fit within the lowest common denominator of all those assumptions.

If your tools cannot handle unlimited length names, use different tools.

Because that's not possible. According to the RFC[1], FQDNs are are limited to 255 characters. Individual components (i.e. between the dots) are limited to 64 characters. Having to account for e.g. IDN, means space limits are an active concern.

[1] http://www.ietf.org/rfc/rfc1035.txt

Application configuration can be static (just hardcode localhost:3306 for your DB, for example).

I wonder how this scales when you have multiple databases, or have read-only slaves, or something like that.

Then developers have to remember to send some traffic to localhost:3306 and some traffic to localhost:3307, and who knows how many more ports.

Documentation never manages to stay up-to-date, so perhaps you could use some sort of Service Discovery Protocol to map these semi-arbitrary numbers to more memorable names.

Then, as long as you know what port the service-discovery-service runs on, you could simply query it for the address to reach your databases.

Maybe that's too much work, though. We could just stuff everything in /etc/hosts.

Am I the only one that would like to be able to setup a time range when it's allowed to use my bandwidth?

You can. After you setup a target open the Preferences window. Select the target therein and click the "Edit..." button.

The dialog that follows has an option to "Pause between [00:00] and [00:00]", where [00:00] is a drop-down which lets you pick the top of any hour of the day.

Owning things that you use infrequently is inefficient. If you could rent or borrow it for the actual time that you need it, then you are wasting (time|money|other) if you own.

It won't work on Customs and Immigration. When you're talking to them you're not "in the US" yet. After that, yes, the privilege against self-incrimination is granted to everyone in the United States, citizen or not.

Caveat: The "border search exception" has some other pretty enormous holes.

If the chance of a catastrophic event happening is one-in-a-million, then it is equally likely to happen on the 13th and on the millionth coin toss.

Assuming that the normal rate of battery fires after collisions is one per million, the probability of observing such a fire after only 13 collisions is rather low.

What you're arguing is that the probability of it happening on or before the 13th time is less than it happening on or before the millionth time -- Which is self-evidently true of _any_ probability, and is a much weaker argument.

perhaps the rate is not one per million

This is much closer to the argument you should be making. I.e. "Given that a purported one-in-a-million event occurred after only the 13th test, what is the probability that their estimate of one-in-a-million is accurate?"

(I don't know the math to answer that question, but I hope somebody that does will come along and chime in.)

  $ uname -s
  Darwin
  $ type seq
  seq is /usr/bin/seq
The man page says --

The seq command first appeared in Plan 9 from Bell Labs. A seq command appeared in NetBSD 3.0, and ported to FreeBSD 9.0. This command was based on the command of the same name in Plan 9 from Bell Labs and the GNU core utilities. The GNU seq command first appeared in the 1.13 shell utilities release.

BTW, if people haven't tried PXE booting before, it's pretty easy with dnsmasq. You can basically read the sample config file and uncomment a few lines.

You don't even need a config file. Here's a command line snippet I have saved for testing PXE installs:

    $ sudo dnsmasq -hdq -i en0 -p0 --enable-tftp --tftp-root=`pwd` -Mpxelinux.0 -F10.10.10.100,10.10.10.199