ipfs / distributions Goto Github PK

View Code? Open in Web Editor NEW

48.0 48.0 32.0 6.1 MB

Legacy dist.ipfs.tech website and artifact build tools

Home Page: https://dist.ipfs.tech

License: MIT License

Makefile 2.84% Shell 15.57% JavaScript 7.26% Roff 0.58% HTML 4.09% Less 68.97% Dockerfile 0.69%

distributions's Introduction

IPFS is an open system to manage data without a central server

Check out our website at ipfs.tech.

For papers on IPFS, please see the Academic Papers section of the IPFS Docs.

License

MIT.

distributions's People

Contributors

Stargazers

Watchers

distributions's Issues

Trying it out :) - Feedback

I've did a fresh git clone, make all and gulp serve to give a test to the new distributions page, before saying anything, huge ^5 for all the work put onto this! :)

Here are things I noticed:

All the download links return 404.
I know you were following the ones in https://nodejs.org/en/download/, but since we don't have 'boxes', the lack of borders makes them look desaligned.
Can we also have a link for the tarball with the source code?
What is the plan to do with all the white space, for example in the go-ipfs? Will we add videos there?

Clarify what ARM version we are supporting

See https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures for details

"All versions" link is too well hidden

I had problems finding it, and others seem to have same problem.

Add `date` field to each version's release.

the index page shows a date.
it was hardcoded to January 1, 2016
@whyrusleeping set it to data.date for the go-ipfs 0.4.0 release.
@whyrusleeping added a date field manually to 0.4.0 this time.
other releases dont show dates.

TODO:

add date to other old releases manually
make sure date is generated automatically in the future

Builds of go-ipfs for musl libc

Currently none of the binaries on dist.ipfs.io can be used on a musl-based Linux, since they're all dynamically linked against glibc (which is the libc they are built on). We should provide an extra Linux/musl build.

Example: the linux-amd64 build would have an additional linux-musl-amd64 build.

`ipfs add -q -r releases` Doesn't work because electron app creates a symlink on the Libraries folder

Following: ipfs/kubo#616 (comment)

Reference for packages available in other package managers (Arch, Brew, and so on)

Arch - ipfs/kubo#7
Brew - https://github.com/Homebrew/homebrew/blob/master/Library/Formula/ipfs.rb

Reproducible builds

@dignifiedquire you mentioned in a hangout this week that making the JS builds reproducible is difficult.

Wondering if this would help: webpack/webpack#408
TL;DR add to webpack config plugins section: new webpack.optimize.OccurenceOrderPlugin()

I imagine doing npm shrinkwrap might help lock down dependencies as well.

You might be thinking of more sophisticated problems than I am though 😉

make is failing on gobuilder

» make all                                                                                               
echo "** making go-ipfs **"
** making go-ipfs **
cd dists/go-ipfs && make
chmod +x go-ipfs-dist
./go-ipfs-dist all
--> making v0.2.2
---> preparing ../../releases/go-ipfs/v0.2.2
---> getting archives from gobuilder...
No downloads has been found for your request.
---> failed.
error: failed to make v0.2.2
make[1]: *** [dist] Error 1
make: *** [go-ipfs] Error 2

asciinema for go-ipfs

we need one. here's a super basic one i made: https://asciinema.org/a/ev9so7mlfqme0254s50oqiw1l but it's so off.

i want to cover:

ipfs init
ipfs cat the welcome readme
ipfs add -r . a big directory of files
ipfs cat files just added
ipfs ls dirs just added
ipfs add a big file (progress bar)

maybe we could cover:

changing a file, adding dir again, noting some same, some different hashes
statrting ipfs daemon
ipfs swarm peers
ipfs cat through the network -- a file i didnt have.

what else? other ideas?

Builds of go-ipfs for Android

This would also need to set up the tooling required:

android sdk
https://github.com/ligi/IPFSDroid will have more information on building for android

cc @ligi

Replace go-ipfs v0.4.0-dev with v0.4.0-rc1

v0.4.0-dev is debris from when we tried to get gobuilder.me to build from the dev0.4.0 branch.

The only release of 0.4.0 so far is v0.4.0-rc1.

All release dates hardcoded to January 1, 2016

see https://github.com/ipfs/distributions/blob/master/site/public/index.jade#L45

I'm guessing this was a workaround until release date got built into the build scripts. We can probably grab the date on the git tag that's being used.

No gobuilder

Trying to get this running it fails for me as I do not have gobuilder setup, and I'm not sure how to go about that. Can we get rid of that as there is already a todo in the code?

bin/gobuilder-cli: bin
    #TODO: make this not require a go compiler...
    go get github.com/Luzifer/gobuilder/cmd/gobuilder-cli
    cp $(gbcli) bin/gobuilder-cli

