otini

Also tracking the viewing history of an IP is not that easy. People trying to do this can be easily spotted by the trackers.

The uploader will be banned and their content removed, and hopefully will have to deal with the police. If a PeerTube instance is too laxist about its moderation policy, other instances will stop federating (federation is opt-in and decided by the admins).

Sure, or Tor. Anything that hides your IP.

We could discuss the possible workarounds for this, but let's not forget that in terms of privacy, Youtube has its own by-design flaws as well. The company gathers much precise data about viewers than Peertube does.

There is no notion of moderation in ActivityPub itself AFAIK, but I suppose you're asking what happens to e.g. comments that have been sent to federated servers/software and then deleted on the original platform.

In general, when that happens the comment is removed on the host platform, then a deletion request is sent to the federated platforms. There is no guarantee that other platforms will delete the content (although if they don't, they are generally considered malicious and should be reported), much like deleted forum posts can be viewed through WebArchive.

Only if you want to be in control of your videos and don't want to use your audience's personal data as a payment to Youtube.

You can also host them on a PeerTube instance run by someone you trust (several non-profits already maintain one).

Peertube has other advantages, among which interoperability. A relevant quote from the main developer:

“Where it gets really, really exciting, is that when you respond to a video status on Mastodon, the message will be sent to the instance of PeerTube. Your response will thus be visible beneath the video, in the comment space. And yes, if another person at the other end of the world responds to your comment via their instance of PeerTube or Mastodon, you’ll see it as a response to your status in Mastodon. If tomorrow Diaspora (the Facebook alternative behind Framasphere) implements ActivityPub, it will work in the same way. We’ll have plenty of platforms that are capable of federating comments.

Free alternatives are criticized, often rightly, for not having added value compared to centralized platforms. With ActivityPub, we now have our first big advantage. Because on the centralized platforms, you’ll have a hard time viewing, under your YouTube video, the reactions of people who commented on Facebook, Twitter, etc. ”

source: https://medium.com/@chocobozzz/peertube-a-federated-video-st...

PeerTube initially aims precisely at being a Youtube alternative, which is why such questions are not tackled in the article I guess. However federation with other servers is totally controlled by admin-defined rules, so you can make a “private” instance. I'm not sure whether making videos watchable by logged-in users only is already possible but it's a very easy thing to implement.

As for the torrenting, if videos are only available to members it shouldn't be a privacy problem. That being said, disabling it will probably be a possibility in v1.0.

> The current top-down, militaristic control structure of most companies is more a result of path dependence than any fundamental requirement.

I strongly disagree. In a corporation, the relation of the employee to the employer is intrinsically one of subordination. It is defined as such in the labour laws of most countries.

Of course, this subordination is not necessary militaristic — but it can be, and naturally tends to be in a context of financial pressure on the company.

The point I want to make is that an employment relation is not symmetric (although it may be experienced as such by those of middle- or upper-class position) but happens on a background of economic depencency, and that is more and more true as the job is less paid and less considered.

Oh I see what you mean. For now, we have made the choice to compile static code to OCaml bytecode, whatever the compilation target is. While this enables the use of macros regardless of the target (e.g. it works in `ocamlopt`, the native compiler), it does make it necessary to compile a module to bytecode if you want to lift it. It's not a big deal with an adapted build system, but a distant future we might support native compilation of macros on some architectures.

> That's clearly a faulty assumption. If production depends on a job and supply is short, then the value and pay will rise until supply meets demand.

I don't disagree with your statement about supply and demand. But as a matter of fact, the supply is never short, because structures of society force a large fraction of the population into jobs they cannot let go, whether they like it or not.

It is common knowledge that people of low social status are given a choice between shitty jobs and starvation. Saying "if the job is not good enough, supply will fall and wages will have to rise" does not take into account the highly competitive character of the job market, especially for those with low educational capital.

I think Varoufakis is profoundly misled in thinking that basic income can be a left-wing policy.

It is a well-known fact that there are two versions of basic income out there: the right-wing version, where welfare is removed and replaced with a single allocation that isn't high enough to live of it; and a left-wing version, where the distributed amount is sufficient to live a decent life and thus gives "real freedom" to people.

Here is why I think the left-wing version is a fantasy: I start from the assumption that capitalistic economies like ours mainly relies on coercion. In other words, critical parts of production depend on people who would rather do something else, if it wasn't their only way to eat. Under that assumption, any policy that gives people a real choice between being employed in a factory and doing the things they really want to do removes in fact the coercion — making the economy collapse.

The form collapsing would take could for example be the following: low-paid, exhausting and low-considered jobs are not taken anymore, and yet society depends on them. The only way to make the workers come back is to pay them much better. But this can only lead to a combination of dramatic price rises and cuts in shareholder profit (and I am not an advocate of capital income, but sadly it is currently one of the main incentives for investment).

For these reasons, I am convinced that any attempt to implement a left-wing basic income will inevitably result in the right-wing version taking over, meaning less rights for the workers and a destroyed welfare.

The second message is arguably clearer, but I don't think anyone would be really hindered by the first one, especially given that, unlike in C, application of printf have an explicit type:

    # Printf.sprintf "some int: %d another int: %d";;
    - : int -> int -> string = <fun>

I think a general tendency in statically typed languages is that we like to write stuff using only the type system, rather than adding code to the compiler. Same for macros: we will rather have them proved correct by the typechecker than make them raise errors (also it is possible, through exceptions).

But maybe this is detrimental to clarity of errors in some cases. I'd be interested to see how Racket handles errors.

Firstly, if your macro does not typecheck, it means that executing it might result in a segfault or something similar, since macros are regular OCaml functions. Secondly, if macro typechecks, then it is guaranteed to expand without errors, and I think that's a nice guarantee to have.

The strymonas optimal performance is guaranteed for any combination of stream processors. That doesn't seem to be the case of this library which relies on frequent patterns.

I would say that the latter is non-optimal, i.e. generates some unnecessary intermediary values whereas the former is optimal as shown in the paper.

Since macros aren't just a plugin but are directly baked in the compiler code, error messages can be anything we want… what are you suggesting?

Well what macros only ever do is generate OCaml ASTs, so the should work whatever the compilation target is.

There are certainly some design choices here. I want to emphasize that in the few projects where I've used macros (e.g. https://github.com/OlivierNicole/macros-examples), I found that these translating functions were scarcely needed and I never had to pass a non-standard type between phases.

You may want to read this comment which I find relevant: https://www.reddit.com/r/ocaml/comments/5e8slg/bringing_type...

This sounds very handy and I definitely need to learn more about LMS and Compiler Plugins. I wonder then what are the limitations on the values you can pass automatically across phases, since there must be (you cannot transfer e.g. a file handle from compile-time to run-time).