signifiers

If you're referring to full-blown IntelliJ, Elcipse, VS, etc, the answer is no afaik. But if syntax highlighting, code completion and lightweight refactoring (within and across files) counts, then Caret or Zed might be worth a look. These are native Chrome apps, and don't require web access/connectivity. (I wrote most of the Chromebook piece in the OP and all my Go code using Caret, and am happy with it). I did some toy stress testing by opening up a few copies of War & Peace (1.5M+ line) text files in Caret. It took a couple of seconds to load, but search & replace and rapid scrolling/navigating worked well. Trying the same thing in vim either in Termux natively or via local ssh didn't hiccup at all. As mentioned in other threads, it's a side effect of design decisions, and naive assumptions about in-memory files. Kids today...

that is not correct.

(author here) I think this was misunderstood. I don't mean the _entire_ Chromebook or OS was unstable -- just the opposite actually. I was referring to having to restart Termux twice in two weeks. Two weeks of constant wake/sleep cycles on and off battery, and plugging/unplugging from an external monitor.

In one case it was a hard kill and I lost one ssh window that had been open for a week. In the other, the Termux gui came up and I never dropped my session (the ssh process never died). I'm not yet familiar enough with the Termux internals to understand that. As far as the Chrome OS stability, it's been one of the most stable machines I own, and I say that as a long-time MBP & Librem owner. 99% of the reboots were intentional as I reinstalled the whole build from Powerwash to Erlang hello world, to make sure I got the details right for the post (and to help troubleshoot some minor install roadbumps a couple of my reviewers experienced).

On the presentations, I joined multiple Hangouts & BlueJeans (WebRTC) video client calls with zero trouble. Signal and Wire voice worked like a champ too.

So while I certainly understand some of the comments here, for _my_ use case — a reliable $160 multi-week travel/burner dev notebook with strong security, I'm more than satisfied. And of course it's not in the same league as my $2K++ MBP. I would never try to run a big JDK app, but for offline Go and Python work, it fits my bill.

It's a common misconception. Chris Pinkham and Ben Black created it, and it never had anything to do with excess capacity. http://blog.b3k.us/2009/01/25/ec2-origins.html

Yes, modems, access points, LTE tablets included. Consumer and Enterprise users (including me) are seeing it. Eg: https://twitter.com/innismir/status/525279100907560961

Interesting. They're definitely ignoring it my case: https://twitter.com/kennwhite/status/525369304456658944

They're ignoring it for me. See: https://twitter.com/kennwhite/status/525374343074029568 Can you confirm you connected over cellular when testing?

The backporting involved here is non-trivial. If the past 9 months are any indication, I would expect we haven't seen the last of the serious YAML vulnerabilities yet: http://www.cvedetails.com/vulnerability-list/vendor_id-12043...

I hear this argument all the time, but let's get real. A million dollars in Berkeley isn't exactly a dump: http://www.ziprealty.com/property/6905-NORFOLK-RD-BERKELEY-C... this isn't too shabby either: http://www.ziprealty.com/property/42-MAIN-ST-SAN-QUENTIN-CA-...

Now, I'll grant you, Palo Alto and San Mateo have a fair number of unexceptional ranch homes in this region, but it's bullshit to claim that you have to spend $1M to secure a minimally-decent family home in the Bay area.

Edit: Little bit of reality here (like $500K+ homes in San Mateo, and rentals in the $2,500-3,500/mo range): http://www.zillow.com/homes/san-mateo,-ca_rb/ http://www.zillow.com/homes/for_sale/Palo-Alto-CA/26374_rid/...

“The statement is patently false. Sid implies that what was perceived from a public demo is CipherCloud's product offering.”

http://www.pdf-archive.com/2013/04/20/notice130419/preview/p...

> GCE is currently in the US only.

Not correct. They've had EU zones since November:

https://developers.google.com/compute/docs/faq#datacenters

https://developers.google.com/compute/docs/pricing#table

