Hi there, TC-39 delegate and MetaMask co-founder here.
SES does address this, and strives to achieve "object capability security", wherein access to a function is equivalent to permission to use it.
One difference between an object capability approach and the capability-token approach described in the OP article is that in an ocap approach, you would have no need for passing around a capability token just to pass it to the restricted methods: Instead, you simply disallow importing modules by default, and now pass in any restricted methods to modules that you want to have access to them. I find this approach greatly more ergonomic, and if you ever want to further restrict a function, you don't need a new token, you just write a closure with your own policy defined in it!
By the way, we've developed a tool called LavaMoat that allows applying SES security to existing npm modules, no token-passing needed, by restricting the environment of each module per a policy file.
https://github.com/LavaMoat/LavaMoat
There's LavaMoat, which enables using SES confinement around normal npm packages by creating a policy file for what can be imported/required by that module (and can auto-generate a suggested policy file from what appears used, which fails to greater restriction/security, and can easily be expanded):
https://github.com/LavaMoat/LavaMoat
MetaMask is actually working hard on these problems, and building faster than ever, but they're big problems that aren't trivially fixed in a point release. You can expect some big announcements this summer.
A lot of that iMac's cost is its retina display, and you didn't bother buying a retina display for the PC. Running a speed test is silly, there are already major differences in the build.
To make this remotely more scientific, you'd either need to buy a 4k monitor for the PC, or use a Mac Pro and just take the monitor out of the equation.
That's true. They should have gotten a 5k screen with 5120‑by‑2880 resolution for the PC like the Mac. This Dell costs 2000 which would have reduced the available for the PC components. On the other hand if you don't care for such resolution the PC may be the better choice.
If they wanted a more apples to apples comparison in the hardware department, they probably should have added $600 to the monitor price[1] and paid for it by using the same CPU as the iMac (i.e. a 6700k)
The article also leaves out the cost of their IT guy's time to assemble the custom PC components. How much does an hour of Joseph WU's time cost? How many hours did it take for him to order, receive, unpack, and then assemble the components?
My guess would be most of Wu's time was spent researching which components to order, probably several hours.
On the other hand, if he's a full time employee, then it does not cost anything extra to have him do his job.
I guess the issue is the driving factor of the iMac cost is the monitor resolution. It would've made more sense (if they didn't need the resolution) to pick a different iMac and spec out a PC at a similar price point.
These kinds of posts attract the Reddit-ier crowd of commenters that already exists within HN, if you know what I mean. The title gave me that feeling; the article confirmed it; and the fact that there were enough comments to require scrolling, on an article about “Which computer is faster, Mac or PC???”, hit the nail on the head and sealed the coffin.
Its color accuracy is also better than most -- it has 10-bit screen colors for one. EIZO equivalent quality monitors go for $1500 and higher even for crappy resolutions.
The Mac Pro can dissipate way more heat than an iMac, so between the two GPUs it can have almost twice the FLOPS of the iMac's GPU, even though it's several years older.
I used to use Repetier Host to run Slic3r and send the serial signals to my printer, but over time I've grown to prefer Slic3r's interface, and now that it has OctoPrint integration (send to your Raspberry pi print server wirelessly), it's the only application I need on a computer to print on my Reprap.
SES does address this, and strives to achieve "object capability security", wherein access to a function is equivalent to permission to use it.
One difference between an object capability approach and the capability-token approach described in the OP article is that in an ocap approach, you would have no need for passing around a capability token just to pass it to the restricted methods: Instead, you simply disallow importing modules by default, and now pass in any restricted methods to modules that you want to have access to them. I find this approach greatly more ergonomic, and if you ever want to further restrict a function, you don't need a new token, you just write a closure with your own policy defined in it!
By the way, we've developed a tool called LavaMoat that allows applying SES security to existing npm modules, no token-passing needed, by restricting the environment of each module per a policy file. https://github.com/LavaMoat/LavaMoat
While we're at it, I'll plug an audit we did of the SES shim code: https://agoric.com/blog/technology/metamask-agoric-hardened-...