dvdkhlng

They are are using a 53-bit hash cyrb53 [1] of the string "IP address + website domain + user agent + language + validity days". It looks feasible that many of the generated IDs could be retroactively brute-force mapped back to an IPv4 address with high confidence (small chance of error due to hash collisions).

[1] https://stackoverflow.com/questions/7616461/generate-a-hash-...

I think the idea is that you use registers and apply the NOR gate multiple times. In this sense the NOR gate is universal, while an OR gate nor a XOR gate are neither universal.

I.e.

  XOR(x,y) = NOR(0, NOR(NOR(x,y), NOR(NOR(x,0),NOR(y,0)))))

(maybe not the most minimal version and maybe even wrong)

> He probably saw benefits from using UDP because he's no longer limited by TCP's congestion control and can flood the pipe with duplicates of his packets.

But he wrote that he'd used "TCP over UDP". The first lines of the TCP over UDP spec already state

"It provides exactly the same congestion control, flow control, reliability, and extension mechanisms as offered by TCP." [1]

[1] https://tools.ietf.org/id/draft-baset-tsvwg-tcp-over-udp-01....

Yes, I had the same confusion. There seems to be a standard for TCP over UDP [1]. But in general, I would assume that it does not help at all WRT any of the packet loss/latency problems posed by satellite links.

TCP is designed for encapsulation in IP, this is why it is called TCP/IP. And UDP is very similar to IP, only difference is that UDP gives you source and destination port numbers and a payload checksum, where IP only gives you a protocol numbers and non-checksummed data. None of these "features" is going to have any effect on how TCP is delivered.

So the only effect that use of TCP over UDP would have here is:

- increase the overhead used for headers, thereby decreasing the MSS (segment size)

- "cloak" the TCP traffic as UDP and thereby prevent any routers and/or middleboxes [2] from applying special treatment to TCP (i.e. traffic shaping, buffering etc.)

Maybe the latter effect is what made a difference for the link in question.

[1] https://tools.ietf.org/id/draft-baset-tsvwg-tcp-over-udp-01....

[2] https://en.wikipedia.org/wiki/Middlebox

edit: formatting

The problem with that is that agricultural output in a 3 degree higher world may not be sufficient to sustain a civilization of almost 8 billion people. "Life always finds a way" may be a little sarcastic once people start starving.

Disclaimer: I'm not knowledgeable in that topic. But from a general physics PoV:

- weather is mostly about complex local interactions between air pressure / surface temperature / air flow (convection) / humidity etc. these are described by differential equations with very chaotic behaviour (small changes in inputs may have extreme effects on the outputs the further you run the model)

- climate is more about long-time effects of the energy input/output of the whole planetary surface and atmosphere. Mostly solar radiation (input) vs. black-body radiation (output). There are also some complex interactions and feedback cycles e.g. change of albedo (cloud cover), and changes of atmospheric composition (i.e. methane due to permafrost melting), but local weather patterns may cancel out when looking at the sum-total of surface thermal energy.

I'm running Firefox, installed from upstream, running on Devuan Beowulf. With the default "Courier New,Fixed" font family set it's just not working.

In Firefox (v82) the text-field does not seem to render in a strictly non-proportional font. Thus everything is garbled. Unfortunately w3m text-mode browser isn't capable to display the page...

[EDIT] The following steps fix playback in Firefox for me:

- I press F12 to open the web-developer tools,

- select the "Console" Tab

- at the prompt at the bottom (marked by ">>") enter:

  document.querySelector("pre#screen").setAttribute("style", "font-family:Monospace;")

- press Return. Renders correctly now.

You can very likely compress the table and/or interpolate between entries. It's not like that those entries are totally random.

Using Tcl exceptions, I guess it would be pretty trivial to do that.

Here [1] is an alternative do..while loop implementation provided by Tcllib, written in pure Tcl.

[1] https://core.tcl-lang.org/tcllib/artifact/4f7e97706ff67a40

Well, you don't need 'expr' in contexts were an expression is expected, e.g. 'if' 'while', 'for' (2nd arg).

I have the exact opposite experience WRT Tcl channels when compared to other languages.

Handling binary data is pretty trivial, e.g. to read a full binary file into a binary string, you do:

  set h [open "filename.bin" r]
  fconfigure $h -encoding binary -translation binary
  set data [read $h]

Then you even have a fantastic way to operate on low-level binary data of any endianness using Tcl's binary scan /binary format instructions [1] (basically what Javascript later invented as DataView).

Tcl was one of the first languages I knew that properly and consistently supported multibyte text throughout the full language, including in Tk GUIs. I.e. writing a cross-platform GUI that could handle Japanese character input/output basically "just worked". You could even read ShiftJIS or ISO encodings of japanese text, which was at the time a prerequisite as Japanese Windows versions were non-unicode (everything done in ShiftJIS AFAIR).