Actually, I would call 5.3 as a fairly major jump - namespaces, closures (Lambda/anonymous functions), late static binding, const's allowed outside of classes. There are several popular PHP frameworks that require v. 5.3+. Some people even go so far as to call the 5.3.x branch “php 6 without Unicode”.

They've been very reliable for us. Network is spiky (12-20MB/s at times), but otherwise, compared to roughly equivalent VMs (lscpu, /proc/cpuinfo, etc.) they are hands-down faster than AWS. In the limited testing we've done on AWS SSD AMIs (optimized for cluster compute), AWS wins on network and CPU, but at literally 10X the cost.

Also, see: http://serverbear.com/9806/digitalocean for interesting benchmarks over time (with all the standard caveats, yada yada).

If you use keys, no password is sent. An option to not send password by mail (for non-key-based launches) is on the coming-soon roadmap: http://digitalocean.uservoice.com/forums/136585-digital-ocea...

I bet they are fairly liberal with their size limits:

http://www.amazon.com/robots.txt http://aws.amazon.com/robots.txt http://www.google.com/robots.txt http://store.apple.com/robots.txt

For those who don't follow this closely, from @MuscleNerd (of the gang-of-four): https://twitter.com/MuscleNerd/status/295964113270620160

Nothing has been announced, but fwiw, I've been running benchmarks comparing the SSD block storage at Rackspace (http://www.rackspace.com/cloud/blockstorage/pricing/), as well as the all-SSD VMs from Digital Ocean (http://www.digitalocean.com/), and frankly, the CPU & I/O blow away EC2 so far. Compared to Google Compute Engine (https://cloud.google.com/pricing/compute-engine), CPU is on par, but obviously SSD is going to best even zippy local instance spindle storage.

For example, calculating 8th order Fermat prime factors (single thread/core intensive, so ymmv), EC2 XLs are getting smoked by 20-50% vs. Digital Ocean's 2 core 2GB RAM/40GB SSD. Replicated in multiple data centers/zones a dozen times. Not bad for $20/month!

Also, for the low end, remember "core" on EC2 is throttled at 50%-75% for the small & medium instances, translating to lots of stolen cpu time.

Still working out the details on the Rackspace SSD EBS-equivalents, but will post update soon.

But, agreed, given across-the-board I/O benefits of SSD, surprised Amazon isn't offering something in the non-cluster category. And at $2,500+ /mo, the new instances are definitely targeting a very niche use case for burst-heavy batching.

Didn't think I'd ever see a .gov page officially referencing: a) a ballot initiative, b) marijuana and c) Cheetos & Goldfish, but here you go: http://www.colorado.gov/cs/Satellite?c=Page&childpagenam...

Key line of the article: “Since Netflix focuses on making sure services can handle individual instance failure and since we avoid using EBS for data persistence, we still did not see any impact to our service.”

As an architecture design, the choice to avoid EBS is hotly debated, though many high-profile systems besides NetFlix (SimpleGeo, Sprint.ly) have moved almost exclusively to EC2 instance-backed (local disk) VMs and as a result, avoided the pain of the last 3 major AWS outages.

Too true. Today when Google's App Engine failed hard, they flat out said: "App Engine is currently experiencing serving issues – Python, Java, Go … Oct 26 2012, 07:30 AM-11:59 PM … Current Availability: 55.90%" and showed read/write I/O metrics were spiking through the roof. Their dashboard clearly labeled the relevant icon as the most severe "Service Interruption".

I admire that level of transparency.

I could not agree more, and have had zero downtime since the fleet-wide reboot last December from any of 20+ instance-backed VMs in US-East. Joe Stump of SimpleGeo and Sprint.ly and many others have come to the same conclusion.

While we have a couple of RDS instances, nothing is production critical. And this: "the root cause of the Multi-AZ [MySql|Oracle|SqlServer] failures we observed during this event will be addressed" only confirms my observations from the RSS history in the dashboard, that in nearly every major EBS-related "service event" (including the ones that happen every few weeks and never get this level of post-mortem), the managed databases, load balancers and config management (beanstalk) services go down too.

