Go vgo: Semantic Versioning and Human Error - <AUTHOR> https://codeengineered.com/blog/2018/golang-vgo-semver-human-error/ <comment><USER2> Preface: vgo _specifically_ calls out the fact that maintainers of libraries have to be backwards-compatible within a major version, and that the onus is on users to put their trust into libraries not to break them appropriately:

> Modules are assumed to follow the import compatibility rule—packages in any > newer version should work as well as older ones—so a dependency requirement > gives only a minimum version, never a maximum version or a list of > incompatible later versions.

([https://research.swtch.com/vgo-mvs](https://research.swtch.com/vgo-mvs))

Back to the article - it seems predicated on this scenario:

> "Our project depends on email@example.com right now, but it doesn't work with > email@example.com or newer. We want to be good citizens and adapt, but we just don't > have the bandwidth right now."

If your deps + your transitive deps for some package are:

\- 1.5.0 (you)

\- 1.5.1 (some transitive dep)

\- 1.4.7 (some transitive dep)

vgo will choose 1.5.1.

However, if your deps for some package are are:

\- 1.5.0 (you)

\- 1.5.1 (some transitive dep)

\- 1.7.3 (some transitive dep)

vgo will choose 1.7.3 and presumedly your app will break.

In other dep managers, you might specify <1.7.0. How would this work? Grab two versions of the package (1.5.1 and 1.7.3), rewrite the import paths of the stuff that requires 1.7.3, and kind of opaquely have two version of the same thing? Or perhaps modify the way the import "xyz" works to be more opaque to solve this problem somehow? There's no nice solution to this.

This seems a fairly reasonable tradeoff; on the upside is a _very_ fast, very simple, and very predictable dependency manager. On the downside is that I have to really think about which libraries I trust not to break me instead of relying on my tool to specify ranges and the like.

Generally though, the ask from vgo is that folks care about backwards compatibility and think about trust, rather than covering up the issue. It's not going to be great for everyone, but I like the straight forwardness of it.

<comment><USER3> > Grab two versions of the package (1.5.1 and 1.7.3), rewrite the import paths > of the stuff that requires 1.7.3, and kind of opaquely have two version of > the same thing?

Yes, in systems like Cargo you end up with multiple versions of the same package. This typically "just works". It works so well, in fact, that often times people don't even realize they're using multiple versions of the same package, and they _want_ Cargo to report an warning here.

> This seems a fairly reasonable tradeoff; on the upside is a _very_ fast, > very simple, and very predictable dependency manager.

For other package managers, speed of the core dependency resolution algorithm has never been a problem for me or anyone else I know.

<comment><USER4> Go packages can have side effects. For example a global map, background goroutines, shared connection pools, etc. Including multiple versions of the same package would not work for these cases.

Actually this isn't really a go specific thing. If I have a struct defined in a package version 1 that gets an extra field in version 2 how can I possibly reuse that struct between packages.

<comment><USER5> Because every other dependency management system has realized that _nothing_ about the version number actually tells you anything about compatibility & so they don't even try.

That vgo encodes semver as sone sort of contract system is crazy pants on a whole new level.

<comment><USER6> Many package managers interpret semver in a similarly mechanical way, e.g. npm, bundler, cargo (and, I think, elm-package, and I'm sure others too), but they choose different versions based on that information.

<comment><USER7> And crucially, in these systems you are given an escape hatch (declaring versions that are not ok), which vgo does not support.

<comment><USER8> I think vgo allows you exclude specific versions in go.mod. It only works for specific versions, not ranges though

<comment><USER7> There are exclusions, but they are only available for the current module:

> Exclusions only apply to builds of the current module. If the current module > were required by a larger build, the exclusions would not apply.

[https://research.swtch.com/vgo-tour](https://research.swtch.com/vgo-tour)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> So what's happened here is there's a bug in in gRPC 1.8.

What the OP wants is a way to say, "hey, our software is broken with this buggy version of gRPC," as part of the dependency requirements. I can see some value in that, but it also feels like a case where just documenting it in the README would not be super-unreasonable.

As a practical matter, _any_ time a dependency A says it wants some other dependency B at version V, if you are using B at a version U>V, you are running in a untested configuration, and may encounter problems. (But! this will only happen if you are specifically requesting U>V, or if you have some other requirement A2 requesting B@U. In the latter case, again, you are running a new, untested combination of software, and there might be problems.)

An alternative to this would just be allowing multiple copies of B at the same major revision, B.U and B.V. But due to Go's use of package-level global variables, that is just as likely, if not more so, to cause bugs, since not all packages will see the same set of shared variables.

It does seem like extending the vgo to allow != version requirements might be reasonable. Not full-on <=, which breaks builds or leaves them unsat forever, but just a != to say "hey this version is buggy and we know we don't work with it."

<comment><USER10> > So what's happened here is there's a bug in in gRPC 1.8.

Yeah I don't understand how this is vgo's problem.

In the follup post it shows that they are importing the buggy gRPC version directly: [https://codeengineered.com/blog/2018/golang-vgo-broken- dep-t...](https://codeengineered.com/blog/2018/golang-vgo-broken-dep-tree/)

So doesn't that mean that they can just file a bug report upstream to get the regression fixed in 1.8.1, and exclude 1.8.0 in the meantime?

<comment><USER11> I agree. I don't see a vgo issue.

The behavior in the example was broken by a release, but could have as well been restored by a patch release as restoring behaviour would not have broken the API.

See [https://news.ycombinator.com/item?id=17123583](https://news.ycombinator.com/item?id=17123583)

</comment></comment></comment><comment><USER12> One possible 'solution' to this is to disallow publishing minor versions that break the api, basically compare all the public signatures to see if they change. E.g. adding a new field is ok, changing a field type is not, adding varargs parameter is ok, changing the order of parameters is not etc etc.

The problem with this solution is that _behavior is part of the api, but it is not encoded anywhere that can be compared automatically_.

That's exactly what happened in the example in the linked article. Two new fields were added (no problem, that's allowed), and the implementation of another field was changed. This change is either fine because it doesn't change the behavior (refactoring, optimization, fix a bug, etc) or not fine and it changes behavior that breaks existing code, which is what happened in the example.

This behavior was not encoded anywhere, so an automatic publishing gate wouldn't have caught this.

<comment><USER13> It's not just public signatures, its also things like types—even private types. For example, if public struct type Foo has a private member of private struct type bar, and private type bar is changed to add a field, this changes the public interface because the memory layout of the type has changed.

<comment><USER14> eh... does this matter though? Go uses static linkage, you have to recompile your code when you update third party libraries anyway.

<comment><USER5> It can cause behavior changes. Especially around memory usage & gc.

</comment></comment></comment></comment><comment><USER15> vgo was explicitly designed to balance out two needs: (1) the need to use known good versions of the dependencies, and (2) the need not to burden dependency consumers with meaningless constraints (especially with an upper limit on the version). This article shows* why the first need is important, but it does not give vgo the credit for satisfying it with its minimal version selection (and, indeed, for providing a more stable and hence reliable solution than maximum version selection), and it misses the value of the second need. In my experience, the upper limit on the minor version is most often arbitrary, and in some cases when it is not, a future minor version reverts the mistakenly introduced incompatibility. Therefore vgo approach has unique advantages over other version selection methods, and it should not be discounted for the lack of a feature necessary to provide them.

* The article says that "Prior to 1.4.0 there was one function of MaxMsgSize" which "had previously set the size on both send and receive" but it does not substantiate this claim, and it may be false since go-grpc 1.3.0 documents that "MaxMsgSize returns a ServerOption to set the max message size in bytes for inbound mesages" [https://github.com/grpc/grpc-go/blob/v1.3.0/server.go#L166](https://github.com/grpc/grpc-go/blob/v1.3.0/server.go#L166), and it has not changed in go-grpc 1.12.0 [https://github.com/grpc/grpc-go/blob/v1.12.0/server.go#L228](https://github.com/grpc/grpc-go/blob/v1.12.0/server.go#L228) which strongly suggests that this is not a bug.

<comment><USER16> > it does not give vgo the credit for satisfying it with its minimal version > selection (and, indeed, for providing a more stable and hence reliable > solution than maximum version selection)

I did not argue that because it doesn't do that. In an effort to not spoil things, because Sam Boyer has done a lot of work on this and wants to write about it, I won't say to much.

MVS does use a maximum. It's the major version number in SemVer. It's implicit. You can't override it when dealing with transitive dependencies. For it to always be a safe value people have to always follow SemVer. Unfortunately, they don't. In a perfect world this would work. Unfortunately, people are fallible and we need a system that works in light of that.

<comment><USER17> Just had this issue recently with a Python library. It claimed to be "out of beta". A month later they broke half the public API moving from 0.3.0 to 0.4.0. Although to be fair, this project didn't claim to be using SemVer.

<comment><USER15> Breaking API between 0.* releases conforms to SemVer: [https://semver.org/#spec-item-4](https://semver.org/#spec-item-4)

<comment><USER17> Interesting, I must have overlooked that before. Thanks for the info.

</comment></comment></comment></comment></comment><comment><USER18> For the uninitiated, vgo has a way to blacklist/exclude certain versions of dependency modules, but it only works for the top-level module being built. Exclusions from deeper dependencies are not honored in order to avoid an np- complete satisfiability problem ([https://research.swtch.com/vgo- mvs](https://research.swtch.com/vgo-mvs)).

<comment><USER16> Two quick thoughts...

1\. By not automatically hoisting that information there is a requirement for the developer to know those details for all transitive dependencies and handle those issues themselves. A task that was automated under dep (and in other languages) is now a manual task in vgo. I do not look forward to doing that when I import Kubernetes into a project as a dependency.

2\. Writing a solver that can work over a rather large codebase (e.g., kubernetes) in a timely manner (as fast as those for other languages) can and has been done. Why are we trying to avoid satisfaction problems, whom do they benefit, and why?

</comment></comment><comment><USER19> > _The issue Sam called out about handling the case where someone isn 't > following the spec. This can be on purpose or by accident. It's not uncommon > to find it._

This is a common occurance. So common - in fact - that I think it's almost always better to either pin everything or nothing and hope the unit test will find any breaking behavior.

<comment><USER16> This is a slightly tangential issue to pinning. With MVS and vgo you cannot set a maximum version. When the resolver walks the tree it doesn't know when a version is too new and could break things. Even if it pins it could pin an incompatible version.

Maximum version information is not communicated.

Note, I'm the posts author.

<comment><USER20> Matt:

> This is a slightly tangential issue to pinning. With MVS and vgo you cannot > set a maximum version. When the resolver walks the tree it doesn't know when > a version is too new and could break things. Even if it pins it could pin an > incompatible version.

This just isn't true. The number you put in the go.mod file can't encode the max version: true. But it won't change underneath you so when you run "vgo list -m" and determine the solved version, it won't change from that.

<comment><USER21> You're right, MVS is deterministic without a lockfile, which is what you're asserting it solves.

The issue it _does_ have is one where a transitive dependency is known bad by one of your immediate dependencies, but there's no way to declare that to the resolver.

Here's a concrete case:

1\. I depend on cool-framework, min 1.5.0

2\. I depend on boring-library, min 1.0.0

3\. cool-framework depends on boring-library, min 1.0.0

4\. cool-framework receives bug reports that boring-library 1.5.0 breaks cool- framework.

5\. I upgrade boring-library to min 1.5.0. Everything builds and tests okay, but I get breakage in my staging env.

There wasn't non-deterministic package install behavior, but I still ended up with breakage that could have been prevented after (4) in a system that allows library dependencies to articulate more complex version constraints than "min version". In Rubygems or Python, with or without a lockfile, cool-framework could update its dependency on boring-library to specify "min 1.0.0, less-than 1.5.0" until the breakage is fixed.

<comment><USER12> Ok so what happens when boring-library v1.5.1 is released that fixes the breakage, right after the maintainer of cool-framework goes on vacation? Now you have the opposite problem: you _can 't_ update to a perfectly compatible version because one of your dependencies can enforce arbitrarily complex constraints on which libraries you can include. Now the problem isn't a simple "oops gotta revert the upgrade until later" which either library can fix, now the issue is that _one_ of your dependencies is blocking all upgrades for (now) no reason.

There are problems either way. I think the other benefits that MVS enables is worth choosing one of these problems over the other.

Edit: As mentioned upthread, vgo supports exclusions for the top-level module. This doesn't directly help here currently, but what if exclusions in dependencies produced a warning of a possible incompatibility instead? I think that would solve the issue of you not knowing that an upgrade could break things.

<comment><USER22> I think a pretty good spot in the design space would be to respect specified incompatibilities with specific versions, but not ranges. Maybe even require a comment attached to the incompatibility constraint, which would explain the problem.

Bugs happen, and users should have some tools for that situation, but if a library is repeatedly releasing one broken version after another, you probably just shouldn't use it.

<comment><USER23> > but if a library is repeatedly releasing one broken version after another, > you probably just shouldn't use it.

Your assumption here is that it was the boring-library version 1.5 that was broken, in reality it could be that they changed something that wasn't documented and was only an implementation detail, but was relied on by cool- framework (e.g. getting a list back sorted in one particular way in 1.4 and sorted in another way in 1.5 where the order was never part of the API contract).

<comment><USER22> Good point. In this case, the bug is in cool-framework, and I don't know that I see a great solution, regardless of the expressiveness of the constraint system. Ultimately I don't think there's a way to rule that out short of specifying exact versions. Unfortunately you can't retroactively change the version bounds for an existing release, so any library that specifies an upper bound admitting any yet-to-be-released version runs this risk.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> MVS sucks, except maybe to protect some users of libraries from their own stupidity. I'd rather not have to deal with that. The way Cargo and other tools do it works perfectly fine and is well integrated with SemVer. Default behavior is to upgrade to the latest non-major release, but it's easy to override for libraries that are more volatile or less trusted.

</comment><comment><USER16> I'm amused...

While this was on the homepage or hacker news, vgo was marked as accepted. It's the timing I find amusing.

[https://github.com/golang/go/issues/24301#issuecomment-39076...](https://github.com/golang/go/issues/24301#issuecomment-390766926)

<comment><USER20> Yes, it is amusing that this objection to the vgo proposal are only now coming forward when it was proposed 2018-03-20, 2 months ago, and the design document a month before then.

<comment><USER24> Russ and the core team ignored the dependency management issue for years, and only responded to the community-led `dep` initiative after a year and a half. The `vgo` proposal was something like a hundred pages of dense technical details, and Sam has a full-time job. I think the sense of urgency you're implying is both artificial and unfair. It's been years already; we can wait another month or two for the details to shake out.

<comment><USER25> > The `vgo` proposal was something like a hundred pages of dense technical > details, and Sam has a full-time job

Does that mean 2-3 months are not enough to read 100 pages document and respond specially from people who are most concerned about package management? Or that Sam should be the only one to respond to this?

</comment></comment></comment></comment><comment><USER26> Minimum-version-selection is exactly equivalent to giving an opaque cookie to the name of every version.

"I need libfoo version ScreamingOrangutan"

There's nothing to be done with a numeric string other than match it, so you might as well choose something memorable or with meaning to humans.

<comment><USER12> No? An MVS constraint like "1.2.0" will match any "1.X.Y" where X >= 2, and the one that's chosen is the first version that matches all the constraints.

Lets say you've walked the dependency graph for a project and somewhere dependency A is requested 3 times: "v1.0.0", "v1.2.0", "v1.2.1" which each mean (respectively):

        anything at or after v1.0.0
        anything at or after v1.2.0
        anything at or after v1.2.1

The minimum version that satisfies all of those constraints is simply the last listed version, v1.2.1, so that version is selected. Note, you can manually choose a later version by asking for it directly, e.g. add "A v1.2.10" directly to the dependencies of your root project and it will be chosen. Or add a new dependency that requests "A v1.3.0" or update a different dependency that requests "A v1.3.2" and the last one will be chosen.

I'm surprised there is still so much confusion about what MVS actually does. The actual algorithm is just a sort function. I blame the name, it doesn't describe what it does very well.

<comment><USER26> This is perfectly reasonable -- and not what was described to me when I asked about it, which also fit the name better than this does.

That is a terrible name.

</comment></comment></comment><comment><USER27> Super confusing that they picked a name that's so similar to VG (the tool to manage your go workspaces, similar to python's virtualenv): [https://github.com/getstream/vg](https://github.com/getstream/vg)

<comment><USER28> The name is not important, it's temporary. It's going to become the regular "go" tool in one of the next releases.

</comment></comment><comment><USER27> 1\. You should always fix your versions so things don't automatically upgrade 2. A good test suite will catch when things break so you don't find out in production. 3. Combining the above 2 it becomes easy to occasionally see which packages changed and upgrade to more recent versions. 4. After trying out a ton of dependency management tools (python, ruby, node, go, java) I think Yarn is the nicest solution i've worked with so far.

<comment><USER29> > don't automatically upgrade

You've missed the point; code neither automatically upgrades with MVS or with a lockfile. In both cases, it's a conscious decision to do so.

Helm likely had to update its dependencies (e.g. k8s dependency for k8s version compatibility) to solve a business problem, which makes it difficult to trivially downgrade that dependency (and thus break the business)

> A good test suite will catch when things break so you don't find out in > production

helm has a good test suite; it wasn't good enough. A test suite is rarely, if ever, "good enough" to catch all bugs. That being the case, we must design in such a way that when a bug does occur, it can be easily resolved.

vgo reduces how many knobs we can twiddle to resolve a bug.

> After trying out a ton of dependency management tools (python, ruby, node, > go, java)

None of those are dependency management tools. python has easy_install and two versions of pip. ruby has gem, bundler, and the mess that predated that. node has npm and yarn. go has dep, glide, gb, go get, and dozens of others. Java has maven, gradle, and others.

> I think Yarn is the nicest solution i've worked with so far

Totally irrelevant information without any additional data on that conclusion.</comment></comment>


Clearbit Open Graph Logo Spec - <AUTHOR> http://blog.clearbit.com/open-graph-logo <comment><USER2> Maybe I'm missing the point of some Open Graph properties, but in this case... what's wrong with just using the HTML standard <link rel="icon" href="/path.png"> tag, which is already well-specified, well-supported, and even includes an optional "sizes" attribute?

[https://html.spec.whatwg.org/multipage/semantics.html#rel- ic...](https://html.spec.whatwg.org/multipage/semantics.html#rel-icon)

<comment><USER3> In general we've found that companies are using the icon rel for favicons (16x16 icons) which don't do a good job of representing a company logo at larger sizes.

<comment><USER2> If you're looking for positive intent, maybe propose that sites explicitly set the sizes attribute? Either way, you're asking folks to modify their <head>. Embracing the icon rel avoids duplicating effort.

<comment><USER3> Yes good point! We'll make sure that we pick up icon rels that point to pngs or jpgs (not icos) too.

</comment></comment></comment></comment><comment><USER4> We are planning on using your Logo API (and other APIs) in a new project and really appreciate the service and intent behind this new initiative.

</comment><comment><USER5> Half of the companies i searched for were either incorrect logos or ones that clearly looked like a random google image search.

</comment><comment><USER6> s/greyscale/grayscale/ please

<comment><USER7> This is one of those silly english things. Grey/Gray are both acceptable spellings.</comment></comment>


Do not use Selenium for web scraping - <AUTHOR> http://buklijas.info/blog/2018/12/15/do-not-use-selenium-for-web-scraping/ <comment><USER2> > The only exception that I could see for using Selenium as web scraping tool > is if a website that you are scraping is using JavaScript to get/display > data that you need to scrape.

Like 95% of web sites?

<comment><AUTHOR> Scrapy does have the solution for JavaScript with Splash, but I have never used it, so far I always found some workaround.</comment></comment>


Bing keeps rising, now 11.5% - <AUTHOR> http://www.techflash.com/seattle/2010/03/bing_keeps_rising_now_115.html

<comment><USER2> This could easily have said "Bing stealing market share from Yahoo!" Or, "Bing: still hovering around 10%". Or, "Google: How the $#&@ are they still growing?"

Specific numbers like this are always suspect. All you can really tell from this are trends... and the combined Bing/Yahoo juggernaut is still losing combined share to Google, ever so slightly.

<comment><USER3> Yes, Google is still growing (slowly). But Bing has gained _more_ points of market share than Google in the past six months. Not just grown faster, but actually added more users than Google has added.

</comment></comment><comment><USER4> Looking at this graph, it looks like Google is still rising too while yahoo is not. So Bing is taking market mostly from yahoo.

</comment><comment><USER5> I think these numbers are always suspect, and they never match what I see across any of my blogs and websites. The vast majority of search traffic to my websites is from Google to this day.

Here's the numbers for one of them in the last month:

* google (organic) 5,552 73.52%

* yahoo (organic) 872 11.55%

* (direct) ((none)) 618 8.09%

* bing (organic) 200 2.65%

<comment><USER6> I also see different numbers, GA says for my blog: google 97.56% bing 1.52% yahoo 0.50%

<comment><USER7> G: 1122 Y: 21 Bing: 1

On what is a non tech site (although the audience probably skews somewhat in that direction). But as has been mentioned, one site is not the whole internet.

</comment></comment></comment><comment><USER8> Bets are that the real story is Yahoo's demise, and the Goog benefited more than Bing. . .

</comment><comment><USER9> On this topic does anyone have experience with Bing (or Microsoft in general) as a PPC platform?

</comment><comment><USER10> Most of queries come from Facebook.</comment>


Your Media Business Will Not Be Saved - <AUTHOR> https://medium.com/@joshuatopolsky/your-media-business-will-not-be-saved-1b0716b5010c <comment><USER2> >Your problem is that you make shit. A lot of shit. Cheap shit. And no one cares about you or your cheap shit. And an increasingly aware, connected, and mutable audience is onto your cheap shit. They don't want your cheap shit. They want the good shit. And they will go to find it somewhere. Hell, they'll even pay for it.

I have said this almost verbatim to many many people, and they stare at me like I've grown two heads, and I don't get why. Content attracts eyeballs, bad content burns eyeballs. This is why TV dying (and depending on who you ask, already dead), this is why radio is basically dead, this is why content delivery systems that have large libraries full of good things have won the battle (Netflix, et al.).

If you don't fuck up, you win. Big media doesn't understand this basic rule anymore. You can't buy eyeballs anymore, not like you used to. You have to give them a reason to stay, because no one cares about your branding; no one cares that CNN said it, or it aired on CBS prime time, or even it was some NPR podcast. They are if it is accurate and/or sufficiently entertaining or thought provoking.

If you have a history of producing good content, people will subscribe/follow/whatever. If you have a history of producing bad content, people will tell other people. The worst case? You Fox News it, and an echo chamber of people hating your brand engulfs your entire company and slowly burns it to the ground.</comment>


The Sound of the Dialup: an Example Handshake - <AUTHOR> https://i.imgur.com/5Dq6K2U.png

<comment><USER2> Link to the original blog post, with more information: [http://www.windytan.com/2012/11/the-sound-of-dialup- pictured...](http://www.windytan.com/2012/11/the-sound-of-dialup- pictured.html) (You can buy the poster there and the blog has many interesting articles.)

Previous HN discussion with many comments: [https://news.ycombinator.com/item?id=5140135](https://news.ycombinator.com/item?id=5140135) (358 points, 527 days ago, 46 comments)</comment>


The Largest Land Vehicle on Earth – Bagger 288 - <AUTHOR> http://i.imgur.com/vj8HNdD.jpg <comment><USER2> for those who don't know joel veitch/rathergoods musical homage to the bagger 288: [https://www.youtube.com/watch?v=azEvfD4C6ow](https://www.youtube.com/watch?v=azEvfD4C6ow)

</comment><comment><USER3> I found the picture amazing and bit on watching the video that was posted.

There are lots of other video's about it, I wasn't a big fan of this one's song. Lyrics were good, the chorus could use some work. (It caused a slight flashback to "Badger Badger" days. )

I'm impressed that this thing is from 1978, I would have thought it was newer engineering. But NASA's Crawler-Transporter still remains the largest self- powered land vehicle in the world, and it was from 1965. I guess pocket protector based engineering still rules.

</comment><comment><USER4> created to stop a threat to humankind that we must defend against</comment>


Troubling chemicals found in wide range of fast-food wrappers - happy-go-lucky http://www.theverge.com/2017/2/1/14464370/fast-food-chemical-wrapper-pfas-pfoa <comment><AUTHOR> Let's hear both sides before we rush to any judgement about these so called facts about these so called "chemicals". Maybe some people like fluorinated chemicals?

Who needs regulations? Everyone can run their own independent tests in their own privately funded home labs and determine if the chemicals are troubling to them or not.

<comment><USER2> Not everyone can run their own independent tests, that's the point of regulations. 80% of people have neither money, expertise, knowledge nor perspective to have those tests be run for them.

Take away the regulations and you'll have polluted water, Beijing-style air, dangerous chemicals in all kinds of devices, all of it the result of greed, because dangerous is usually cheaper.

<comment><USER3> I think that your parent commenter had tongue firmly in cheek when writing that.

</comment></comment></comment><comment><USER4> How about thermal printer receipts? Most are coated with BPA. How many are in your pocket right now?

How about the fact that most McDonalds grill their burgers on grills that are covered with disposable teflon sheets? They don't tell the public that.

<comment><USER5> > How about thermal printer receipts? Most are coated with BPA.

BPA on thermal paper is indeed a worry (and of course most those "BPA-free" bottles use a different bisphenol plasticizer, just not bisphenol-A).

> How about the fact that most McDonalds grill their burgers on grills that > are covered with disposable teflon sheets? They don't tell the public that.

But a teflon sheet? Teflon is so tightly linked that it is inert that is why it's non-stick! Yes, its _production process_ is quite toxic, and of course if you heat it to the point of breaking it down you'll get toxic byproducts the will kill birds (with their hyper efficient gas exchange systems...that we don't have). I seriously doubt they heat their grills to 400 F.

I once swallowed some strips of teflon tape (settling an argument with a friend...) and they were bright white and intact (sharp edges where cut were still sharp) on the way out.

<comment><USER6> The breakdown products of Teflon are also toxic to the prostate, as I found out personally once by eating lots of eggs scrambled in a Teflon skillet. I avoid it now.

<comment><USER7> Would you mind saying more about what happened to you?

<comment><USER6> I don't remember exactly how long I had been using this skillet for my eggs -- a couple of months, perhaps, no more. I started having urinary difficulties, went to my doctor, and was diagnosed with Benign Prostate Hyperplasia. He didn't identify any specific cause nor prescribe any treatment, but somehow I got the idea that it might be the Teflon and stopped using it. The problem, which I had never had before, went away and has not recurred.

It's possible this particular skillet had been overheated at some point, though I certainly wasn't using high heat to scramble eggs. But still, why take the chance? The ceramic non-stick surfaces you can get these days work well enough and are much safer (AFAIK, anyway).

<comment><USER7> Interesting, thanks.

</comment></comment></comment></comment></comment></comment><comment><USER8> > _Schaider was surprised to find that some [food containers] contained PFOA, > a type of fluorinated chemical that U.S. manufacturers had agreed to phase > out of food packaging by 2011 and altogether in 2015. The containers may > have come from old inventory or from China, where production has continued > unabated._

Even _with_ regulations, the government doesn't seem to follow up and ensure adherence.

There's a lot of valid discussion about "security theater" at airports. And, with stories like this, I sometimes think we have a kind of "safety regulation theater" in the US too.

Laws are passed banning a poisonous substance or a dangerous industry practice of some kind and everybody celebrates the righteous victory.

But then the government stops paying attention and we still have these banned chemicals leaching into our food.

A lot of us seem to believe that simply passing a law solves the problem, end of story.

</comment><comment><USER9> At home I cook on cast-iron pans with metal utensils.

Once they are seasoned well they are remarkably non-stick and easy to clean with just hot water and a stiff brush.

<comment><USER10> I tried cast-iron (mostly for pancakes) but found that it heated very unevenly (to the point of burning food in the center and not cooking food at the edge).

I've found success with a multi-clad stainless steel skillet. Heating it to the Leidenfrost point [1] ensures that nothing sticks.

[1] [https://en.wikipedia.org/wiki/Leidenfrost_effect#Leidenfrost...](https://en.wikipedia.org/wiki/Leidenfrost_effect#Leidenfrost_point)

<comment><USER5> Think about how these cast iron pans need to work. They have a high thermal mass so once hot will have a nice uniform temperature...but you will have to wait for that to happen. A thinner pan will heat much faster but will be liable to hot spots.

I prefer a thinner pan myself[+] but I understand why people like the cast iron.

[+] one thing about those pans: the idea of a "seasoned" pan, with old, rancid oil molecules stuck in the nooks and crannies simply creeps me out. However I haven't heard of anyone actually getting sick (or suffering any olfactory effects either) so I'm sure it's all in my head.

<comment><USER11> >A thinner pan will heat much faster but will be liable to hot spots.

No, it won't (unless you're talking about a thinner cast iron pan). Cast iron has terrible thermal conductivity. A thinner pan made of a better metal, such as aluminum or copper, won't have hot spots.

IMO, the best pans are stainless steel, with plates of copper and/or aluminum in the bottom for even heat distribution. Stainless steel looks nice (unlike cast iron) and is easy to clean with steel wool or even oven cleaner if you have something really stuck in there, and with the conductive layers inside has superior performance.

<comment><USER5> Yes, I meant thinner cast iron pans, as that had been brought up in the post I was replying to. Apologies for not being clear.

</comment></comment></comment></comment></comment><comment><USER12> Do we have any estimates on how many actual deaths (or sicknesses) occur due to the use of these chemicals? I care because if we can't positively attribute death or sickness to the use of these chemicals, it seems unfair to tarnish them.

<comment><USER13> They're certainly worth tarnishing. Knowledge of PFOA and PFAS is not without science and evidence of it's harm already established. Here are two sites where the chemicals have contaminated groundwater and caused illness in communities.

[http://healthvermont.gov/response/environmental/pfoa- drinkin...](http://healthvermont.gov/response/environmental/pfoa-drinking- water-2016)

[https://www.nytimes.com/2016/08/13/nyregion/military-base- co...](https://www.nytimes.com/2016/08/13/nyregion/military-base-contaminated- water-in-newburgh-ny-state-says.html?_r=0)

<comment><USER12> The first link shows contaminated well water at very high concentrations. That's bad.

The second link mentions more contaminated water supply, and mentions cancer.

I am asking if anybody can directly demonstrate that using this in food liner has an even detectable rate of harm.

If it doesn't then there is no reasonable basis, just fear, to remove the chemicals from the liners.

<comment><USER14> Could there be harm from removing these particular chemicals?

If not, isn't the precautionary principle good?

I guess this highlights how poor humans are at identifying and thinking about risk.

<comment><USER12> removing the chemicals would make the food liners not work anymore. then the people who make the liners will find something else. It's not clear there is anything else that works as well, or is as safe.

in this case it's almost certainly true that food liners do not contribute enough of the toxin to have an effect- below a certain dosage the body simply mops up all the toxin and there is no cumulative harm. On the other hand where people _are_ exposed to massive amounts, they develop obvious and clear health problems.

</comment></comment></comment></comment></comment><comment><USER15> The problem with these chemicals is that they very easily penetrate through your skin straight into the blood. [1] (Their super low molecular weight might be the reason for that.)

So even your jacket may be a significant route of exposure, too.

[1] Dermal Penetration Potential of Perfluorooctanoic Acid (PFOA) in Human and Mouse Skin [http://www.tandfonline.com/doi/abs/10.1080/15287394.2011.615...](http://www.tandfonline.com/doi/abs/10.1080/15287394.2011.615108)

</comment><comment><USER16> Not to mention the primary source of BPA usually being cross contamination from thermal receipts.

</comment><comment> saiya-jin I do put my lunch at work on paper 2 plates, then take the lower one and cover the plate hence covering the food, put it into fridge and go to gym. lunch after gym.

When I come from gym, there is not much food left anymore in our cold buffet, by far the healthiest food I can get there).

after reading this, not so sure I want to touch those paper plates anymore, although there is no alternative at work...

<comment><USER17> Feel free to bring your own!

</comment></comment><comment><USER18> The government started the drug war to keep drugs from "destroying" our bodies.

Surely big daddy government keeps bad chemicals out of the products we all use since he is so interested in keeping us healthy and safe. Yup we are all in safe hands.

<comment><USER19> "Repeal food safety laws, let the Free Market sort it out"?

<comment><USER18> My comment is more to point out the hypocrisy of having a war on drugs but allowing shitty chemicals in the things we use.

But I'm glad the comment was not deleted and I forgive the downvoters.</comment></comment></comment>


Using LLVM's profile guided optimization in Rust - <AUTHOR> https://unhandledexpression.com/2016/04/14/using-llvm-pgo-in-rust/ <comment><USER2> this would be really neat to combine with the benchmark testing feature in rust. You could write real world benchmarks and produce the pgo profiler output, then feed that back into the compiler.

This is really cool.</comment>


Users Continue to Double-Click Online - <AUTHOR> http://baymard.com/blog/users-double-click-online

<comment><USER2> I sometimes do this mainly due to abysmal responsiveness of some website (not sure if the first click registered).</comment>


Show HN: Gisrep – Command line GitHub issues reporter - <AUTHOR> https://github.com/briggySmalls/gisrep <comment><AUTHOR> I developed this out of frustration with the manual aspects of creating release documentation at my work. This is my first post here and I would really appreciate any feedback from the HN community. Thanks for taking a look.</comment>


Ask HN: Old Technical Books - <AUTHOR>

What do you do with your old technical books? I need to free up some shelf space to buy news ones. <comment><USER2> It depends on what "old" means. A 5 year old programming book is hopelessly out of date. A 30 year old programming book is a treasure.

</comment><comment><USER3> Keep or give them away.</comment>


Github Redesigns Repository Page - <AUTHOR> https://gist.github.com/broccolini/2245234ac3a4936049e8ffc13f376986 <comment><USER2> can't preview it yet. hope i can keep my zoom level at 150% now.</comment>


PeerTube v2 - <AUTHOR> https://framablog.org/2019/11/12/peertube-has-worked-twice-as-hard-to-free-your-videos-from-youtube/ <comment><USER2> I really want to like peertube but I think its UX, at least where it stands now, is going to hold it back from ever challenging youtube.

I use youtube a lot, and for a huge range of topics. I don't have any interest in creating an account on a niche-specific instance and I think the average user who doesn't even understand what federalization does even less. However, I literally don't even understand how to make an account on what, as far I can tell, is supposed to be the go-to instance - [https://peertube.social](https://peertube.social). If there's no main platform where you can watch and discover general content then there's nothing that you can point new users to.

As a developer, if you want to host a niche video site, then peertube looks great. As a user, if you want to move off of youtube then I don't think this is how you're going to do that.

<comment><USER3> I think hosting a niche video site is more PT's speed anyway.

There are plenty of video makers that have an audience that would follow them them to a new platform and PT is one way to do that and (possibly) keep more of the cut that YT is currently taking now.

As long as YT stays dominant they're always going to have the advantage of availability and discovery so it's honestly not worth competing for makers on that front.

<comment><USER4> > keep more of the cut that YT is currently taking now.

Keep more of what cut? AFAICT, YouTube creators make money from two primary sources: YouTube ads and Patreon. The latter is independent of YouTube (i.e. YouTube doesn't get a cut). The former seems very closely tied to YouTube. How would an independent creator even go about sourcing ads to show on their independent site? Do they want to put in the effort? Would they really have enough leverage to get paid substantially more than their cut of YouTube's ads?

<comment><USER5> > How would an independent creator even go about sourcing ads to show on their > independent site? Do they want to put in the effort?

I'm pretty sure networks on Youtube are able to provide alternative ads on channels part of their networks already.

Any Youtuber can also put bake ads directly in their videos too, all the big ones already do that either in sponsorship, or literally as ads (see Linus Tech Tips as a reference).

So essentially PeerTube doesn't add anything in revenue, it only remove Youtube ads network (which can provide quite a bit of money without any effort in ads).

</comment></comment></comment></comment><comment><USER6> The peer-to-peer storage and sharing of video files isn't the hard part: it's the ability to search for and discover content that makes YouTube compelling in my opinion. Are any of these p2p YouTube replacements presenting a compelling way to search/discover content in a distributed way? Or if the search index is centralized, do any of them have a compelling model for staying funded without selling everyone's search/catalog information to data brokers?

<comment><USER7> _> Are any of these p2p YouTube replacements presenting a compelling way to search/discover content in a distributed way?_

Being "distributed" over p2p/federated architecture _opposes_ the end-user convenience of search/discovery/ranking/recommendations because of _speed-of- light_ limitations. I wrote a previous comment about this: [https://news.ycombinator.com/item?id=17578332](https://news.ycombinator.com/item?id=17578332)

Also, the previous last reply by _posting2fast_ of a partial-centralized server doesn't really replace Youtube because his proposed idea creates _new problems_ of spam videos and untrusted/fake videos. E.g. the central index of metadata says "www.johndoehomeserver.com" has a tutorial video for Algebra but when you actually stream the video from "johndoehomeserver.com", you get a spam video for Viagra instead of math instruction. Therefore, users will naturally gravitate toward the centralized servers that have _both the metadata and the actual video content._ This emergent group behavior of preferences would end up recreating another "Youtube"-like clone.

p2p architecture and torrents works well for things like pirated Photoshop or ripped Marvel Avengers movies because the users _already have the content 's title _preloaded_ in their brain_ and therefore a centralized index for discovery/serendipity of unknown content isn't necessary.

<comment><USER8> It does not necessarily oppose it. All there needs to be done is to expose a static, daily generated JSON file that contains all videos on the instance. This has nothing to do with the speed of light.

Anyone then could build a search index and build a good search experience.

To combat spam, instances should reveal up/downvotes to indicate quality, I guess your fake math video would not get much love from the community.

<comment><USER7> _> This has nothing to do with the speed of light._

Please take extra care to correctly parse what I actually wrote in response to the gp. Yes, speed-of-light is still a limitation based on the gp's constraint of _" search/discovery in a _distributed_ way"_ which means the search algorithm _avoids central servers_ and loops through a bunch of remote p2p nodes to parse a bunch of exposed JSON manifest files.

If instead, the search algorithm loops through data in a cached index server, that's no longer "search in a distributed way" that the gp was originally wondering about. That's the particular point I was responding to.

 _> Anyone then could build a search index and build a good search experience._

Now, as to the issue with that "cache index server" that pre-parses the JSON files...

The cache server that _also contains the actual video data_ will naturally _attract the most users_ because when they hit the "play" button on their smartphone, the video starts immediately instead of waiting or suffering stuttering from somebody's flakey home video server.

So, the index server with the "good experience" as perceived by users will be the one that also includes the actual videos -- basically acts as a CDN -- and this emergent behavior of user preferences defeats the decentralized ideals of p2p video.

We see that p2p of things like illegal software already works and is proven. However, p2p of mainstream videos has massive technical hurdles that oppose how _typical users_ like to discover content and play them with immediate gratification.

<comment><USER9> > If instead, the search algorithm loops through data in a cached index > server, that's no longer "search in a distributed way" that the gp was > originally wondering about.

So DNS isn't distributed because my computer caches queries?

I think this is arguing semantics rather than practicalities. Centralization isn't binary -- it's a continuum, and we care about it because of the benefits it provides, not because we think it's an end in and of itself. What we care about is the ability to aggregate search results from multiple places, to bypass search if we have a specific video URL that's being shared, and to build our own search engines without running into copyright problems.

If all of those goals can be accomplished with a caching server, then does anyone actually care if it's _technically_ decentralized?

> So, the index server with the "good experience" as perceived by users will > be the one that also includes the actual videos -- basically acts as a CDN > -- and this emergent behavior of user preferences defeats the decentralized > ideals of p2p video.

My reading of this argument is I might as well just host my blog on Medium, because Google search is just another point of centralization. And after all, for speed reasons users will prefer to use a search engine that hosts both the blog and the search results -- so eventually Google search is definitely going to lose to Medium anyway.

But of course Medium isn't going to unseat Google, because in the real world speed improvements are relative, and at a certain point users stop caring, or at least other concerns like range of accessible content and network effects begin to matter a lot more.

<comment><USER7> _> So DNS isn't distributed because my computer caches queries?_

Again, I'm not talking about a _technical_ engineering component. I'm talking about _users aggregate behaviors_. Please see my other reply of how we seem to be talking at different abstraction levels.

 _> Centralization isn't binary -- it's a continuum, and we care about it because of the benefits it provides, not because we think it's an end in and of itself._

Right, but that's not what I'm arguing. I'm talking about centralization as a _emergent phenomenon_ that bypasses the ideals decentralized protocols that the protocol's designers didn't intend.

 _> If all of those goals can be accomplished with a caching server, then does anyone actually care if it's technically decentralized?_

I guess I don't understand the premise then because if that were true, why would the adjective _" distributed"_ even be mentioned in the question _" search/discovery in a _distributed_ way?"_ To me, something about _distributed /decentralized_ as a characteristic in the technical implementation is very important to the person asking the question.

EDIT: here's another example of that type of "search without central indexing server" question: [https://news.ycombinator.com/item?id=20282397](https://news.ycombinator.com/item?id=20282397)

<comment><USER9> > I'm talking about users aggregate behaviors.

So am I.

For example, Github currently hosts the majority of Git repositories online, and I've heard people argue that this means Git isn't really decentralized, because the user behavior is to stick everything into a central repository on a central server. But when Microsoft bought Github, lots of people migrated to Gitlab, and (issues notwithstanding) it was easy for them to do so because of Git's distributed architecture. Git was decentralized _enough_ that pivoting from a bad event was still way easier than it would have been with a different architecture.

When I talk about decentralization as a practical concern, I'm not worried about users aggregating around good services. I'm worried about whether the architecture supports moving away from or augmenting those services if something goes wrong in the future.

And what I mean when I talk about centralization as a continuum is that the social aggregated behaviors you're worried about are still strictly better under a PeerTube system than they are under a Youtube system -- so there's no point in bashing PeerTube just because it doesn't solve literally every problem.

If I'm removed from a centralized PeerTube indexing service, my video is still online under the same URL, and I can still point users at a different indexing service. If censorship becomes problematic or widespread, users will move to different indexes because the network lock-in of an indexer is less than the lock-in of a social platform. As far as speed concerns go, users can fall back on slower indexers only when fast ones fail. All of this is workable.

But if I'm removed from Youtube, I have to start over from scratch with a new URL on a different site with different features that doesn't play nicely with any of the existing tools or infrastructure.

> I'm talking about centralization as a emergent phenomenon

The emergent phenomenon you're talking about is that sometimes better, faster services have more users than bad services. That's not a problem with decentralization, and that's not a problem decentralization is trying to solve. Decentralization is only trying to mitigate the harmful effects of that phenomenon.

It is not a desirable goal of decentralization to make every node in a graph have the same traffic levels -- and I mean that both on a technical and on a cultural level.

<comment><USER7> _> When I talk about decentralization as a practical concern, I'm not worried about users aggregating around good services. I'm worried about whether the architecture supports moving away from or augmenting those services if something goes wrong in the future._

I understand your point here but this sounds more like a _technical_ detail and not about social power structure. To your point, I'd also say the combination of DNS and http protocols _already allow_ for people to move their content around the internet (keep the same url) and yet people _do care about aggregation around platforms_ because they don't like concentration of power. So even though you state you don't worry about it, others do. I believe reducing platform power is part of the motivation for p2p video.

 _> And what I mean when I talk about centralization as a continuum is that the social aggregated behaviors you're worried about are still strictly better under a PeerTube system than they are under a Youtube system -- so there's no point in bashing PeerTube just because it doesn't solve literally every problem._

Btw, I'm not "bashing" Peertube. Instead, I'm trying to emphasize that it would be a mistaken belief to think that a p2p video protocol can stop _defacto_ centralization. (E.g. see history of http protocol on why that doesn't happen.) Instead of thinking about what's _technically possible_ with cache index servers, we should think about what _humans_ typically do that _inadvertently recreates centralization_ that nobody seems to want. A quality cache index server can create a _feedback loop_ that attracts both users and video uploaders which _weakens decentralized p2p_ nodes. If that particular cache server's popularity doesn't really matter because p2p nodes will always be able to independently exist, then that means _today_ we can also say that Youtube doesn't matter because you can already serve videos (AWS, Azure, home server) independently outside of Youtube.

 _> If I'm removed from a centralized PeerTube indexing service, my video is still online under the same URL, and I can still point users at a different indexing service. If censorship becomes problematic or widespread, users will move to different indexes because the network lock-in of an indexer is less than the lock-in of a social platform._

But people can make the same argument about Google's index search results. E.g. it doesn't matter if your blog or niche pet store got removed from the page 1 of the search results because you can theoretically point users to a different indexing service (Bing, or roll-your-own index ranking algorithm with Common Crawl dataset, etc). _The content at the url domain you already own is still at that url._ But we both know that answer (while true in a sense) does not satisfy people. Website owners get very upset when they lose ranking or get removed (censorship) from search results altogether. Even though there are _technical solutions_ for people to not use "google.com", it's irrelevant when their mental framework is "power & influence" of Google.

 _> The emergent phenomenon you're talking about is that sometimes better, faster services have more users than bad services. That's not a problem with decentralization, and that's not a problem decentralization is trying to solve. Decentralization is only trying to mitigate the harmful effects of that phenomenon._

I think I disagree with that but let me expand. If the goal of decentralization is some diversity (e.g. some niche content has a place to serve video outside of Youtube) then your paragraph makes sense. However, if it's the more ambitious idea of "replace Youtube", then yes, it's a huge problem of decentralization that it can't be as fast/convenient/quality as centralized services for normal users. If most mainstream users are _avoiding_ decentralized services because it "didn't solve problems it doesn't claim to solve" \-- does it mean decentralization "succeeded"? I guess there's semantic wiggle room there.

 _> It is not a desirable goal of decentralization to make every node in a graph have the same traffic levels_

I never claimed equal traffic was desirable and that seems to be an uncharitable reading of my points.

<comment><USER10> _> Instead of thinking about what's technically possible with cache index servers, we should think about what humans typically do that inadvertently recreates centralization that nobody seems to want._

The comment you link to above makes a technical argument. It asserts what you believe is and isn't _technically possible_. In that sense I feel like you are moving the goal posts.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I really like the idea behind these types of decentralized projects. However I want to mention that they rarely take off. And it's usually not due to some technical or marketing related reason. The simple economic reason for the lack of their success is that centralized organization like YouTube can operate much more efficiently than a decentralized one like peertube. Some of the reasons are: Higher organizational efficiency (faster restructuring due to an explicit hierarchy), which allows them to quickly adapt to a changing environment. Benefiting from economies of scale (buying specialized hardware for video hosting in bulk). Being a for-profit organization provides them with a constant feedback loop whether they still meet consumer demands. On top of that a constant source of income allows them to have paid employees. Paid employees are (all year round) more motivated to continuously adapt the platform to changing consumer demands.

<comment><USER12> You're right on all points.

Still, some of the most successful systems are decentralized: internet, telephone, email, torrent, bitcoin et al, the web (caveat that DNS is centralized), etc.

All of these examples are basically networks of people. Do we want these networks operated by private companies?

<comment><USER11> I think what you refer to as decentralized systems is for the most part applications on top of the TCP/IP protocol stack. Still I wouldn't call the examples you provided - with the exception of torrents - as decentralized. The internet and the telephone systems are mostly run by a few large ISPs and CDNs, email by a few large providers (Gmail, Yahoo, Outlook), and for most people the web consists of Facebook, Youtube, Spotify, Instagram, etc and a few large newspaper sites.

</comment></comment></comment><comment><USER13> I setup a peertube and companion mastodon just about a year ago. I mostly used the peertube personally. A few weeks later I noticed some user was uploading movie rips so I disabled the user account in the barebones admin user interface and set a user data limit at 2 gigabytes, the server had tons of space and this seemed generous.

Fast foward EOM, what appeared to be the same user created an automated system to create a new user, upload 2GB and move to the next. Peertubes basic ui had no way to mass ban, set filters, nothing. I had a monster bill and just unplugged the whole thing because the users were coming from a wide range of ips.

While I hope that was an outlier, the UI still leaves a LOT to be desired, and slower instances are painful to use

<comment><USER14> I love how we spend so much time rediscovering all those hard truths that we supposedly already learned in the "Web 2.0" era. Whenever you have user- generated content, you need to deal with the quality and legality of that content. FOSS and decentralization enthusiasts still seem to be imagining the internet as a place where all people willingly cooperate to create positive value for everyone, as if trolls, pirates and conspiracy theorists weren't a thing.

</comment></comment><comment><USER15> Went on [https://peertube.video/](https://peertube.video/) and immediately got a bunch of porn. Not really sure from a consumer aspect this is yet fully there from a UX perspective!

But the tech is really interesting and as a federated alternative I could see it doing really well. Best of luck to the team!

<comment><USER16> Anyone can start an instance and post whatever they want. Just because it has "peertube" in the URL doesn't mean it's an "official" instance or anything like that.

<comment><USER14> Whether a service is centralized or decentralized might matter a lot to us here, but to 99% of people it's utterly irrelevant. An implementation detail.

Therefore their mental model will equate Youtube (a service) with Peertube (an application used by multiple services). If illegal content is on some Peertube, it's "on Peertube" and it drags down all the other stuff that is "on Peertube". Just like how big advertisers withdraw all their campaigns from all of Youtube when a single popular Youtuber posts a particularly distasteful video. They don't recognize the substructure inside Youtube's community because, to the public majority, Youtube is a monolithic thing. It's going to be the same for Peertube. (Unless Peertube has a better marketing department than behemoths like Youtube, which it likely has not.)

<comment><USER16> The solution to that then is to not pretend like PeerTube is centralized by hijacking the name for your URL. If you're hosting an instance, give it a unique name. If MyCoolVideos.com is a peertube instance with a bunch of child porn, then MyCoolVideos.com is going to get labeled as a bad site, and no one will know or care if the underlying technology is PeerTube.

This is a problem with federated services in general. People always seem to want to register on the "official" instance, when really there is none. I think there should be a solution to help people make the decision, or better yet not force them to make a decision at all. Maybe some OpenID-type login/account system should be used instead of having to make an account on a single instance. Or simply stop trying to market the underlying tech, like Mastodon or PeerTube, since that's not going to make a difference to the end- user and will just confuse them.

</comment></comment></comment></comment><comment><USER17> Does anyone know of a successful server-based peer-to-peer project other than TOR and cryptocurrencies? I'm all for breaking free of the stranglehold of centralized proprietary platforms, but it also seems to me that most of the open source projects that ever really succeed at competing against entrenched proprietary incombents are the ones where a centralized service is being provided by a non-profit (e.g. Wikimedia Foundation, Mozilla, Canonical). Maybe expecting people to set up a server is just a bridge too far? Maybe there's just too many conveniences in centralization for todays users to put up with the hassle? Maybe there needs to be a centralized server that is as easy to use as the proprietary ones, and then the hardcore users can set up their own and federate with the central one?

<comment><USER18> E-Mail

<comment><USER17> Right, and web servers too - neither had much competition when it launched though, so the point about no being able to beat incumbent proprietary solutions still stands. Not to mention the majority of people get their email hosted by a proprietary service these days.

<comment><USER18> >neither had much competition when it launched though

I'm sceptikal as well, about a federated protocol being able to replace an existing entrenched player. Buy I still hope.

>Not to mention the majority of people get their email hosted by a proprietary service these days.

But all the proprietary services talk to eachother, and, mostly, talk to private instances as well. There are absolutely allowed to be proprietary PeerTube instances.

</comment></comment></comment></comment><comment><USER19> Great work! This is a good YouTube alternative I can get behind, however after reading a little bit I kind of frowned at this line on the plugin paragraph.

> You could also imagine plug-ins to sort videos in reverse alphabetical > order, or to add a Tipee, Paypal or Patreon button below videos!

Please don't consider or be tempted by those three proprietary platforms, I would much rather prefer donating using Liberapay instead.

Other than this, PeerTube has got huge potential and I would love to know what content creators (on YT or HN) think of it.

<comment><USER20> Unfortunately, there is no alternative. Everybody uses PayPal or Stripe on the backend...

<comment><USER21> > Everybody uses PayPal or Stripe

Are you implying that there are literally no other payment platforms than ones that reduce to PayPal or Stripe?

<comment><USER20> Unfortunately yes. Look at Librepay's "How it works for creators" paragraph:

"We currently support processing payments through Stripe and PayPal."

</comment></comment></comment></comment><comment><USER22> Have you tried talking to universities or university video providers (e.g. Echo360)?

A lot of universities are part of networks (e.g., the one I teach at, UNE in Australia, is part of the Regional Universities Network.) So they seem to fit the pattern of organisations that produce and host a lot of videos (course videos), don't like YouTube (we sometimes get told off for putting course videos there) and are part of networks that might like federated access to each others' video collections (while we mostly produce our own - it's not tv it's a teaching course and students usually want to hear from their teachers - sometimes we'll want to include something like a guest talk from industry).

Universities may be less interested in the bittorrent streaming aspect (they already successfully stream video and don't face the ridiculous peaks in demand because most videos aren't public) but ActivityPub to be able to search selected videos from each others' repositories could be interesting.

</comment><comment><USER23> I love this project and that is sets the focus on providing a video platform as its primary goal ignoring implementing monetizaion like crypto tokens etc. for now.

Many thanks to all the people who worked hard on getting PeerTube to what it is today.

</comment><comment><USER24> In the space of distributed video platforms, I think Peertube has the right idea: Bitchute is gaining a lot of traction, but the core issue of centralized control remains. Distributed content delivery is not enough to prevent censorship and viewer manipulation. Federation will allow many platforms to proliferate and solves this problem.

I hope Peertube gains traction, but they're fighting an uphill battle when it comes to the centralized competition. The problem that PeerTube cannot solve is engagement and stability:

\- Engagement: Unlike Youtube they cannot use a recommender system like for suggestions. Most Youtube views are from recommendations and related videos. \- Stability: As a business or media outlet, I will link to a Youtube video but not a PeerTube video because I know Youtube will host it indefinitely.

<comment><USER25> > Stability: As a business or media outlet, I will link to a Youtube video but > not a PeerTube video because I know Youtube will host it indefinitely.

If you want the video to stay up indefinitely (or at least as long as your company continues operating) you should probably host it yourself (e.g. on your own PeerTube instance), because YouTube might take it down whenever they feel like it.

</comment></comment><comment><USER26> A major differentiator for PeerTube, if they are still doing the decentralized data route, is that content publishers control their content. I am curious if that is still the case with PeerTube, but it used to be 'Mastodon for Videos'. That means a central authority can't take down videos. A site like peertube.social can only ban certain videos from being shared through its site, or ban individual users, and perhaps keep a blacklist to share with other sites.

I find it interesting that the Madame Secretary episode I watched last night (from last week) dealt with the issue of deep fakes. Particularly how easy it is, if someone is willing to put in the time, to create and publish video showing someone doing/saying something they'd never do.

Decentralized trust and reputation metrics are going to be a big thing over the next decade.

<comment><USER27> This is one of the rare good fits for blockchain. You can get the hash of a video, or hash for each segment of a video, then store that hash in a blockchain transaction, which makes it publicly verifiable while also serving as a timestamp.

A news organization could have their own wallet that they're sending currency from which acts as a verifier that it's them, then they store a hash/s of their video on the blockchain. Then you could have a facebook/twitter player that checks the hash of shared news video clips and could display a lock icon and message that says something like this video is verified non tampered from the CNN source.

</comment></comment><comment><USER28> The work done is awesome. I'll try it because the idea of self-hosting low traffic videos is interesting.

Besides, I can't stand articles that use the so called écriture inclusive. Either they write in the accepted, standardized version of French or they fork it but don't call it French.

<comment><USER29> Sprecaþ ᵹē Englisce? Language does evolve. English used to be a heavily inflected language with 5 grammatical cases and three grammatical genders, very free word order, negative concord, no do-insertion, etc.

And no matter how much AF wants people in France to say "fin de semaine", they won't. A language is defined by the body speaking it, and standards bodies can really only suggest things to them.

</comment></comment><comment> Seb-C So the only peer-related functionality is allowing a site to share videos with other sites? While I appreciate the project, this seems like a useless gadget to me.

If we want to fix the problems of Youtube we need a service that allows creators to independently make their own video distribution website as easily as creating a Wordpress blog today. It means something that just works without technical knowledge, while the creator has 100% freedom and responsibility about what is hosted.

The www is decentralized by nature, no need to reinvent crazy and complex things. We just need to be able to create a video-distribution-website as easily as a facebook page or a youtube channel.

</comment><comment><USER30> I really like the platform, but I think it would shine even more with scalable video coding support, to the point that it would be a game-changer. Unfortunately, the issue was closed [1].

Do any of you know open source libraries, or documentation on SVC for mp4, VP9 or AV1? I don't think ffmpeg supports this at all, which is a shame.

[1]: [https://github.com/Chocobozzz/PeerTube/issues/99](https://github.com/Chocobozzz/PeerTube/issues/99)

<comment><USER31> [https://en.wikipedia.org/wiki/Scalable_Video_Coding](https://en.wikipedia.org/wiki/Scalable_Video_Coding)

From what I can tell SVC adds lower resolution streams to the H264 bitstream so that devices with weaker decoders can still decode the video. This would increase, not decrease, the bandwidth.

>Do any of you know open source libraries, or documentation on SVC for mp4, VP9 or AV1

It appears to be defined as annex G in the H.264 (mpeg4 part 10) spec, so it's not available in VP9 or AV1.

The status quo is to use Adaptive Bitrate, where you publish streams at different quality levels and have the client choose which stream to use to adapt to network conditions.

<comment><USER30> > This would increase, not decrease, the bandwidth.

Not if that part of the stream isn't downloaded. It's quite easy to skip over some chunks in either HTTP (range) or bittorent.

> The status quo is to use Adaptive Bitrate, where you publish streams at > different quality levels and have the client choose which stream to use to > adapt to network conditions.

This works well if you have a good connection (uninterrupted, so that you can switch to adapt to the available bandwidth), however you cannot progressively load better and better quality content, as the low quality one will be wasted. Moreover, if the connection is interrupted, you cannot fall back to the low quality content, as you probably haven't downloaded it.

However, that's just wasteful, as it would "just" be a matter of presenting data in a manner that can be better chuncked. And for adaptative bitrate to work well, you need a reliable bandwidth estimate from the start...

Luckily, network infrastructure is improving everywhere. But that shouldn't be a reason to be _that_ wasteful, especially given that a) most of Internet's bandwidth is dedicated to video b) it would lower transcoding energy costs as well c) if everyone gets the same file, it's _much, much_ more effective for p2p, such as in that case (especially for a moderate number of viewers).

Edit:

> From what I can tell SVC adds lower resolution streams to the H264 bitstream > so that devices with weaker decoders can still decode the video.

It's more like organizing the data so that some can be dropped, and it gracefully degrades quality (FPS, resolution...) instead of dropping some images. I tried to explain it with my own terms there: [https://news.ycombinator.com/item?id=17307277](https://news.ycombinator.com/item?id=17307277) before knowing the proper name.

Searching HN, I found [https://news.ycombinator.com/item?id=18045494](https://news.ycombinator.com/item?id=18045494) which kind of answers my question.

</comment></comment></comment><comment><USER32> peertube will not catch up unless someone creates an advertisement market place for PeerTube, so content creators can monetize their content outside YouTube

here's a startup idea for you all. :-)

</comment><comment><USER33> Do I understand it correctly, that the federation in this case means that I can watch video from site A on site B, while it's being hosted on A, meaning bandwidth cost for A and no ability to for instance suggest videos A hosts, show viewer advertisement, etc?

Not sure how would I like it if I hosted instance, paid storage and bandwidth costs while noone even visits my site and views all content on site with better SEO.

<comment><USER25> Federation in this case means that you can watch videos from site A on site B, simultaneously seeding it for other users, reducing bandwidth cost for A. This only happens if site B federates with site A, meaning that it lists videos A hosts in its catalog (a mild suggestion to maybe watch them). Site A would be unable to include ads, except by baking them into the videos or descriptions etc.

I'm pretty sure PeerTube isn't aiming to provide an easy way to host an ad- supported video site. They want to be an alternative to YouTube, not an exact equivalent. If you need money to produce or host videos, their current suggestion is to ask for it: [https://joinpeertube.org/faq#what-is-peertube-s- remuneration...](https://joinpeertube.org/faq#what-is-peertube-s-remuneration- policy)

</comment></comment><comment><USER34> I like the idea, peer to peer and decentralized, but it seems like the UX and UI should be the biggest problem of it by now.

</comment><comment><USER35> I tried to play the about PeerTube video and selected 1080p and got about a second, then spent most of the time waiting while it buffered... very slowly (100-200KB/s), whereas YouTube 1080p is near-instant. I would have thought there (probably) most popular video should be well seeded, but I only see like 2 seeds on it.

</comment><comment><USER36> Some people here said that Youtube has a good recomandation algorithm, this is weird because I stil get same video recommended and auto played even if I disliked it and trying to google "how to do X on youtube" just returns youtube results for your query not web results on how to fix youtube

</comment><comment><USER37> Unfortunately, "normal people" are never going to use something like this in significant numbers.

We need a centralized video hosting website, with freedom of speech values, with huge funding, which markets to normal people.

The only way I see this happening is a single bored billionaire going for it.

<comment><USER38> We need centralized access for discovery, but distributed access for storage and accessing, as to spread the costs.

And then we need countless people on the internet to buy, install, maintain and replace the hardware that powers all of this.

That's not easy.

</comment></comment><comment><USER8> Is there a search engine to look for content across all instances?

</comment><comment><USER39> elephant in the room: how does this platform deal with DMCA requests, copyright violations, and content moderation.

<comment><USER40> That's a little bit like asking how nginx deals with DMCA requests.

It depends who's running the specific server running PeerTube.

</comment></comment><comment><USER41> My problem with peertube is - if I install it and federate I'll have all sorts of illegal videos on my computer. Nazi propaganda, child porn, anything.

I'm not going to spend hours moderating that, and I certainly don't want to explain myself to police.

And if I don't federate it's basically less convenient ftp.

<comment><USER9> > These instances can chose to follow each other (this is called federating). > For example, if the head of IT services of College X would like KarateTube > videos to appear on CollegeTube, all she has to do is federate with > KarateTube. KarateTube's videos will remain on its server but students who > are used to watching videos from CollegeTube will be able to see them.

It sounds like federation isn't an everything-or-nothing approach. You can federate with a specific instance that you trust, and even in that case, you won't host any videos on your device other than what you upload.

Would like to see confirmation, but it also seems like instances can follow in one-direction. IE, I could have a private server that follows no one, but allow other instances that want to include my public videos in their search results to follow me.

That assumes I understand the details correctly -- the FAQ is a tiny bit vague so maybe I'm misunderstanding.

</comment></comment><comment><USER42> can anyone tdlr peertube vs lbry?

<comment><USER18> Peertube is a feration protocol for YouTube-like video hosts to interact with eachother. Or more precisely, it's an implementation of ActivityPub, like Mastodon, focused on video hosting.

LBRY appears to be some kind of cryptocurrency thing. I don't know. Looks shady.

<comment><USER42> Thanks for the response, not sure why my request had been downvoted :/ I've used LBRY in the past, its decentralised video hosting as I understand it. But also allows for content producers to monetise their stuff. kauffj mentions it above - [https://news.ycombinator.com/item?id=21513640](https://news.ycombinator.com/item?id=21513640)

</comment></comment></comment><comment><USER43> It seems like they did not consider how they want peertubers to be able to monetize. On the contrary, it seems they have something against 'capturing your attention and selling it to Fanta'. I want this piece of work to be exhibit A in how staying inside your ideological bubble will ensure failure. I think it's especially sad since they used crowdfunded money so they aren't just failing on their own dime.

<comment><USER44> Most of the YouTubers I follow have ads they embed themselves in their videos, sponsored content or patreons. I'm not sure the platform running ads is actually strictly needed. (+ of course it doesn't have replace YouTube to be valuable)

It'd be interesting if an instance could add them itself - I think doing it dynamically would mess with Webtorrent support?

<comment><USER43> Might work for bigger channels with a stable following. Which is great but they need to start somewhere. I have an old friend who owns a history channel on yt. History Hustle. His vids are quite good but he's no pro just kinda doing it on the side. He doesn't have any real kind of sponsorship aside of his one patreon and yt. I think a lot of guys started out this way too. But I remember how other friend bragging when he got like a few euro through it. I think that inspired it. I don't know how that kind of thing would work without the yt model.</comment></comment></comment>


Net Neutrality Quashing Will Mean New Pricing, Throttling, and Business Models - <AUTHOR> http://www.technologyreview.com/news/523606/net-neutrality-quashed-new-pricing-schemes-throttling-and-business-models-to-follow/ <comment><USER2> The now court-confirmed method to enforce net neutrality is to re-visit the FCC ruling that internet network providers will not be treated as a regulated common carrier utility.

A simple decision. Politically, the present administration is not likely to act to do this.</comment>


Apple Trying to Negotiate Unlimited iTunes Music Downloads  - <AUTHOR> http://mashable.com/2011/03/04/apple-unlimited-itunes-music-downloads/ <comment><USER2> Worst use of the word "unlimited" I've seen recently.</comment>