cc @jbenet @whyrusleeping

Clicking ipget doesn't mark it as active

Clicking on ipget changes to the ipget page, but doesn't mark ipget as active in the menu.

Go downloads hierarchy is broken

The version listings for the go packages got screwed up, they now have a directory for a version with just a go-ipfs.zip inside. This is broken, please restore the old schema, which is typical of traditional systems, and which tools already depend on:

go-ipfs_$version_$platform.$archive -- eg go-ipfs_v0.3.11_amd-64.tar.gz - this way it is clear on a downloads folder what version you just downloaded, and it does not replace older versions.
.zip is fine for windows, but please use .tar.gz for unix platforms, as some zip tools ignore/lose permissions. since we will ship binaries and shell scripts it is important that they absolutely always keep permissions.

To be clear, we want:

.
├── go-ipfs
│   ├── latest -> v0.3.7
│   ├── v0.3.6
│   │   ├── go-ipfs_v0.3.6_darwin-386.tar.gz
│   │   ├── go-ipfs_v0.3.6_darwin-amd64.tar.gz
│   │   ├── go-ipfs_v0.3.6_linux-386.tar.gz
│   │   ├── go-ipfs_v0.3.6_linux-amd64.tar.gz

Screenshots

maybe we should have a small screenshot that shows what each "distribution" is