[edit] here is a real-world example of a trivial script handling binary data [2]: reading binary RGBA 4 bytes/pixel image data and outputting RGB 3b/pixel into a pipe that finally outputs a .PNG image. It's difficult to find a programming language that can do that in less lines and with more clarity.

[1] https://wiki.tcl-lang.org/page/binary+scan

[2] https://stech.muecke.pw/opensvn/free/trunk/dkbin/nn-fbtopng

"Harm" is difficult to assess in some cases. What about the bunch of school children who faced a higher than normal probability of traffic accident because somebody illegally parked near a pedestrian crossing? You can't really claim losses against somebody who endangered your life, before anybody is hurt. Maybe that's what fines are for...

I think the GPLv3 implements a similar idea WRT patent rights, sometimes referred to as "patent retaliation clause" [1].

Just saying that there is precedent for licenses being used to protect against overreaching "IP" laws.

[1] https://www.gnu.org/licenses/gpl-faq.html#v3PatentRetaliatio...

Good question. I'd pick one of:

(a) Smart pointers + static analysis + sanitizers make C++ pretty usable

(b) C++ usability requires brittle, half-baked add-ons such as smart pointers and non-deterministic/heuristic/unreliable/NP-hard development tools such as static analysis + sanitizers.

Uh, you're too optimistic:

Everybody and their uncle had a lot of ideas about how they would fix "C++". Eventually all those contradicting ideas got merged into the C++ standard.

:)

I think for shared_from_this() I have a different use-case in mind: an object of some class wants to register with some other class. I.e. think about something like

  auto self = shared_from_this();
  document.onclick([self](){self->doit(); } );

I'm not sure there is a way to express that in C++ without use of enable_shared_from_this.

It is very easy to accidentally run this kind of code from a constructor where shared_from_this() is a 0-ptr.

make_shared also only helps in 95% of cases. E.g. it does not allow specifying a custom deleter, which is a use-case that is allowed by the shared_ptr<> constructor. It also won't fix any of the problems WRT shared_from_this() being called in the constructor.

When I think about C++ "smart" pointers, I often think about easy to provoke / difficult to spot fatal edge cases. E.g.

- C++ code where some method calls std::shared_from_this(), and that method ends up being called indirectly during the object's construction, leading to a 0-pointer dereference [1]

- accidentally creating two shared-pointers to the same object leading to an eventual double-free (that may just silently corrupt the heap while the program continues running)

- undetectable cyclic shared_ptr<> references somewhere deeply hidden in the code causing a memory leak

Modern C++ feels like a case of "but we can do that in C++, too" syndrome. Stuff that "just works" in Java or Lisp, can now be done in C++, too, however in C++ it will only work for 95% of all use cases, and break in a spectacular manner for the remaining 5%.

E.g. think about the template meta-programming madness (and efficiency WRT compile-time) and compare that with what Lisp offers (see also [2]).

[1] https://stackoverflow.com/questions/31924396/why-shared-from... standpoint

[2] http://people.cs.uchicago.edu/~jacobm/pubs/templates.html

I can second that, I have seen people frustrated after loosing work in Snap! by missing to save. But then that's maybe also a lesson people ought to learn early-on when creating stuff on the computer: safe early and create backups :)

I'd suggest TIC-80 [1] as an intermediate step from Snap! to larger IDEs. TIC-80 documentation [2] is a little thin, but overall it's a very pragmatic integrated development environment that combines sound, sprite, map and code-editor into one very simple IDE environment (no debugger, though, only rudimentary logging).

You have a choice between multiple script languages (Lua, Javascript and more). The run-time library [3] only has a handful of simple functions but is feature-complete nonetheless (plus there is some address-based peek/poke API to do more advanced, low-level stuff).

I'd imagine learning javascript programming by starting game-development in TIC-80 to be much more straight-forward than attempting to wrestle with the complexities of HTML5+CSS+javascript+tooling for in-browser programming.

[1] https://tic80.com/

[2] https://github.com/nesbox/TIC-80/wiki

[3] https://github.com/nesbox/TIC-80/wiki#special-functions