When you move from AWS' basic EC2 IaaS VMs with instance (ephemeral|local) storage to EBS-backed (basically vSAN) storage, your multi-month uptime odds go down considerably. But when you step up to the PaaS of managed DBs, load balancing, dynamo, etc., yes, they offload a ton of management drudge, but it's an order of magnitude more fragile.

The unpredictability of performance, network contention and stability with EBS, for me, just doesn't outweigh the relatively smaller risk of hardware disk failure I take on from instance-backed nodes. Yes, I know, disks fail - but EBS disks fail a lot, and when they do, good luck fighting the herd to spin up more -- or crap, now, even getting web console access to understand what the hell is happening. That's the irony here - API access (including issuing more IPs!) is "throttled" at precisely the time when you need it most.

My advice? Instance-backed >= large, and roll your own failover/DR/load balancing. Go ahead and "plan for failure" - but do it old school: plan for the more likely case of simple h/w failure, not the EBS control plane and everything that depends on it.

Unknown? Rutkowska has done some of the most interesting security research in virtualization security, including most famously the "Blue Pill" and "Red Pill" demonstrations - escalating privileges to Dom0 (and detection of presence of a hypervisor by the client). For both HVM and PV architectures (e.g., Windows & Xen), she and her colleagues have done ground-breaking work that have impacted the implementation of every major commercial and open source virtualization.

Academic pubs != Relevance

Edit: But since you asserted it, here are researchers that cite her work (over 130, including IEEE and ACM folk):

http://scholar.google.com/scholar?cites=13610021170603453007...

Look again.

LUKS is used for all filesystems. Qubes was specifically engineered to block the Evil Maid scenario and similar vectors for notebooks. See pg. 31 from http://qubes-os.org/files/doc/arch-spec-0.3.pdf:

"There are several things that all together make the storage secure in the Qubes architecture:

1. Confidentiality, understood as preventing one VM from reading other VMs data

2. Confidentiality, understood as preventing access to the data when the machine is left unattended (full disk encryption, resistance to Evil Maid attacks, etc)

3. Integrity, understood as preventing one VM from interfering with the filesystem used by other VMs

4. Security non-critical role: a potential compromise of the storage subsystem doesnʼt result in other system components, like other VMs, compromise. Storage subsystem is not part of the TCB in Qubes OS."

See also, Section 7.1 System Boot Process, and 8.5 Resistance to Physical Attacks (or just search for "disk encryption").

Part of the mindset is that any Prime returns are dramatically easier than independent merchants, particularly new/relatively new sellers. If it's a trivial purchase, fine, but if I'm spending $100+, for me, it's usually worth a couple extra bucks knowing there will be zero friction if something's not right. Also, in my experience w/ electronics and physical books, the vast majority of independents take a day or two longer to ship than Amazon (both "regular" or as a fulfiller).

Research article here: http://stm.sciencemag.org/content/4/140/140ra86.abstract

The particular finding in the article is just the most recent insight from next generation DSI computational modeling breakthroughs. The article highlights the hardware/device engineering, but the real news is that by using these new modeling techniques, nearly all modern MRI scanners can benefit, largely unmodified.

As someone who works at the intersection of informatics & device engineering, I find these visualizations stunning.

And the embedded video in the article is not just eye candy, it actually represents a class of diagnostic tools that didn't exist a couple of years ago.

Guilty as charged on a modest bit of editorializing; just google DSI or its related cousin Diffusion Tensor Imaging and tell me that's not pretty cool.

As for "no math" mentioned in the article, that is true. But a cursory search for the terms tensor or fractional anisotropy and weighted trajectory projection models will quickly reveal just how much math is involved, regardless of a press release that glosses over that fact.

I just ran the numbers on the new EC2 instance, and I'm pretty skeptical about the benchmarks above. I'm not sure that, for example, a half second of dd /dev/zero really tells us much.

When interpreting any benchmarks on EC2, it's important to understand that there is a 5-10% read/write performance hit on first use because AWS uses lazy block wipes between customer instance launches. See http://www.youtube.com/watch?v=IedaYaKsb-4#t=29m49s (should pre-cue, if not, skip to 29:49). This is referenced in the docs, but it's easy to miss: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/In...)