the go-ipfs one could have a terminal with "ipfs add -r" mid-flight (with a progress bar, etc)
the electron app one could show the menubar menu + webui
the webui dist (#7) could show the webui.

(let's start with pngs, and then levelup to short gifs.

Add ipfs logo and make IPFS link to ipfs.io

make electron-app dist

user testing feedback

@dignifiedquire this is looking great -- took it out for a spin with people.

some feedback:

i ran this by 6 people. 3 were hackers. 1 other had coded something at some point. 2 were non technical.
they all generally liked the page ("looks {good, ok, fine, functional} to me")
they all were fine navigating
they all were fine with the columns + clicking.
in iOS safari it rendered weird, the columns didnt go away after click, and the anchor was a bit offset.
2 had trouble noticing that "docs / changelog / all versions" was clickable.
it is not very clear that blue text is links in this page. it's a different color and the glow isn't very noticeable in some screens. an underline on hover would be good.
4 had trouble knowing where to download. didnt know the platform grid was links-- (1 thought it was just a listing of what it worked with). "Ok, how do i download it?" was a common question.
3 people suggested "a (big) (green) button with a down arrow".
might be ok to add "Downloads:" as a title above the grid (i dont like how it looks, but it makes it clear. -- or "Choose platform to download:")
but what will be very good is to have smart button that detects user's OS and downloads that platform. fine to delay till later if much trouble.
people were distracted by much text-- fixed when i made the min-size of each distribution "page" (.d-component { min-height: 700px } -- about a screen-height's worth. when we add the asciinema or jpgs and so on it will get there, but may be good to just do it (even it blank) to make sure the user is focused on one release at a time even if there is no media.
(surprising to me) people were mostly fine once in the "all versions" part. -- crude dir listing was ok. they got to the zip! but they did snag on the platforms listing
2 people were looking for osx and did not know "what the hell is darwin?" so we should consider renaming from Go's to more common OS name

i can do more user testing if useful.

make index pages/cards

generate per-dist index card (card.html)
make the global index page (cat dists/*/card.html >>index.html)

inspired by iojs

New design pieces

RC candidates _should not_ be the default download

Looks like go-ipfs @ 0.4.3-rc1 is the default download at https://dist.ipfs.io/ right now. This is not great, because RCs could have serious issues and vulnerabilities.

In this case, 0.4.3-rc1 is thought to be much better than 0.4.2, but i'm not sure this merits skipping the release process... this is the sort of thing that can make small problems big.

version listing does not have `latest` symlink

the version listing inside a distribution should have a latest symlink, which is used to enable links like https://dist.ipfs.io/go-ipfs/latest/dist.json

to be clear:

.
├── go-ipfs
│   ├── latest -> v0.3.11
│   ├── v0.3.11

(go-ipfs) get older builds to work from gobuilder

Add a way to link to the latest version directly

There MUST NOT be a dependency to update this website when a new version is released. That's super cumbersome. The gobuilder links explicitly avoided this problem. This was not by accident, but by design.

One easy way to do is is to add a release dir (to mirror the git branch name) that gets updated by the dist.ipfs.io repo release process. this can symlink the files directly like so:

ls -l go-ipfs/release
go-ipfs_release_linux-386.tar.gz -> ../v0.3.11/go-ipfs_v0.3.11_linux-386.tar.gz
go-ipfs_release_linux-amd64.tar.gz -> ../v0.3.11/go-ipfs_v0.3.11_linux-amd64.tar.gz
This has the unfortunate side-effect that the files will be downloaded as go-ipfs_release_linux-386.tar.gz instead of preserving a version. Not sure how to solve that yet. What we need is effectively something like a 302 redirect. I can imagine a way of importing symlinks into ipfs not as dag hardlinks but as dag symlinks that the gateway serves as 302 redirects.

Other ideas?

Ref ipfs-inactive/website#98 (comment)

Cleanup build-info and build-log

e.g. http://v04x.ipfs.io/ipfs/QmUA7DPsDZrp1qjDHfG9oGZM7Z1Jx7fosawHxu7B78rHz3/go-ipfs/v0.3.11/build-log

@whyrusleeping could you do this please?

change "interplanetary networks" copyright notice

change "interplanetary networks" copyright notice to "IPFS Community", we'll make a proper foundation later. but right now it's out of place because it should be "Protocol Labs"

need better frontend design

maybe @RichardLitt can help here?

domain?

What should the url / domain be for this site?

could be:

update.ipfs.io
distributions.ipfs.io
dist.ipfs.io
releases.ipfs.io
downloads.ipfs.io
ipfs.io/downloads
ipfs.io/dl
ipfs.io/releases
ipfs.io/dist
ipfs.io/distributions

Auto generate README.md for all versions listings

There should be README.md files inside of a distribution version listing, and inside each version listing.

Eg from https://github.com/ipfs/distributions#how-this-repo-works:

dist/index.html -- listing of all bundles available
dist/<dist> -- all versions of <dist>
dist/<dist>/README.md -- simple readme for <dist>
dist/<dist>/latest -- points to latest <version>
dist/<dist>/<version> -- dist version
dist/<dist>/<version>/README.md -- readme for <version> listing

these READMEs can be the same across versions, and should be autogenerated. They are like a human readable version of dist.json, there in case the user ends up with a big archive directory of the version. The readme could point to https://dist.ipfs.io, could point to this repository, and to `https://ipfs.io

Clean up the `build-info` and `results` files

The go version listings seem to have a build-info and results files

if these are used, their purpose should be well documented, the example listing in the README should be updated.
if they are not used, let's make sure to remove them.
I do like the build-info file, it's useful to audit. is there more information that should go here? or can we make it better machine readable? (make it json or yml)
the git hash should probably (also) go into the dist.json

scrolling to the bottom doesnt highlight correct nav item

Notice go-ipfs is selected on the left side, but i'm scrolled all the way down

one repo or many?

open ended discussion
maybe not relevant now, but in the future, as things get more complicated.

do we think that it will scale to keep all the dists in this one repo? it may be relevant to do:

distributions (this repo) - is the website, and aggregates all the others
dist-<thing> is a repo for producing all the build targets, and outputting a single ipfs hash per version.

So basically, we'd have repos like dist-go-ipfs and dist-station.

OR another option is to put the bin building in go-ipfs or station themselves, and use this repo only to manipulate ipfs hashes (i.e. can be given a hash with all the binaries, then patch it to include all the other data)

add changelogs

not added for go-ipfs -- see ipfs/ipfs-update#7 (comment)

Enforce two factor auth

As this repository will play a crucial role in enabling code signing (Ref #51) we need to enforce 2fa for everyone who has write access to this repository:

rendering issue on chromium 47

Using this url: http://v04x.ipfs.io/ipfs/QmUCqDJ2dVkdfiMrkgsM7PYNVL91GY8LdvpitxKL71biRp/

Running Chromium 47.0.2526.106 on 64-bit Linux. All text is invisible:

Firefox renders this fine, however. I haven't dug into this any deeper, but am happy to try if you aren't able to reproduce. :)

Builds of go-ipfs for NetBSD

go-ipfs 0.4.2 adds support for NetBSD

release files for go-ipfs should be go-ipfs.zip not ipfs.zip

does not have v0.3.11

Final copy for 1.0

This is the copy that needs to be written/reviewed:

Descriptions

ipfs-update
go-ipfs (review)
fs-repo-migrations

Changelogs

These are linked, but we need to make sure they actually exist (link is: <repo>/CHANGELOG.md)

ipfs-update
go-ipfs
fs-repo-migrations

Git repo weighs 160 MB

$ git clone https://github.com/ipfs/distributions.git
Cloning into 'distributions'...
remote: Counting objects: 131, done.
remote: Total 131 (delta 0), reused 0 (delta 0), pack-reused 130
Receiving objects: 100% (131/131), 159.82 MiB | 1.67 MiB/s, done.
Resolving deltas: 100% (29/29), done.
Checking connectivity... done.

Using this script: https://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/

$ ./gitsize.sh 
All sizes are in kB's. The pack column is the size of the object, compressed, inside the pack file.
size  pack  SHA                                       location
7287  2040  276eb15fbc05f26c4b4f1d8ebd907860e521412e  dists/go-ipfs/bin/gobuilder-cli
5660  5629  79fdf3b9fc6efd7cb33185dc8a55d0b646440220  releases/go-ipfs/v0.3.6/ipfs_v0.3.6_linux-amd64.zip
5660  5629  90e2d20056c02ae75facf60bd24b0e9692dd1ebf  releases/go-ipfs/v0.3.7/ipfs_v0.3.7_linux-amd64.zip
5644  5613  6468916f94ce5d3ef021f468a22d08d0efadc69e  releases/go-ipfs/v0.3.6/ipfs_v0.3.6_freebsd-amd64.zip
5643  5612  d22c22822233302ae59d1359a0aad49435cb96f8  releases/go-ipfs/v0.3.7/ipfs_v0.3.7_freebsd-amd64.zip
5627  5595  41a80697760d1f25eec3c834a8bd24239417ae0e  releases/go-ipfs/v0.3.7/ipfs_v0.3.7_darwin-amd64.zip
5627  5595  76595522458ad032b207e367fa9ad1fc68930cf8  releases/go-ipfs/v0.3.6/ipfs_v0.3.6_darwin-amd64.zip
5434  5405  c9c7349009885d7ac3be4c662d02f07160e8c57f  releases/go-ipfs/v0.3.7/ipfs_v0.3.7_windows-amd64.zip
5434  5405  4069cb6cc7196570c325e0ed2d64781a15b6c7c7  releases/go-ipfs/v0.3.6/ipfs_v0.3.6_windows-amd64.zip
5337  5307  75d6f630be3c6a5d839f6f0303da397a57aeb166  releases/go-ipfs/v0.3.5/ipfs_v0.3.5_linux-amd64.zip

Haven't managed to get rid of them

webui distribution

We should probably have a "distribution" of the webui as well, but just say that the webui is distributed through ipfs, and thus accessible from go-ipfs and ipfs-app already. (i.e. it is not "downloaded").

Reason is that many people get confused and install the node package. see http://www.siliconian.com/blog/16-bitcoin-blockchain/23-beginner-s-guide-to-installing-ipfs-on-a-raspberry-pi-2

(king of like a .PHONY target in a makefile)

Links to {issues, repo}

It would be great to these links to each distribution:

issues or bugs or report a bug or report an issue - which links to $repo/issues
repo or repository which links to $repo for the distribution

The issues/bugs one is higher prio. Even in presence of repo, would still be important to have the link to issues. Many users will not know their way around github, or know to do "github repo page -> issues link", and instead we want to lead them to submitting issues + getting help asap.

We could have some text at the bottom or the top of the page describing that we use github for issues, with a link to https://guides.github.com/features/issues/. Maybe:

We use GitHub.com to host our code, track issues, and discuss solutions. If you're new to github, sign up for an account here and read about posting issues here. Then, to report problems with any of our distributions, click the "Report an Issue" link under the description.

These links could be added to the set "docs, changelog, all versions", and just make a second line.

Builds of ipget for Windows

https://dist.ipfs.io/#ipget

ipget for windows download is not available

Released artifacts must not change (prereq for 0.4.0 release)

I'm running make for the first time and it builds everything. Imagine if I was the one preparing a new release of something, this would change all artifacts of everything.

Instead, it should get all of dist.ipfs.io, and then only build what's missing, patch it in, and publish the result of that.

This is kind of urgent, since changed checksums of release artifacts will rightfully (and hopefully) set of alarm bells with users.

Include fonts rather than linking from CDN

ETA April 14, 2020

Visual standardization was fixed via #289, but we still need to include the fonts used in the site so it can be fully delivered over IPFS.

ETA April 2020

Standardize CSS and fonts against those used in www.ipfs.io and/or docs-beta.ipfs.io to a degree that brings them visually into line with existing branded materials, but stopping short of effort-heavy rebranding (we'll be tackling this as part of overall approach to ipfs.io in the future).

Original issue text

It should ideally be vendored

Invalid SSL cert

https://dist.ipfs.io is serving an SSL cert that doesn't match the subdomain. Since links have started appearing various places (e.g. the README at https://github.com/ipfs/go-ipfs) and the site currently prompts a giant insecure connection warning in most browsers, this should probably be addressed soon.

Add an about section at the top of the page

I'm thinking that it would be helpful to have a description of the page at the very top, making things clear. Perhaps: