adamb

Our early decision to use SHA-1 was a balance between limitations of mobile hardware and the security landscape of the day.

Much of Skynet's core technology is actually designed for mobile platforms. Skynet essentially thinks of a desktop computer as a fancy phone with a different UI toolkit and without a cellular modem.

While switching to SHA-2 is on our to-do list, it's not as high as nailing a stellar experience for our users. Should SHA-1 erode more quickly than expected, we'll be sure to bump up the priority of that transition. We'll be sure to pivot the network before it's a real problem.

While we're talking about syntax, "\n" is an alternative to ",".

This helps multi-line expressions read more naturally.

  '{
    foo: 1
    baz: 'bar
    chunky: 'bacon
  }

Our use of ' was inspired by lisp's.

Immutability such is an important part of Spin's messaging model that we wanted a consistent way to declare an immutable construction.

  # An immutable string (or symbol)
  'foo

  # An immutable list
  '[ 1, 'foo, '[] ]

  # An immutable map
  '{ foo: 1, y: 'two, z: '[ 'three ] }

Slightly more advanced...

  # Also an immutable string
  "foo with spaces" 

  # An immutable pair
  "bar" -> 2

  # Syntactic sugar for that same pair
  bar: 2 

  # Syntactic sugar for "baz" -> baz
  ~baz

The distributed programmer in me wants to point out that having applications automatically use the latest version of a library is a scary proposition.

During a distributed operation, participants can arrive at many different points in time. This means that applications using the newly-patched library will likely be interacting with applications using the unpatched library. Whenever multiple versions of anything are interacting with themselves things can get complicated.

In light of this, we opted to keep things simple and predictable for ourselves (and others). Since applications always run against exactly what you say they should, you're free to keep running forward, without having to worry about tripping over past decisions.

Without making any promises, it's hard to imagine any programming system becoming successful without being largely open source.

Security holes present an interesting challenge. Since we allow authors to blacklist their code at the uuid level, it's possible to issue a network-wide advisory that revokes execution rights for that specific uuid.

This can instantly close the hole until a patch is released. This keeps users safe and gives application authors time to test against their application with the new library before re-publishing.

In many cases, application authors are the only people that are qualified to test interactions between their applications and the updated library.

A step backwards compared to what? Are you thinking about a specific alternative approach?

Generally speaking, we don't connect directly to unknown computers, but there are other reasons for that.

Security is addressed at a few levels (here are 6 of them).

1. Access to native resources requires specific permission.

2. All processes (including those with access to native resources) can only be addressed by their 288-bit process identifier (128-bits of which are random). The only identifiers known to a process are its own, those of its children, and ones explicitly given to it.

3. The Actor model means each process can independently decide which messages to reply to, which to ignore, and how long to wait for a response (if at all).

4. Each node has a unique RSA key-pair. The 160-bit fingerprint of the public key is the non-random part of every process identifier. This allows nodes to verify the remote processes they communicate with. (And if necessary, encrypt messages sent to them.)

5. Hash-based distribution makes it easy to blacklist poorly-written or maliciously-crafted code, once it's been identified as such.

6. System services in Skynet are always kept current with live, on-the-fly updates.

It's worth noting we (the team that's building Skynet) didn't set out to build a parallel language, we set out to build a distributed one. It turns out that a lot of the things that make Spin a good distributed language also make it a good parallel one.

- ask for input from the previous year's teacher

- students only pick one other person, so picking their entire clique wouldn't fit as an answer. further, as good students tend to find one another, it's a good filter for finding people that should be recommended by the teacher but aren't (or vice-versa).

- if a full essay is too much, just ask them to write what they'd do with their scholarship in a few sentences (prose, poem, any form will do). since you're only looking for 2 kids, you only need a question that will highlight the top candidates. no need to properly rank the entire class.

you mentioned that when you plotted score vs income, there was a clear correlation- i was suggesting using this data to normalize the scores.

if trusting teachers is an issue, there are two options.

- polling multiple teachers (hopefully eliminating individual bias)

- polling multiple students.

for polling teachers, you might suggest that each teacher recommend 4 students.

for polling students, you might suggest that each applicant write 2 essays: why they should receive the award, and which of their fellow classmates should as well.

correlating these with exam scores might provide a clearer picture still.

i'd suggest a simple split:

- select the highest scores on the exam without question (these students will make your program prestigious)

- normalize actual scores based on "expected scores", select highest normalized scores (these students will highlight your program's accessibility, rewarding those who do much with little)