You did not answer my question, but I guess it does not matter with the new strategy. Looks like embrace-extend-extinguish to me – has it always been a goal of Keybase to replace PGP with something keybase-specific or did something change?
534 karma · joined June 1, 2016
One of its tasks is to ensure non-discriminatory access to infrastructure markets for all market participants: Former state monopolies have to share their infrastructure at a reasonable price to competitors, for example. Another task is consumer protection: In february 2017 they decided that an internet-enabled child's doll containing a microphone accessible remotely without any indication to the people using that doll should be “verboten” since they classified it as a hidden wiretapping device.
The federal network agency claims that XMPP clients have to be registered according to a German law that says that one has to be registered with (but does not need permission from) the agency if providing public communication services commercially.
https://en.wikipedia.org/wiki/Federal_Network_Agency
Edit: As other hackernews have pointed out, only the telecommunications stuff is supervised by the BMVI.
Internet Relay Chat: Client Protocol https://tools.ietf.org/html/rfc2812
Internet Relay Chat: Server Protocol https://tools.ietf.org/html/rfc2813
By contrast, redo builds the target first and then records what was used to build it. For example, when compiling a C file with “gcc -M”, gcc will output dependency information. With redo, you normally record those dependencies after the target has been built. With make(1), that information has to end up in the makefile somehow, possibly leading to further builds.
How would you solve all three problems I listed using make(1)?
• make(1) has a hard time rebuilding target files when source files have changed. The problem is that users have to declare the dependencies of a target before the build, but due to file search paths, it can be that dependencies are only known after building a target. To know about all dependencies, make(1) would have to build any target at least twice.
• make(1) by default does not rebuild a target when its build rules change. While this seems really weird to me, it seems to be a consequence of having a single makefile. When a build rule is changed, the makefile changes. So should all targets depend on the makefile implicitly? One could argue that they should – but then each change in a makefile would rebuild all targets.
• make(1) can not handle non-existence dependencies. Imagine a file foo.h being searched for by a compiler in directories bar and baz (in that order). If the header file baz/foo.h is found, then bar/foo.h should be considered a non-existence dependency: If at any future point in time it exists, the target should be rebuilt.
These problems are all solved by DJB's redo approach, which I implemented in a few hundred lines of Bourne shell (/bin/sh): http://news.dieweltistgarnichtso.net/bin/redo-sh.html
For a weekly HN digest, I read this: http://n-gate.com/hackernews/
I propose to blog anonymously about those “interesting ideas” then. That way you can achieve something, but get none of the personal recognition you seem to want to avoid.
> Then, as a general rule, I start drinking if I have no obligations for the evening.
Please stop drinking alcohol regularly, especially when you feel depressed. It may make you feel good for a short while, but drinking alcohol regularly can result in liver failure, mental illness, and an increase in the risk of cancer, among other diseases.
The problem is one of bargaining power: Consent must be given freely – but in cases where one party in an exchange has a lot more bargaining power, the other party often will agree to something because of fear of retribution or a threat of force. Example: If an employee is told by the boss he or she will be fired if they do not have sex right now, any consent in that scenario is not given freely, but under duress.
Are the games you want to stream also proprietary software?
Title: “JPMorgan Software Does in Seconds What Took Lawyers 360,000 Hours”
Smells fishy.
“gst-launch-1.0 v4l2src ! timeoverlay ! xvimagesink” gives you a webcam overlay.
For more info: http://wiki.oz9aec.net/index.php/Gstreamer_cheat_sheet
; cat <<EOF >/tmp/testfile
Diction and style are two old standard Unix commands. Diction identifies wordy and commonly misused phrases. Style analyses surface characteristics of a document, including sentence length and other readability measures.
These programs cannot help you structure a document well, but they can help to avoid poor wording and compare the readability (not the understandability!) of your documents with others. Both commands support English and German documents.
EOF
; LANG=C diction --lang en --suggest /tmp/testfile
/tmp/testfile:2: These programs cannot help you structure a document well, but [they -> (do not use as substitute for "each, each one, everybody, every one, anybody, any one, somebody, some one")] [can -> (do not confuse with "may")] help to avoid poor wording and [compare -> "Compare" to points out resemblances, "compare with" points out differences.] the readability (not the understandability!) of your documents with others.
3 phrases in 5 sentences found.
Depending on them, it might seem or have seemed clever.
I think it is dangerous to confuse “clever” and “evil”.
Did you intend to draw a connection between these two statements?
From your point of view, the problem is something inherent to semantic versioning. From my point of view, the problem is inherent to your behaviour – if you really want to do “several breaking releases one after another”, why hide it from users?
One example deficiency is message ordering. In Slack, messages ordering sometimes changes sometimes after I have received two messages, that are then ordered differently. Is this an example of “eventual consistency” in the wild?
Another deficiency of Slack that definitely is more “inspired” by IRC than anything else is the reconnection handling. If you ever have used IRC, Slack and XMPP on a train (or any other spotty connection), you may have noticed that IRC (or Slack) can time out without you noticing immediately, while with XMPP temporary network problems are usually handled automatically by modern clients.
The difference in both cases lies in stream management – if each message has a sequence number (as it has in XMPP with XEP-0198), endpoints can definitely establish a) an ordering and b) what the last message received was. This eliminates any manual replay. Slack does not do this, apparently, even though unexpected network termination happens frequently.
A third defiency of Slack that makes it look like IRC is the notable absense of metadata fields. While in XMPP you can have a vCard, the Slack documentation contains this gem, indicating Slack developers themselves abuse the last name field to convey information such as not being in the office:
> We ask that everyone displays first and last names in Slack, so we can use the last name field to alert coworkers when they are out of the office, on extended leave, or sick for the day.
Source: https://slackhq.com/slack-101-onboarding-247454704155#11aa