lambda

Hardware capabilities seem like they could be an interesting alternative to traditional separate address space memory management; they could allow you to have fine grained access control to individual objects in memory without having to have separate address spaces via a TLB.

However, they seem to be trying to stuff so much into the capability; there's a base, a length, and offset, permissions, sealing bits, extra bits reserved for user permissions, and so on. They're 256 bytes, 4 times the size of a normal pointer, plus an extra tag bit for validity.

They do have a compressed 128 bit version, with various alignment constraints, but it seems like they are trying to stuff too much functionality into these capabilities.

I feel like it might be more instructive to start from a much simpler capability design, with just simple fat pointers with a few bits used for tagging (due to alignment, or not needing to use the full 64 bit address space), and see how far you can get with that, without adding in all of the extra features and needing huge pointers or funky compression that imposes much stricter alignment constraints.

"The score is the total benchmark time. The lower the score, the better."

This is something that I've been hoping to see for a while. The traditional model of web apps, with a database backend but doing manual de-normalization, adding manual caching and cache invalidation, or using manually created and expensive materialized views, seems complex, fiddly, and fragile.

The database engine should be able to build the necessary cache of intermediate state from the queries used by the application; and this shows that that is in fact possible.

Source: https://github.com/mit-pdos/noria

EditShare | Linux Application Developer, DevOps | Boston, MA; Warsaw, Poland | Remote possible

EditShare sells storage, backup, workflow, and asset management systems for professional digital video ingest, playout, and editing.

EditShare is seeking a highly-talented developer eager to work on GNU/Linux-based video storage and archiving products in our Watertown or Warsaw offices. Technologies in our products span the entire computing stack, from low-level kernel modules and optimizations, to high-performance distributed storage and network applications, to user-facing cross-platform and web-based client applications. We even run and support our own GNU/Linux distribution!

https://www.editshare.com/python-developer

work@editshare.com

Cabot Creamery in Vermont is another fairly well known example of this; it actually happens to have joined with a larger but less publicly visible coop known as Agri-Mark.

The Rust team took the approach of targeting application code on the three primary Tier-1 platforms, macOS, Windows, and GNU/Linux, as the goal for API design and portability of the standard library.

Besides the standard library, it also has the core library, which is a small subset that is appropriate for all environments, even those without allocation or those with different strategies for allocation.

With this goal in mind, many of the decisions make sense. A portable application can't rely on getting errors on out of memory situations. Many people don't write code that handles out of memory, or if they do they don't test it, which can lead to significant bugs. Error handling for out of memory is cumbersome if it is required for every operation which could allocate memory, such as pushing to a Vec.

Additionally, Rust 1.0 didn't have some of the later features to make error propagation simpler, so functions which could return errors were more cumbersome to use.

And finally, fallible allocation can be added after the fact. It is being worked on: https://github.com/rust-lang/rust/issues/48043

For now, anyone who wants to use Rust in those situations, but still wants allocation support, needs to implement their own allocator and collections with fallible operations. Once the allocator API and fallible collections support lands, much more of the Rust standard library will be usable in such an environment.

Looks like it was as of LLVM 6: https://github.com/rust-lang/rust/pull/50744