So here you go, for hi1.4xlarge:

*

Summary for the impatient - After initialization (i.e., second-write), quasi-realistic I/O on the new SSD EC2 instances sustains writes @ 420 MB/sec and reads @ 6 GB/sec. The entire 8.6GB / filesystem copied over to SSD in 21 seconds.

Not bad.

*

    # df -h

    Filesystem            Size  Used Avail Use% Mounted on
    /dev/sda1            8.0G  1.1G  6.9G  14% /
    tmpfs                  30G     0   30G   0% /dev/shm
    /dev/xvdf            1023G   16G  957G   2% /media/ephemeral0

    (Note: /dev/xvdf and /dev/xvdg are just soft links to /dev/sdf and /dev/sdg respectively)

    Crude stats on first-use:

    # hdparm -tT /dev/xvdf

    /dev/xvdf:
    Timing cached reads:   14788 MB in  1.99 seconds = 7446.69 MB/sec
    Timing buffered disk reads:  1066 MB in  3.00 seconds = 355.04 MB/sec

    Wipe the device:

    dd if=/dev/zero of=/dev/xvdf bs=1M& pid=$!
    while true; do kill -USR1 $pid; sleep 4; done;
     [...]
    dd: writing `/dev/xvdf': No space left on device

    1048567+17 records in
    1048566+17 records out
    1099511627776 bytes (1.1 TB) copied, 1955.42 s, 562 MB/s

    Stats after zero-wipe (dd /dev/zero) to device:

    hdparm -tT /dev/xvdf

    /dev/xvdf:
    Timing cached reads:   13260 MB in  1.99 seconds = 6673.05 MB/sec
    Timing buffered disk reads:  1124 MB in  3.01 seconds = 374.02 MB/sec

    hdparm -tT /dev/xvdf

    /dev/xvdf:
    Timing cached reads:   11188 MB in  1.99 seconds = 5624.17 MB/sec
    Timing buffered disk reads:  1122 MB in  3.00 seconds = 373.99 MB/sec

    hdparm -tT /dev/xvdf

    /dev/xvdf:
    Timing cached reads:   12930 MB in  1.99 seconds = 6505.78 MB/sec
    Timing buffered disk reads:  1124 MB in  3.00 seconds = 374.15 MB/sec

    Confirming Effect Of Pre-wiped I/O:

    hdparm -tT /dev/xvdg

    Timing cached reads:   11796 MB in  1.99 seconds = 5931.68 MB/sec
    Timing buffered disk reads:  1038 MB in  3.00 seconds = 345.87 MB/sec

    hdparm -tT /dev/xvdg

    /dev/xvdg:
    Timing cached reads:   12658 MB in  1.99 seconds = 6367.41 MB/sec
    Timing buffered disk reads:  1050 MB in  3.00 seconds = 349.47 MB/sec

    hdparm -tT /dev/xvdg

    /dev/xvdg:
    Timing cached reads:   12856 MB in  1.99 seconds = 6468.39 MB/sec
    Timing buffered disk reads:  1066 MB in  3.00 seconds = 354.80 MB/sec

    Pre- Vs. Post-wipe performance: 373.6 MB/sec vs. 349.3 MB/sec (6-7% speed improvement)

    Somewhat more real-world numbers:

    dd if=/dev/sda1 of=/dev/xvdf bs=1M
    8192+0 records in
    8192+0 records out
    8589934592 bytes (8.6 GB) copied, 19.7876 s, 434 MB/s

    dd if=/dev/sda1 of=/dev/xvdf bs=1M
    8192+0 records in
    8192+0 records out
    8589934592 bytes (8.6 GB) copied, 20.0365 s, 429 MB/s

    dd if=/dev/sda1 of=/dev/xvdf bs=1M
    8192+0 records in
    8192+0 records out
    8589934592 bytes (8.6 GB) copied, 21.4193 s, 401 MB/s