The tech startup that eventually creates that will call this "efficiency". This type of 'solution' is exactly what capitalism creates.

> I would love to have a real-time dashboard/HUD with measures of disorganized speech patterns or affective intensity

> It would be hard to make it not distracting

Not only would it be distracting, it could also bias you in unexpected ways.

> I would love to have a real-time dashboard/HUD with measures of disorganized speech patterns or affective intensity,

I already don't trust a lot of the mental health industry because of the very bad experiences[1] I've had in the past. The easiest/fastest way to guarantee I never visit a psychiatrist again is to start using that kind of "AI" tech without first showing me the source code. "Magic" hidden algorithms are already a problem in other medical situations like pacemakers[2] and CPAP[3] devices.

> make up for the trade-off of not being in the room

Maybe what you need isn't some sort of "AI" or other tech buzzword. It sounds like you need better communication technology that doesn't lose as much information.

--

On the more general topic of "AI in psychiatry", I strongly encourage you to play the visual novel Eliza[4] by Zachtronics. It's about your fear of a cheap, high error rate system with an additional twist: the same system also optimizes your role into a "gig economy" job.

[1] a brief description of one of those experiences: https://news.ycombinator.com/item?id=26035775

[2] https://www.youtube.com/watch?v=k2FNqXhr4c8

[3] https://www.vice.com/en/article/xwjd4w/im-possibly-alive-bec...

[4] https://www.zachtronics.com/eliza/

The major advantage of a language that isn't Turing complete is not having the major risk inherent to Turing complete languages: asking if any non-trivial program will produce any given result or behavior is undecidable[1].

> write a program that runs until the heat death of the universe even in a Turing-incomplete language.

The Halting Problem is just a simple example of program behavior. The undecidability extends to any other behavior. Asking if a given program will behave maliciously is still undecidable even if we only consider the set of programs that do halt in a reasonable amount of time.

When you are using a regular language or deterministic pushdown automata, questions about the behavior or even asking if two implementations are equivalent is decidable. It is at lest possible8 to create software/tools to help answer the question "is this input safe." When you use a non-deterministic pushdown automata or stronger, you problem becomes provably undecidable*,

I highly recommend the talk "The Science of Insecurity"[2].

[1] https://en.wikipedia.org/wiki/Rice%27s_theorem

[2] video: https://archive.org/details/The_Science_of_Insecurity_ slides: [pdf] https://langsec.org/insecurity-theory-28c3.pdf

    It's a motherfucker
    don't you know

    If they push that button
    Your ass got to go

    What you gonna do
    Without your ass

I would like to suggest that the problem is that the skilled people that understand how to write crypto systems are providing libraries that are easy to misuse. Instead of providing a library that is likely to be used incorrectly without a lot of specialized knowledge, provide infrastructure that manages the crypto so the average developer doesn't need to become an expert on crypto systems.

HTTPS is a useful example. Instead of providing webapp authors a library of cypher/hash functions and warning that they shouldn't roll their own transport layer security and then acting shocked when those authors try to use that library and make a lot of mistakes, we instead separate the crypto step into a separate layer of infrastructure so the average webapp author can easily use crypto without having to learn a lot of specialized knowledge. Someone writing a Ruby on Rails app shouldn't have to write functions like pervade_encrypt($data)/pervade_decrypt($data) to move out of the plaintext world of HTTP and utilize encrypted transport. They only need to buy/LetsEncrypt a cert they can install in their webserver. They can even delegate that to their hosting provider.

"If it's possible for a human to hit the wrong button and [cause a catastrophic failure] by accident [or inexperience], then maybe the problem isn't with the human - it's with that button. [...] People make mistakes, and all of our systems need to be designed to be ready for that."

>> Tom Scott, https://www.youtube.com/watch?v=dabnx8VSdkE

[1] https://www.schneier.com/blog/archives/2017/01/class_breaks....

That is only true if-and-only-if we pretend those 13 bits are the only identifying information being sent to Google when requesting a font. The HTTP request is almost certainly being sent to Google wrapped inside an IP protocol packet. For most[1] requests, there are at least 24 additional bits (why 24? see: [3]) of very-identifying data in the IPv4 Source Address field. More fingerprinting can be probably done on other protocol fields, and IPv6 obviously adds an additional 96 bits. Yes, IP addresses are not unique, but ~13 bits is easily sufficient to disambiguate most hosts on a private network behind a typical NAT. Correlating the tuple {IPv4 Src Addr, x-client-data} received on a font request is trivial: it only requires a user to login to any Google webpage that includes a font request.

>> re: your [1]

    A given Chrome installation may be participating in a number
    of different variations (for different features) at the
    same time. These fall into two categories:

       Low entropy variations, which are randomized based
         on a number from 0 to 7999 (13 bits) that's randomly
         generated by each Chrome installation on the first run.

       High entropy variations, which are randomized using
         the usage statistics token for Chrome installations
         that have usage statistics reporting enabled.

[1] Google reports[2] they currently see about a 60%/40% ratio of IPv4/IPv6.

[2] https://www.google.com/intl/en/ipv6/statistics.html