From my experience, as a cyclist speed and acceleration helps with avoiding car-related danger. If you're fast enough, cars won't needlessly overtake you (in rush hour, most car traffic may not exeed 30 km/h for example due to roads being packed too full, that's easy to match for a trained cyclist).

Also at intersections, being really quick at acceleration allows you to get out of the danger zone of cars crossing your path before there's a conflict. Think about right-turning trucks starting after a red traffic light.

I think fitness (and maybe reaction time) is some reason why severe cycling accidents seem to happen to older cyclist at a higher rate. In Berlin out of 15 cycling deaths this year, more than half of them are age 60 and higher [1], 3 are beyond 80 years of age.

[1] https://adfc-berlin.de/radverkehr/sicherheit/information-und...

> Should the bike lanes be removed, then?

Yeah, for Berlin at least it's a very difficult question trying to find out how to move forward from the current half-assed state of affairs.

There is some sort of new law/policy that defines how proper bike infrastructure should look like [1] defining minimum width and stating that bike-lines should not be put onto foot-walks. However not many actions where performed based on that law which was also drafted in a way that prevents bringing forward proper legal action when not adhered to.

Maybe also something needs to be done WRT driving school, where bike-related issues are not really taught as far as I'm aware of. Most drivers (and maybe most teachers at driving school) still believe that cyclists do not belong onto the road and do not understand how driver behaviour endangers them. Minimum car<->bike overtaking distance (1.5 m) for example is generally ignored by more than half of cars.

[1] https://de.wikipedia.org/wiki/Berliner_Mobilit%C3%A4tsgesetz

In case people don't get the "white spray painted biycles" reference, see [1].

Berlin just got 15 more of those bikes this year already (which is more than usual, maybe due to corona).

[1] https://en.wikipedia.org/wiki/Ghost_bike

The problem with this is that car drivers usually just assume that the cyclists could just safely use the bike lane, while in reality many bike-lanes are statistically more dangerous than just driving on the road.

In Germany there used to be a a general obligation to use bike-lanes when present, which was overturned by court, because of the safety argument.

As a cyclist I'm harassed at least once a weak by drivers who think I should use the non-obligatory bike-lane. This makes it very difficult to consciously chose the safer road instead of the (too narrow, too badly lit, too close to foot-traffic, too damaged, full of glass shards) bike-lane.

> One that they didn't mention was our artifacts on the moon which will last 100 million years or so. Geostationary and HEO satellites will stay for a while but I'm not exactly sure how long.

Erosion due to micrometeorites erodes the surface of the moon at 1mm per 1e6 years [1]. I wonder whether erosion of human-made moon artifacts will commence at a comparable rate.

Note that the hull thickness of the apollo lander is just 0.3 mm [2]. Part of the propulsion system, tanks etc. would be the components to last longest, butt 100 million years may be quite a stretch.

[1] https://mauricejscollins.wixsite.com/moonscience

[2] https://space.stackexchange.com/questions/924/what-would-hav...

> On top of that, climate change is a slow moving disaster, and we are typically good at mitigating long term changes (at least way better than urgent crises). Scientists calling for the end of the world at every opportunity will look ridiculous 100 years from now.

I wish I could share your optimism. Climate change may be a slow moving disaster, however it is more a "high latency" moving disaster. In the sense that once the symptoms start hurting us, it will not be possible to administer any control inputs that will effect the course of climate change within an acceptable period of time.

And while we may be good at mitigating long term changes, I think "existential crisis" kind of long term changes may not have any modes of mitigation that would be acceptable to the current generation of humans (like accepting that 90% of world population just won't have a chance of long-term surivival).

>> according to every serious scientist we are pretty much on the worst case scenario path according to any peer reviewed model.

> Obviously not true.

I think GP was referring to predictions of climate sensibility to changes in CO2 concentration appearing to track the predicted worst-case [1]. He was not referring to the predictions of CO2 concentration per se.

And the predictions about CO2 rise you refer to are not very comforting anyway. If the 2 degree line is crossed, as predicted by these data, then a cascade of tipping points [2] will likely put the earth into a permanently "hot" climate state.

[1] https://www.theguardian.com/environment/2020/jun/13/climate-...

[2] https://en.wikipedia.org/wiki/Tipping_points_in_the_climate_...

If we disrupt the balance, after some time we will reach a different equilibrium state. It currently looks like we are going to cause a cascade of tipping points which will result in the earth reaching a new stable equalibrium called "Hothouse Earth" some 4-5 degree celsius above pre-industrial levels [1].

In such a climate, earth would possibly not be able to sustain a large multi-billion human population.

[1] https://phys.org/news/2018-08-earth-hothouse-state.html

Just to counter some of your claims with publicly available sources:

- We do control clouds and cloud cover albedo [1].

- Human-induced changes to composition of earth's athmosphere result in about 3 Watts of additional heating per square meter of earth's surface [2]. That's almost 1% of the normal solar heating, or > 2K of (eventual) equalibrium temperature increase, so maybe we should call that "climate control" after all?

[1] https://www.faa.gov/about/office_org/headquarters_offices/ap...

[2] https://en.wikipedia.org/wiki/Radiative_forcing

You mean that IPCC predictions based on climate models have been replaced by different predictions based on newer models as more data became available over time?

Unfortunately (for us) it does look like newer predictions predict worse outcomes with higher confidence [1].

PS: yes scientific consensus changes over time as a function of available measurement data and understanding. That's not a sign of failure but of improved scientific insight.

[1] https://www.counterpunch.org/2020/03/18/the-ipccs-worst-case...