- Removes half of the static bootstrappers, and adds 4 /dnsaddr bootstrappers instead
- Updates go-libp2p for /dnsaddr support
- Updates go-libp2p-host because that was missed some time ago
<!– Before filing an issue, please search the existing issues (both open and closed) to see if your report might be duplicate –> <!– Please don’t file an issue when you have a support question, send support questions to the mailinglist or ask them on IRC (https://www.powerdns.com/opensource.html) –>
<!– Tell us what is issue is about –> - Program: Authoritative, Recursor, dnsdist - Issue type: Feature request
<!– Explain in a few sentences what the issue/request is –> The order of linux distributions (especially Debian and Ubuntu) is really not ideal. It favors old things for no particular reason.
I was looking for the repo info for Debian 9 Stretch (but half the time i’m looking for an Ubuntu or a different Debian, or potentially a RHEL).
There are a number of ways to improve this
1. Don’t auto expand the second level (distro releases) when someone expands the first level (distro brands)
2. Change the order to favor newer releases over older releases
3. Possibly split LTS out of the normal flow (they’re in a lot of ways a distinct product from normal releases – with a distinct customer base – consider RHEL vs. Fedora – they’re very related, but practically unrelated customers – same for CentOS, very related, but distinct customers)
4. Switch to a series of
[ |v] drop downs instead of a tree, an example of that is used by the PPA system, as in:
a. click “Technical details about this PPA”
b. select an item in:
Display sources.list entries for:
Tree auto expanded to show Debian 8 children which obscured the presence of Debian 9.
Note that it’s much worse for Ubuntu, the first entry expanded is 14.04 (the older LTS), the second is 16.04 (the latest LTS), the third is 16.10 (obsolete), the last is 17.04 (the current release).
Note: the behavior is also not very helpful at the next tier: If a user is looking for something, they probably only care about a single product (auth, dnsdist, recursor, metronome) – showing them all of the various versions of all the products they don’t want isn’t helpful.
w/ a dropdown, I’d probably preselect the latest release branch but have “master” above and all the older things below.
Make it easy for customers to pick the right product.
This is not possible yet, as github is bugged
go-ipfs version: 0.4.10- Repo version: 5 System version: amd64/linux Golang version: go1.8.3
If the .ipfs directory is a symbolic link the repoSize as returned by
ipfs repo stat or
ipfs stats repo will always return 9 bytes regardless of actual data stored
With symlink ``` ~$ ls -al lrwxrwxrwx 1 ipfs ipfs 9 Jun 22 2016 .ipfs -> ipfs_data drwxrwxr-x 5 ipfs ipfs 4096 Jul 12 01:25 ipfs_data
~$ ipfs repo stat NumObjects: 204114 RepoSize: 9 StorageMax: 800000000000 RepoPath: /home/ipfs/.ipfs Version: fs-repo@5 ```
~$ ipfs repo stat
These should include:
Include instructions for developers for:
I’m very excited about the badger datastore, it seems to be very optimized for a lot of the same things that ipfs needs.
When i first looked into it, the interfaces had no error handling, but now they have fixed that problem. I would like to get a badger datastore backend written so we can start testing how ipfs performs with it.
go-ipfs version: 0.4.9- Repo version: 5 System version: amd64/windows Golang version: go1.8.1
<!– One of following: Critical - System crash, application panic. High - The main functionality of the application does not work, API breakage, repo format breakage, etc. Medium - A non-essential functionality does not work, performance issues, etc. Low - An optional functionality does not work. Very Low - Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release. –>
Started ipfs daemon:
Runs for a bit and connects to peers.
Starts throwing errors in the console.
[0;37m16:48:35.891 [31mERROR [0;34m bitswap: [0mError writing block to datastore: Access is denied. [0;37mbitswap.go:322[0m
[0;37m16:48:39.904 [31mERROR [0;34mcommands/h: [0merr: write tcp4 127.0.0.1:5001->127.0.0.1:56762: wsasend: An established connection was aborted by the software in your host machine. [0;37mhandler.go:288[0m
Hello, it seems there is a problem adding packages.synocommunity.com repository to rs3617xs+ - it reports “Invalid location”. The same procedure on RS2211 works well.
Here are the http request and reply sniffed from the network … (packages.synocommunity.com was resolved to 18.104.22.168)
GET /?package_update_channel=beta&unique=synology_broadwell_rs3617xs%2B&build=8451&language=csy&major=6&arch=broadwell&minor=0&timezone=Amsterdam HTTP/1.1 Host: packages.synocommunity.com User-Agent: synology_broadwell_rs3617xs+ DSM6.0-8451 Update 2 (package) Accept: */*
HTTP/1.1 422 UNPROCESSABLE ENTITY Date: Wed, 02 Nov 2016 11:47:48 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: __cfduid=d1523eb3770083bbc6dad219f752ed3ab1478087268; expires=Thu, 02-Nov-17 11:47:48 GMT; path=/; domain=.synocommunity.com; HttpOnly Server: cloudflare-nginx CF-RAY: 2fb75a9440222348-FRA <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <title>422 Unprocessable Entity</title> <h1>Unprocessable Entity</h1> <p>The request was well-formed but was unable to be followed due to semantic errors.</p>
(and one more POST request using the same parameters)
Using IPFS master, d48cd56 Context: I have about 7 GB of pinned files, about ~100kb each. (The ipfs blocks directory is 18GB in size), migrated from IPFS 0.3 to 0.4.
ipfs cat of a short text file I added just before doesn’t seem to terminate after a few minutes of continuously reading ~400MB/s from an SSD where the IPFS blocks are stored.
I also noticed, that with smaller sized local ipfs block dirs (7 GB), freshly created on 0.4,
ipfs cat does succeed, but after about ~5 seconds of full CPU usage. (it succeeds possibly because all the just added 7GB of data is cached in memory)
Seems like either a serious bug or a performance problem.
Question: Does IPFS use a trie for accessing/indexing hashes? If not, it definitely should.