[3] my previous posts on this topic - re: x-client-data https://news.ycombinator.com/item?id=23562285 re: 24-bits-per-IPv4 https://news.ycombinator.com/item?id=15167059

Trying to restrict competitors from making interoperable products is admitting you don't want to participate in a well-running competitive market and instead deserve monopoly power.

[1] https://www.eff.org/deeplinks/2019/10/adversarial-interopera...

[2] including features like interoperability with a competitor's product.

Phrenology is still pseudo=scientific bullshit even when the calipers[1] are replaced with an "AI" black box of software.

> Just need software that punishes employees who aren't happy enough at work, then we'll have a proper nightmare.

"RSA ANIMATE: Smile or Die"[2]

[1] https://images1.bonhams.com/image?src=Images/live/2006-06/16...

[2] https://www.youtube.com/watch?v=u5um8QWWRvo

Whenever I hear about "smart" devices as a replacement for something that is safety/security critical (like a lock), the question of what happens when the internet and/or power fails is rarely even considered. Does the lock fail open or closed? Does the door open if there is a fire in the building that damages the internet/power wiring? If it fails open, does that mean someone can bypass the lock by simply cutting the network/power cables outside the building?

There might be reasonable answers to these questions at a large business building that can afford fallback options, but I'm not sure there are good answers for e.g. residential situations.

    Paula: "...what's that?"
    Blank Reg: "It's a book!"
    Paula: "Well, what's that?"
    Blank Reg: "It's a non-volatile storage medium.
                It's very rare. You should have one."

The technical benefits are nice, but this type of ergonomic feature is why ruby has remained my favorite language for over a decade.

The traditional way a big tech company becomes the dominant provider is to embrace an open interoperable protocol to minimize the friction of switching from another provider. Later, when they have captured enough of the market, they extend the protocol to gradually reduce the de facto interoperability with other providers to increase the friction of switching to any other provider.

https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...

What if instead of "fire fast", the idea was re-framed/restructured into the new employee initially working as some sort of consultant with a short term contract? Use telecommuting/work-from-home or other temporary workarounds to defer expensive/disruptive things like moving to live near the company until after the defined "trial" period. Instead of "firing fast", you either let the temporary consulting contract expire or you proceed with the actual hiring process and the deferred tasks.

Maybe this isn't possible in practice, but it seems like we could design a workaround to this problem if were sufficiently creative.

> think about the effects it has on others

Unfortunately, that takes proactive effort. Unless there is a mechanism to actively incentivize spending time and energy to protect others, most of the time that effort will be spent on "more important" things. ~sigh~

"The Six Dumbest Ideas in Computer Security"

> #1) Default Permit

> #2) Enumerating Badness

  In the beginning, there was a plan, 
  And then came the assumptions,
  And the assumptions were without form, 
  And the plan without substance,

  And the darkness was upon the face of the workers,
  And they spoke among themselves saying,
  "It is a crock of shit and it stinks."

  And the workers went unto their Supervisors and said,
  "It is a pile of dung, and we cannot live with the smell."

  And the Supervisors went unto their Managers saying,
  "It is a container of excrement, and it is very strong, 
  Such that none may abide by it."

  And the Managers went unto their Directors saying,
  "It is a vessel of fertilizer, and none may abide by its strength."

  And the Directors spoke among themselves saying to one another,
  "It contains that which aids plants growth, and it is very strong."

  And the Directors went to the Vice Presidents saying unto them,
  "It promotes growth, and it is very powerful."

  And the Vice Presidents went to the President, saying unto him,
  "This new plan will actively promote the growth and vigor 
  Of the company With very powerful effects."

  And the President looked upon the Plan 
  And saw that it was good,
  And the Plan became Policy.

  And this, my friend, is how shit happens.

The best explanation I've seen - and possibly the most important video on youtube - is "This Is Phil Fish"[1] by Innuendo Studios. It's not really about Phil Fish; it's about everyone who isn't Phil Fish acted when they decided he became "famous". In the past, being "on tv" or "in a band" or other traditional examples of fame required some amount of buying into fame. Becoming famous required media access that was controlled by gatekeepers. You had to work with those gatekeepers if you wanted to be "on tv" or whatever, and because you had to choose to participate, people often see the decision to become famous as also accepting some amount of responsibility to "act like famous people are supposed to act".

This internet fundamentally changed the mechanics of fame, because the internet IS media access. Now it is possible to become famous - to become a "celebrity" with a "responsibility" to act in a certain way - simply by being yourself in your normal everyday life.

[1] https://www.youtube.com/watch?v=PmTUW-owa2w

Comments URL: https://news.ycombinator.com/item?id=30099077

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=29894987

Points: 1

# Comments: 0

    local tmpFile="${TMPDIR:-/tmp/bash-web-server.$$}"

    # ...

    rm "$tmpFile"

    local tmpfile="$(mktemp --tmpdir="${TMPDIR:-/tmp}" bash-web-server.XXXXXX)"
    trap "rm -f \"${tmpfile}\"" RETURN EXIT

    # ...

    # Do nothing at the end of the function; trap will
    # remove the file at RETURN automatically.