I'd like to say leave speed reporting to the Twittersphere and mandate a clear label on unvetted news reports on any network, but I doubt politics can have such influence on the media. I would love it if the news reports had a watermark that says fresh-and-unvetted just like "preliminary results" or "consult your doctor before taking".

First we have to encourage and support critical thinking, but too much of it may lead to some influencers misusing it to support causes which deny past and current crimes of humanity on itself and the planet.

So they can't even say "it's likely to rain tomorrow"? This doesn't seem thought through.

That said, our weather models are pretty good but not good enough to make certain predictions that far away into the future, but they can for the next few hours.

It's like a software company's model of code branches. The Apple/Google/whatever filesystem team works on something, it gets pushed into their level of production branch, then it percolates up to the shared production kernel branch, and after a couple more layers it hits the common branch, which is what public production binaries are made from and consists of kernel, userland, foobar modules all merged together. Not all software shops operate this way, but it's what size of a project can demand after it hits certain amount. The linux kernel works this way too, to name a successful non-commercial project. You can argue this doesn't prevent regressions, and that's true, but it's hard to deny there would be more regressions (aka false reporting) with unfiltered (aka unvetted) reporting.

I still don't believe the term "100% certain" is meaningful. Maybe if they were to put a label on certain facts: "This fact is considered by our editorial board to be 93% certain." And maybe have a chart, so that figure can change over time.

I think there are better ways, and that there should be accountability. I just am not in favor of black and white terms for concepts that, to me, are purely shades of gray.

But I must say that st's font rendering of Unicode is more complete than rxvt-unicode or xterm. With the same font configured in all three, st is the one that manages to render the most glyphs of plan9port's unicode sample file. Would be great to have the same in urxvt or xterm.

It's worded weird, but I assumed the "compute board" is the PI.

The OS is put together by Canonical, until now it was based on Ubuntu 16.04 and they'll soon update it to Snappy Ubuntu Core so you get a fully 0-maintenance solution.

I don't have such a source file handy to reproduce, but if you try enough ISO MP4 containers with H246, you will hit one where this is the case.

Is `-t` different from `-to` which I've been using?

Any idea what the exact warning text is?

Opera Unite was an isolated platform with prebuilt apps by Opera and custom apps you could download from an app store. FlyWeb is an API exposed to any web page.

Opera Unite gave you a public URL that was an Opera server reverse proxying to your local machine so you could share files, chat, etc. with your friends online. FlyWeb just publishes multicast DNS (Bonjour/Avahi/Zeroconf/etc.) service discovery records to your local network.

http://help.opera.com/Windows/12.10/en/unite.html

When will Rust get

1. function head patterns like other languages in the ML family, although Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation

2. support for naturally writing recursive functions

It's actually more of a sibling in the family who ran away from home at the age of 6 and fell in with the crowd on the wrong side of the tracks.

Initially Rust was very much like ocaml. It isn't anymore :) Many of the normally-in-functional-languages features in Rust come from these days. Others were lost and re-added later. It's a very complex history.

> function head patterns like other languages in the ML family

could you elaborate? I'm not familiar with this feature (only have dabbled in sml).

> support for naturally writing recursive functions

yeah, I wish we had TCO.

> Initially Rust was very much like ocaml. It isn't anymore :) Many of the normally-in-functional-languages features in Rust come from these days. Others were lost and re-added later. It's a very complex history.

Yeah, having tried Rust in those days, I kinda stopped when it broke every week, and was then surprised with the surface of 1.0. It seemed like a different person to talk to.

I've made my peace with the C'ification of Rust as the price to pay for attracting a large crowd of developers who grew up with C, C++, C#, Java, JavaScript, Ruby, Python, the list goes on. It's a reasonable sacrifice to make, but the two mentioned basic features aren't complex things to wish for.

> could you elaborate? I'm not familiar with this feature (only have dabbled in sml).

Imagine being able to hoist your match clauses into function head (signature?).

  oldEnoughToDrink :: Int -> Boolean
  oldEnoughToDrink 21 -> True
  oldEnoughToDrink _  -> False

  OldEnough = fun(21) -> true;
                 (_)  -> false
              end,

I don't think Rust will get support for that. You can simulate it with macros (and, later, syntax extensions). Of course, that isn't as clean as pure language support. I know why it makes recursion (esp tail recursion) easier to use though. You could always bring it up on the forums and try though.

Say you have a function that should will tell you a file extension is likely to be that of a text file:

  isTxt("txt") -> true;
  isTxt("org") -> true;
  isTxt(_)     -> false.

If Rust is planned to get HKT, then I don't see why I cannot get pattern matching in function heads when there's also guards as found in ML languages.

Oh, I know that it's useful; I've used it in Haskell often. And the `fn foo (x) { match x {}}` pattern isn't uncommon in Rust.

> If Rust is planned to get HKT then I don't see why I cannot get pattern matching in function heads when there's also guards as found in ML languages.

The HKT proposal logically extends existing associated types syntax so that you effectively have HKT. It's particularly elegant in that it's something folks (who are unaware of what HKT is) on learning about associated types expect associated types to support. I've had folks ask countless times as to why you can't `type Foo<T>` in an associated type.

It also opens up access to patterns that weren't possible in the past.

OTOH function heads would just be sugar for fn + match. It doesn't open up new possibilities, it just makes some patterns easier to type. And frankly, with blocks being expressions, it's not much easier to type. You have to provide the function signature somehow, and it's there. The match arms are also there in both the Rust and haskell versions. The only thing exclusive to the Rust version is that you need to explicitly say `match`. Meh.

Languages have a "complexity budget" -- spend too much of it and folks won't learn your language because it's too complex. Rust has spent a lot of it on the borrow checker. Adding random bits of syntax spends this budget, and you need a compelling reason to do so. This is why I'm quite fond of the current HKT proposal -- I'd always thought HKT in Rust was pie-in-the-sky, but the current proposal ends up with a very unsurprising and natural-looking syntax (and doesn't feel "new"), which makes me think that it has a good chance of succeeding.

If you can come up with a good proposal for function heads, who knows, it might happen! But it will have to be good; I don't think just proposing function heads without tons of justification and/or a syntax that fits in naturally will work.

Regarding semantics, without having thought about the Rust semantics too much, I'd suggest to check out the most prominent uses for recursive functions in OCaml, SML or Haskell, then try to consider that as the sweet spot to support in Rust.

That said, if the content of season 3 manages to push some of the concerns outlined into the general public's perception and highlights them, then it's a good thing and well achieved.

The thing that stuck and was funniest for me was from the worst episode (ep 1) about the adapter and planned obsolescence.

Since San Junipero is mentioned here positively, I should add that it didn't work for me and seemed like ep 1 just too long for the content, but that's a subjective thing I guess. I kinda found it uninteresting and boring and honestly the ideas brought forward not crazy or exciting. Maybe it's because having lived in the tech world, the concepts are just as old as the availability electricity or even anyone who watched the matrix or read the mangas it's based on would find it "old".

Playtest reminded of the No End House creepypasta.

My favorite episode, despite the plot flaws, was Hated in the Nation, and that one almost saved the season. In light of InternetOf*, it was the episode I enjoyed the most.

Has this been proven yet? I'm under the impression that we're still in the stages of better not believing any side of the arguments because any secrets - if they exist - will be fresh and well hidden for the moment. If you ask me, I would be very careful claiming to know who orchestrated what.