According to the "Update to LLVM 7" ticket for Rust (https://github.com/rust-lang/rust/issues/50543), many of the points of interest are in LLD, especially in WASM support:

    LLD has implemented --gc-sections for wasm
    LLD has implemented DWARF debugging information sections for wasm
    LLD has natively implemented concatenation of custom sections for wasm
    LLD has gained the ability to place the stack first in a wasm module's memory layout, reducing the corruption that happens on a stack overflow
    LLD option to not merge data segments
    Some SIMD generic float intrinsics have been fixed
    LLD optimizing further the size of release binaries
    LLD supports @-file syntax

Other things which mention LLVM 7 in the Rust bug tracker:

https://github.com/rust-lang/rust/issues/52457 "use funnel shift intrinsic to implement rotates"

https://github.com/rust-lang/rust/issues/52323 "emscripten already supports the wasm backend in LLVM7, so we should move the current emscripten-llvm from version 4.0 to that, so that we can remove all the workarounds lying around for LLVM < 5.0 (LLVM 5 is the new minimum supported version)."

https://github.com/rust-lang/rust/issues/49740 "Use separate memcpy source/dest alignments in LLVM 7"

https://github.com/rust-lang/rust/issues/51872 "Simplify u128->f32 casts thanks to LLVM r334777"

edit to add: rustc stable 1.29.0 already uses LLVM 7, and nightly is already using LLVM 8; rustc frequently switches to the new LLVM release when it is branched, it doesn't wait until it is released:

  $ rustc +stable --version --verbose
  rustc 1.29.0 (aa3ca1994 2018-09-11)
  binary: rustc
  commit-hash: aa3ca1994904f2e056679fce1f185db8c7ed2703
  commit-date: 2018-09-11
  host: x86_64-apple-darwin
  release: 1.29.0
  LLVM version: 7.0
  $ rustc +nightly --version --verbose
  rustc 1.30.0-nightly (79fcc58b2 2018-09-18)
  binary: rustc
  commit-hash: 79fcc58b24d85743d025fd880fca55748662ed3e
  commit-date: 2018-09-18
  host: x86_64-apple-darwin
  release: 1.30.0-nightly
  LLVM version: 8.0

It may be impossible for you to get what you're looking for out of a "portable assembler." There's a fundamental tension between low-level control, optimization, and portability. Either you will have code that will run dog-slow on certain architectures, as the compiler has to jump through hoops to do things like unaligned reads and writes that you ask it to do, or it will simply fail to compile certain architectures, or you will encounter undefined behavior on other architectures.

Whichever way it happens, you'd have to rewrite the code for different architectures. If you're rewriting the code on different systems, why aren't you just using an assembler instead of a portable assembler?

However, Rust may be the answer you're looking for.

Right now, in safe code, all operations are well defined; there are a few compiler and standard library bugs which allow undefined behavior, but that's not intentional and many of them are just waiting on some compiler refactoring to land before they will be fixed.

In safe code in Rust, you can pass around references (bare pointers with no GC), work with byte arrays, allocate things on the stack or on the heap, etc. It does provide some restrictions in what you can do to make it possible to check statically that all of your code is safe.

There is also an unsafe subset; this allows the "I know what I'm doing" kind of manipulations you can do in C. Of course, this means that you could encounter undefined behavior; if you do something incorrectly, it could cause arbitrary behavior. The compiler has to be able to rely on certain guarantees that you uphold, because otherwise it could perform not even the most basic of optimizations, nor in many cases even know how to correctly compile the code.

There is an active effort to specify the exact guarantees applied to unsafe code. Right now it's "whatever the current compiler and LLVM happen to do", which is not particularly good in terms of guarantees.

The idea is to try to make something which will be amenable to validating the code. If undefined behavior is sufficiently well specified, then you can compile the code in an instrumented mode which will detect undefined behavior (at significant cost in speed), and you can run your test suite in that mode to get reasonably good guarantees that you don't have UB in your program (as long as your test suite has sufficient coverage).

Clang and GCC have similar modes, undefined behavior sanitizers, that compile code with instrumentation that can detect certain classes of UB. Since C's memory model wasn't designed with this in mind, and C has a fairly weak type system, they can't cover everything.

The hope with the current work on Rust is that a memory model can be formally defined such that all UB could be detected by such a sanitizer, so as long as you have sufficient test coverage, you can be confident of avoiding UB.

Of course, there are other tools you can use as well to avoid UB, like formal proofs of correctness, but it can be quite difficult to fully specify the language in a formal system, and writing proofs of correctness in such systems is not a trivial task.

Air New Zealand already offers the Skycouch, in which an additional portion of the seat folds up to make them wider and you can lay across all three seats: https://www.airnewzealand.com/economy-skycouch

I've flown on it once. It's not as nice as a real bed, you can't fully stretch out without sticking your legs into the aisle, but it's a heck of a lot nicer than trying to recline in a normal economy seat.

I don't know exactly how much it cost, since someone else had bought the tickets for me, and may have used frequent flyer benefits to offset the costs. I think you basically pay the cost of each extra seat, so it's not cheap, but cheaper than upgrading all the way to business class to get seats that recline all the way to flat. If you have someone you're comfortable sharing with, then you only pay for one extra seat for the two of you.

> I got all three options and cleaned all three dishes. A near heavenly experience.

Wow! That's a lot of food!

However, you inspired me to hit them up for lunch again. Work from home and usually eat lunch at home, but went out and had Wilaiwan's today. Excellent as always; I ought to do that more often.

Are you referring to Wilaiwan's in Montpelier? Excellent place that's only open for weekday lunch, and Saturday lunch when the Farmer's Market is running in the summer.

They usually cook large batches of three dishes, and are open 11 AM to 2 PM or whenever they run out, whichever is sooner; and they do seem to frequently run out, I've found that going at 1:45 is not a good plan.

There's a set of docs on Fuchsia that you can read about if you'd like (https://fuchsia.googlesource.com/docs/+/master/the-book/)

There's some discussion of it already on HN: https://news.ycombinator.com/item?id=16813796

Some advantages of the Fuchsia architecture over Linux for Android:

* Capability based system; applications only get access to objects, including files, directories, other processes, etc via capabilities, so they can only affect those objects they have been given access to directly. This is much better for security and isolation of applications.

* Userspace drivers with a stable ABI, or with the possibility of versioned ABIs. This could allow them to ship updates to the underlying system without waiting for vendors, reducing fragmentation.

You can add subtitles or closed captions to the video. It also supports adding a transcript (like subtitles or closed captions, but without timing information), and it will use speech recognition to try to line it up with the video.

You can also add a transcript or a link to a transcript in the video description.

Yes, but they are still shipping AOSP and still selling Pixel phones with unlockable bootloaders.

Clearly, Google wants to be able to support companies which want to sell locked-down phones.

But as long as they sell their own phones with unlockable bootloaders, you can vote with your wallet and buy those phones.

I am concerned about the reduction in use of the GPL, but what I care about is being able to run and modify the software on my phone, and as long as Google is still releasing AOSP (and the Fuchsia open source project), and selling phones that are unlocked, I'm happy enough with that.

Yes, they might change their policy in the future. But for now there's no indication that they intend to do that; they've always been good at selling their own phones and Pixelbooks with unlockable bootloaders that does allow you to replace the ROM if you want.

I've been happily buying Nexus and Pixel phones for as long as they've existed, on which you can easily unlock the bootloader and build your own ROM if you want. I don't see why Google would stop doing that just because they've released a new OS.

If you're concerned about installing your own software on your own hardware, why not buy it from a manufacturer that protects your freedom to be able to do so?

In your 35 second blurb, and the New York Times article, it seems like the point you're making is that interference is the main way that quantum computers work. But what makes quantum interference special over other kinds? You can get interference in sound waves, light waves, radio waves, etc. You also mention that magnitudes can be complex, but the same is true of other kinds of waves; complex numbers are used for discussing impedance in electronics.

These are even relatively simple to work with; back in high school, I set up my basement as a darkroom, set up a sandbox for isolation, borrowed a laser from my physics teacher, bought a kit online with a beam splitter, mirrors, lenses, and film, and made some holograms of various objects utilizing light interference.

You could set up an apparatus in which light goes through a beam splitter, reflects off mirrors to travel via different paths, and is recombined and interferes in the end to produce an interference pattern. You could probably encode a lot of information in the exact length of the different paths, perhaps in an array of mirrors which could be actuated to produce slightly different path lengths in different parts of the beam (after the beam is expanded), and use the interference to make calculations.

Other than the smaller scale, and greater difficulty of working with it, what is special about quantum interference that would make it more amenable to solving problems that are NP complete than some apparatus producing similar kinds of interference with light?

Also, has it been proven (or argued sufficiently convincingly) that quantum computation at scale is actually possible? I'm wondering if there could be an issue where it requires more computation to construct a quantum computer than the computation you get out, or require a non-constant number of quantum computers (with respect to the size of the problem) to actually get reliable enough results out, or something of the sort.

I think this is somewhat like the questions of whether certain automata are Turing-complete (https://en.wikipedia.org/wiki/Wolfram%27s_2-state_3-symbol_T...), when a sufficiently complex process is needed to encode the problem into the automata that it could be argued that the computation was not actually carried out by the automata itself (I don't actually know if that question was answered; Wikipedia references a mailing list thread that has a lot of discussion, but I haven't seen any authoritative conclusion).

Given that empirically, only extremely simple quantum computers have been able to be constructed, what makes us think that there isn't some kind of tricky scaling issue like this were the additional complexity of building, running, or verifying the results of quantum computers will negate the benefits?

You missed two thirds of my comment.

This was in order of preference. If you can, use free software that you can fix and support yourself if need be. If not, buy the software and run it yourself, so you can at least control its operation. The last option is to by SaaS, and if you do, you need to have contingency plans in case it goes away. You should take this risk seriously, and factor it in to your decision when buying SaaS, and invest the engineering resources to make sure you aren't overly dependent on it.

Yes, I should have been more clear that what I meant was that this is one possible alternative explanation that hasn't been ruled out by the experiments done, not that this is the only possibility. I had said "could have been consciously or subconsciously prompting her" and should have also said "could have been using their own theories of mind and inference ability to read more into Koko's actions than what is really there."

I was just trying to list one more possible explanation that the experiments hadn't ruled out, not cover everything, but you're right, those are each also possibilities.

Use free (FLOSS) software.

If you have to use non-free software, buy software, not services.

If you have to buy services, always have a well-tested fallback path for when that service is not available.

The problem with all of this is that using these kinds of emotional reactions to evaluate research can lead to making some significant errors that can cause real harm.

As an example, facilitated communication was once touted as a way in which non-verbal autistic people could communicate with the outside world (https://en.wikipedia.org/wiki/Facilitated_communication). The facilitators thought it worked. Parents thought it worked. It felt great to be able to talk to your kids who you could never talk to before.

The problem is, it was complete bunk. If you did any kind of actually blinded test, such as showing one picture to the facilitator and another to the subject, they would write out what the facilitator saw. The facilitators themselves weren't even aware they were doing this.

But on the basis of this completely pseudoscientific method, there had been parents who had been accused of sexual assault of their children and kicked out of their house because of it, when in reality the abuse had just been imagined by the facilitator.

Emotions are definitely important in communication, and communicating emotions with animals is definitely possible.

But there are real reasons for demanding better evidence before claiming that you are interpreting language on behalf of some other person or animal.

> quantifiable, numerical data we are used to in engineering and computer science

You make it sound like quantifiable, numerical data is a fairly niche thing, but of course it's used in pretty much every field of scientific inquiry.

Science is the practice of using the best tools we have to better understand the world around us. Subjective description of interactions with the world around us is just a very basic baseline from which to start inquiry, not something that you can say has led to meaningful results.

In this case, it doesn't even necessarily require substantial numerical data to evaluate these claims; just basic blinding procedures, like evaluating the results of Koko describing something that she saw that her handler did not, and getting some basic statistics over a number of interactions to see if they do better than chance.

That's not training dogs to breath water, that's altering the water to be breathable by dogs.

If you want to look at it that way, nothing is qualtitively "entirely different." We can all breath water to different degrees, and if you go down that route, then there's no real qualitative difference between mammals and fish, right?

Saying that these differences aren't qualitative and are just difference of degree isn't really a useful way to have discourse. There is absolutely a qualitative difference between how respiration works in mammals and fish, and just because you can manipulate the environment in some way to make it work doesn't change that.

Language is in the same way qualitatively different than other forms of communication, just as mammals are qualitatively different than fish.

Humans can communicate in language, and can communicate other ways. If I go to China (and I don't speak Chinese), I can buy food by pointing to it and having someone hold up their fingers to signify the price. I'm not communicating through language, but I have communicated effectively.

And you wouldn't call what I did there sign language; it is not a consistent set of signs shared by a group of people which can be composed into an infinite number of sentences with arbitrarily complex meanings. It is instead a fairly limited method of communication which can be used to communicate a fairly direct concept, I need that thing, along with a response that simply indicates a number for how much is expected in payment.

I don't know why you keep on referring to the distinction I'm making here as "divine-granted." I'm simply making a distinction between language, and communication that is not language.

The "entirely different" part is about specific claims about language.

There are many different ways animals are able to communicate with each other, and with humans. Sounds, gestures, songs, body language, scents, and so on.

They can get quite creative, they can be used to communicate emotion, they can indicate that the animals have some sense for the mental state of who they are communicating with, and so on. Almost all of this is fairly obvious to anyone who's ever owned a pet (though there are plenty of cases in which there can be some subjective bias there, so it can be good to devise better tests if you're really skeptical).

But none of them have been demonstrated to have the arbitrarily complex, abstract, compositional nature that human language does; in which a finite (but large) set of words or signs can be strung together in arbitrarily complex ways, allowing a countably infinite number of different ideas to be potentially conveyed.

This is qualitatively different than any other communication method that has been demonstrated in other animals.

There's no dogma about it; it's just something that is unique to humans, as far as we know, just like the amazing ability to manipulate skin color and texture is something that's unique to cuttlefish. There are some things that certain kinds of animals can do that other kinds of animals can't, like flight, breathing via water or air, producing venoms, and so on.

It would be a pretty big scientific breakthrough to discover that there was some mammal that could change its skin like cuttlefish, or to discover that a mammal could be trained to breath water.

Likewise, discovering that non-human animal can learn a human-like language, with its arbitrary complexity through compositionality and ability to express abstract thought, is a pretty big claim too. The problem is, some people make this claim, without sufficient evidence to back it up.

Helen Keller was able to communicate directly with people without a specific facilitator, eventually by learning to speak, to write, to read braille, to understand sign language by touch, and to lip read by touch. She was best with her first teacher, Anne Sullivan, but she could communicate directly with other people in many ways without facilitation.

This definitely does have implication on treatment of people with disabilities; the same kind of pseudoscience was once popular with non-verbal autistic children, called "facilitated communication." However, some fairly basic blinded testing, showing the facilitator one picture and the subject another (possibly the same, possibly different), demonstrated that it was entirely the thoughts of the facilitator being communicated. Many of the facilitators didn't even realize this; they didn't realize they were subconsciously prompting.

https://en.wikipedia.org/wiki/Facilitated_communication

I recommend the PBS documentary "Prisoners of Silence" on this: https://www.youtube.com/watch?v=5sO9LyXuOQY

So yes, there are implications, and those implications are that it is important to be thorough in demonstrating that some kind of facilitator in any communication is actually accurately representing communication from the subject, as opposed to themselves.

I responded to this point in somewhat more depth in another comment:

https://news.ycombinator.com/item?id=17367375

What bothers me is not the idea that another animal could understand language, but the very poor evidence being presented for it in the case of Koko.

That coupled with how much coverage Koko got from media and celebrities can skew people's view of the scientific process and standards for evidence.

And very similar kinds of pseudoscience have been used with humans with non-verbal autism, in something called "facilitated communication," which has turned out to be entirely based on the facilitator's thoughts. This has caused real harm to people, with parents being accused of sexual abuse of their children, when it was all just imagined by the facilitator.

So what bothers me is the extreme carelessness of scientific process, and heavy amounts of self-promotion and publicity with extremely little skepticism, as that can lead people to not properly evaluating other similar claims like FC.

This isn't about "new and unique ideas" in the sense of some profound insight. I was responding to the "was capable of communicating new and unique ideas" from the parent, which is a way of paraphrasing some of the claims about Koko's language ability, in which it is claimed that Koko was going beyond mere use of single words to refer to literal objects or actions.

I can put together a complex sentence describing abstract ideas, which is what I'm doing here. A dog cannot; a dog can understand a single word or sign in isolation, and may be some amount of literal sequencing, but there is no ability to understand an arbitrarily complex sequence of signs or words containing abstraction like human language is capable of.

The claim about Koko's use of sign language is that she has been able to compose sentences out of combinations of words, and express abstract ideas; maybe somewhat more limited than humans in some way, but fundamentally the same way that human language works.

That's what the skepticism is about; since while it's clear that she could be trained to recognize individual words and produce individual signs, and maybe some limited pairs, all of the evidence of anything more complex seems to come from interpretation through her handlers, who could have been consciously or subconsciously prompting her, and are using their own theories of mind and inference ability to read more into Koko's actions than what is really there.

There's plenty of non-verbal communication you can do with a dog or even a cat. They can pick up on emotional states. They have memories. They can learn words or signs. They can be caring.

A lot of the claims about Koko seem to be either unsurprising for anyone who has owned a pet (yes, pets can sometimes be surprisingly emotionally intelligent), or go far beyond what the evidence actually supports, relying much too much on subjective judgements and unblinded tests by the researchers.

One of the reasons that this is a problem is that this exact same kind of thing is done with humans sometimes, in the form of "Facilitated Communication" (https://en.wikipedia.org/wiki/Facilitated_communication), which is claimed to be a way of training "facilitators" to help calm and guide non-verbal autistic children's hands to be able to type out sentences and communicate.

This was a very popular form of assistance for a while, and it even led to autistic children being able to speak out about their abusive parents. Except, as it it turns out, it was entirely based on pseudoscience. Once you did any kind of blinded testing, where you showed something different to the facilitator as you did to the patient, they would spell out the word for what the facilitator saw. The parental abuse, for which parents had been kicked out of their own homes and not allowed contact with their children? Entirely imagined by the facilitators.

I'd recommend watching the PBS documentary "Prisoners of Silence" on this topic (https://www.youtube.com/watch?v=5sO9LyXuOQY).

Allowing this kind of pseudoscience to get so much coverage can cause real harm to people, and it erodes faith in the scientific process.

How many of these "new and unique ideas" could be attributable to Koko and not her handlers? Almost all interpretations of what Koko's signing means come from her handlers, not from neutral observers.

Dogs can be trained to recognize hundreds of words, perform many tricks based on hand gestures, can engage in different body language to indicate different things that they want at the time, and can show true affection to their human companions or other pets in the house.

What bothers me most about Koko is that she has been presented as something entirely different than a smart, well trained dog; that she has some deeper understanding of language and can combine words in novel ways, but the evidence really looks like there's a lot of cherry picking and prompting by the researchers to get at that.

Oh, wow, Hangouts and Meet are working in Firefox now? I've been keeping Chrome running just for that for a couple of years, will be glad to stop having to do that.

Yeah, it looks like the author started playing around with D and writing a Pascal to D compiler for the migration, then did the evaluation with a "requirements" list that seems fairly heavily weighted towards D and their approach to translation by doing a simple recursive walk of the Pascal parse tree and outputting equivalent D, then decided to go with what they had already started working on.

Rust does support nested functions that don't close over their environment, and has a separate syntax for closures which do, and closures can either move or borrow their captured variables. This makes it a bit harder to write a translator that produces good, idiomatic results; you could always use a closure that borrows the closed over variables, which I think matches the Pascal semantics, but that would mean the code would look a little odd for cases in which you had a nested function just to factor out some functionality and didn't need the closure.

  fn main() {
      let a = 10;
  
      fn function() {
          println!("Hi!");
          // println!("a is {}", a)
          // fails with:
          //   can't capture dynamic environment in a fn item
          //   use the `|| { ... }` closure form instead
      }
    
      let borrow_closure = || println!("a is: {}", a);
      let move_closure = move || println!("a is still: {}", a);
    
      function();
      borrow_closure();
      move_closure();
  }

One really useful tip for Wireshark that's not as obvious as it should be.

Increasingly often, what you need to debug is a TLS connection. However, that can make debugging more difficult as the contents of the connection are encrypted.

However, if you can access the server key, whether you have access to the production server, or are working in a development environment, or you MITM yourself with mitmproxy, or you're working on some product that ships the same default server keys with every install, you can load the key into Wireshark and then decrypt all of the TLS traffic.

To do so, go to Preferences > Protocols > SSL, and click "Edit" next to "RSA keys list". Then you can load private keys in, and associate them with a host and port, and when you have a TLS connection on that host and port, Wireshark will decrypt the traffic and you can see the inner protocol.

https://wiki.wireshark.org/SSL

Note that this doesn't work if you use a cipher suite with forward secrecy, though it looks like there is support for that as well if you enable logging of ephemeral keys in your client or server (https://security.stackexchange.com/questions/35639/decryptin...)