HN user
Harvard '16 Molecular Biology & Government | Thiel Fellow | Previously: AWS, Sun Microsystems, others.
spartango at gmail
While there is extensive infrastructure for detecting active transmitting devices like Stingrays, there's no discussion (or tooling) around passive IMSI grabbers. These devices are significantly more limited (no IMEI or MSISDN, GSM-only), they remain pretty effective in areas/networks where GSM is still in place.
For what it's worth, PBS has an app[1] for Apple TV, and it has much of PBS' content.
With that said, the general problem of certain services being restricted from/to specific platforms is extremely frustrating, and will only get more painful as exclusives become common.
I'm not convinced this localization argument holds so much water. Consider the following:
Case 1: If you're using a search engine not based in the US, and you're not a US person, then the NSA probably can't use any legal tools against you (depending on country). However, the NSA is allowed to use the full range of its capabilities to collect against you (PPD28 notwithstanding). They can infiltrate that service by technical or human means and carry out espionage activity without legal restriction (Title 50/EO12333). Further, they can retain the data unredacted for a long time.*
Case 2: On the other end of the spectrum, if you're a US person and you're using a US-based search engine, surveillance activities against you are far more complex. Warrants, NSLs, and/or other legal paperwork is involved, and there are strict rules on data retention, sharing, and minimization. That's not to say that there isn't surveillance, just that it comes with substantially more overhead. Meanwhile, most of the NSA's technical exploitation approaches are off-limits, and any collection/exploitation activity must be carefully managed.
Case 3: The intermediate case, where you're a non-US person using a US service, is a bit more hairy but still is better than the first case. While the NSA/FBI can utilize a range of legal tools (again, warrants, NSLs, etc) against you, because your data is likely entangled with US-persons data, it must also deal with all the overhead of minimizing and redacting that data (same as case 2). Similarly, the use of technical means against US providers is heavily restricted, so you won't be fighting against the same capabilities as you would be in case 1.
At the end of the day, which do you think is easier for the engineers at NSA: exploiting, entering, and just taking everything (case 1) or filling out a huge amount of paperwork and carefully handling the redacted scraps of data that comes back from the provider eventually (cases 2 and 3)?
I think you can make an argument for either side, but I tend to believe that technical exploitation is easier than legal, for now.
*Caveat here is that this intelligence data is hard[er] to use in US law enforcement activity against you. It's worth noting, however, that NSLs and FISA data are also non-trivial.
Maybe I'm just out of the loop, but the author doesn't make it clear what exactly is objectionable about Palantir with respect to privacy issues. That's not to say that there isn't anything, but just that it would be helpful to have a synopsis of what exactly they're doing wrong.
I understand that they do work with governments, but that's as much as I've seen in the press. There has been far wider discussion of the privacy challenges facing Facebook and Google.
Neither the F-35B nor the F-35C carries a gun. The USAF's F-35A is the only model affected by this issue.
Also, the Marines want the STOVL F-35B for operation on LHA/LHDs, as well as small island bases with short/limited runways. It's not just the ski-jumping Brits who want that feature.
With that said, you're right that the STOVL capability has added substantial complexity to the airframe.
If you find the work in cancer interesting, it's worth looking into a few commercial outfits that are doing this type of testing:
* Genomic Health ($GHDX) with OncotypeDX
* Foundation Medicine ($FMI) with FoundationOne
Both of these companies have tests on the market that analyze tumor genomes (sequencing or microarray-based) and provide information to oncologists to better treat their patients. Information like drug efficacy and tumor aggressiveness (requiring chemo-/radiotherapy).
An email version of this would be quite useful for team interactions with sensitive partners/clients/contacts.
Cool, thanks. I hadn't seen this before.
For those wondering: CRIU is Checkpoint/Restore In Userspace.
http://criu.org/Main_Page is the project, and http://criu.org/LXC is container support.
From a quick look, it seems that there are some limitations in CRIU, especially with LXC support, but it is work in the right direction.
Your explanation is clever and could account for most of the behavior of the product. Certainly the environments, rapid booting, and even hot resizing.
What's missing, however, is how they do machine state snapshots (not supported in any container system afaik). I know Xen/VMWare support these, but if they are running atop AWS they will not have access to the hypervisor. I can imagine kludgily running another hypervisor atop AWS, but there would appear to be a more clever solution.
Xen/VMWare also support hot resizing of CPU and RAM.
What's interesting is that neither LXC nor Docker support memory snapshots (machine state), which Terminal.com has demonstrated. Xen, KVM, and VMWare do, but I can't really imagine people running these atop AWS infrastructure (Xen underneath).
Your demos show impressive speed in booting, machine resizing, and snapshotting. Kudos.
With that said, several hypervisors do support hot-resizing, snapshotting, and cross machine migration. Xen has excellent hot resize support, where VMWare has pushed hard for live migration and proper snapshotting over the years.
That 15 years of experience at one of the world's top software companies is seen is a negative disgusts me.
It seems disrespectful to judge an employee based on the negative perception of an entire company. For all the broken things within a company like Microsoft, I think it would be foolish to mark the company's talent pool as tainted.
Perhaps this reflects a subtler form of the fanboy-ism that exists in technology culture today. The sentiment is that companies we dislike must have incompetent employees. Competent employees would surely build a better product, right? Obviously this is naive.
Absolutely right, ageism plays into this as well. If you're hiring, keep in mind that, while fashionable, it is illegal to discriminate based on age. I wish this law was slightly easier to enforce.
While I am aware that this is the reality, I find the attitude underlying this reality rather unfortunate.
As an interviewer assessing a candidate, I would like to believe that I'm thoughtful enough to see that corporations lay people off for any number reasons. The macro-scale conditions at Microsoft likely have no bearing on the candidate's quality.
Imagine if the candidate were from RIM. We'd hardly question the reality that RIM has to lay off people, many of whom are competent.
In the US this doesn't make sense (for most people), unfortunately.
Employers offer group plans which tend to be much cheaper and offer substantially better benefits than individual plans. The larger the company, the better the arrangement tends to be.
COBRA is designed to fill in that coverage gap when you leave, but as others have noted in this thread, it is not always economical.
The SA-11 'Buk' TELAR (9A310M1) was indeed designed to be used as part of a broader system including C&C, dedicated launchers, and the 9S18M1 radar. It certainly requires trained personnel to operate.
With that said, the Buk was also designed to surpass its predecessor('Kub') by incorporating a fire control radar into each launcher (TELAR vs TEL), so that it could operate with some autonomy. The original idea was to allow the whole SAM network to track multiple targets independent of the 9S18M1 radar, which would focus on detection and delegation.
This capability also enables an autonomous TELAR unit (as the various images and videos are showing) to target an aircraft at a range of 3-32km, much as people are hypothesizing happened to MH17. It is plausible, although far from certain.
When you say that national intelligence communities are secretive, you're absolutely right. So much so that they would certainly not share any sort of information with commercial/multinational airlines. It sounds ridiculous, given that lives are at stake, but it is important to consider their calculus (taking the US intel perspective for a moment):
Knowledge that rebels had active radar-guided SAMs would be derived from a handful of classified assets, from satellite to radar to drone to people. Adversaries to the US are meant to be unaware of these modalities (to prevent countermeasures), but you can bet they are all in use.
The challenge is that disclosure of any facts gleaned from classified systems potentially reveals their capabilities.
Now disclosure is a continuous spectrum, from "there is a threat" to "here is a multispectral image of a launcher", so perhaps there is some shareable information. In considering that, you weigh the utility (external risk) of the information shared against its credibility (details), and the potential loss of capability incurred by disclosure. When we say "loss of capability", in this case it may mean disclosing the capability to detect missile launches early, which represents a critical piece of US missile defense.
For a historical case study in this type of calculus, it's worth looking into the disclosure of images during the Cuban Missile crisis. There, the US had to provide credible information that there was a threat in Cuba, and did so at the cost of the revelation of U-2 images.
By the way, this same calculus played into the US President's wording when he spoke yesterday about the tragedy. Obama was careful to say little about how they knew where the missile came from.
Unfortunately, from the perspective of an intelligence agency, NDAs are insufficient to protect classified assets, especially where multinationals are involved. Anything that is disclosed would go through several levels of indirection, and would probably end up in a NOTAM (like the one prohibiting flight under FL320 in the region).
AWS definitely dogfoods, to the point where people have to be careful internally to not create circular dependencies (this nearly happened to me once).
I think there's a notion of persistence in AWS' leadership that propagates through the teams. AWS is willing to fight through the early painful years for products to see them arrive at the stage that EC2/S3 have attained.
Webhooks would address this challenge for a certain class of applications (those with their own server component), but if you imagine building a solid desktop email app (APNS/GCM not used), then you have a problem.
I'm glad they're thinking about it, though!
Maybe I'm missing something, but:
Flipping through the documentation, the RESTful API seems to only allow for polling for new messages (deltas via the sync protocol[1]).
While I'm glad that there is a delta-API, I'm concerned that this doesn't support proper "push" notifications for new messages. This is a valuable feature of Exchange and IMAP[-IDLE](where supported).
I understand that the heterogeneity of these push protocols makes it difficult to expose a push API, but it seems an important feature of mail clients.
Similarly, it seems that REST is not quite the best protocol for the "push" piece of modern email. I suppose long-polling support on the Sync API would work fine, however.
I filed a patent at age 16; there are no laws governing how old you must be to file, and rightfully so.
While you may stereotype young people as being unready to write and file patents--and perhaps many are--at least some have developed the right skills and technical knowledge to do so.
Judge the patents on their own merits, not their authors.
Excellent product; I've used ExpanDrive in the past and it works remarkably well.
Curious--any chance you can put together support for OneDrive for Business? Microsoft currently lacks a proper client for that service on the Mac, and it's a minor pain.
I imagine there's a bit of a selection bias based on the group of selectors; if you are exposed primarily to software, it is easier to comfortably judge software applicants than biologists, for example.
Based on previous years, it would likely be difficult to make the comparison with Harvard/MIT (or similar), given a good number of the fellows spent time at either of those institutions. Those who did have had access to the resources of both circles.
As I understand it, TF tries to pick good people even if they are working on not-so-bulletproof projects at the moment. That's likely the justification here.
Keep in mind that the funding is a grant (rather than equity/royalty/loan) and is not given to the project but the individual.
You want the serving pc to have hardware accelerated video encoding (e.g. Intel Quick Sync), otherwise it runs terribly. Similarly, the client should have hardware accelerated decode, but that is very common.
While it is true that the SR-71 & A-12 were spy planes, and that the GP makes a slightly asinine statement, the pedant (and aviation geek) in me feels obliged to point to the YF-12[1].
The YF-12 was a twin-seater derivative of the A-12 that was developed as a fighter aircraft, complete with a look-down/shoot-down radar and missile bays.
The F-12 never made it to production, but a small number high-speed of weapons tests were conducted with the 3 YF-12 airframes that were built.
With that said, the MiG-25 should certainly not be belittled as a marvel of aviation. It was a blisteringly fast interceptor and reconnaissance aircraft, with an impressive radar system for its time. It filled a special role in the Russian Air Force until last year[2].
[1] http://en.wikipedia.org/wiki/Lockheed_YF-12 [2] https://medium.com/war-is-boring/21d12739b5db
There is an entire mechanism for this, from consenting individuals in early stage trials to accelerated approvals. If you're curious, checkout the FDA's programs (http://www.fda.gov/forconsumers/byaudience/forpatientadvocat...). This isn't everything, but it represents the interest of most players in getting these medications to patients as quickly as possible.
While you may be right that there exists a price point at which posh people will pay for this type of delivery service, the example of Tartine is a poor one.
Tartine has been regarded as one of the best bakeries in SF for a number of years, having cultivated its reputation and following for over 10 years. It commands high prices not just because of quality, but also by its brand.
This is relevant not merely to pick apart your example, but more as a sort of chicken-and-egg challenge that faces many food service businesses. By default, bakeries are a low margin businesses, making it difficult to survive the long years you need to build the reputation that enables higher margins. The businesses that have circumvented this struggle have done so by such means as owner/chef fame.
With that said, I'm confident there are other ways of quickly achieving high-margin status. OP's company will have to be clever in doing so. It's unclear to me that delivery is a sufficient vehicle in this respect, except in bulk where ACME dominates.
Thank you for reading and citing the law in detail. For those who haven't read it[1], I'd encourage you to do so. Unfortunately, the author of the blog post is reading it rather selectively and linking to another report.
Reading through the law, it seems largely sensible. The council lays out its logic for which pieces of the operations of a service like Uber need to be regulated, and specifies appropriate regulatory action on each item. We're talking about aspects like "transparency of rates", "certificates of safety" from mechanics, allowances for handicapped people, and insurance.
In fact, the council lays out a pilot program to assess whether such regulatory action is actually effective, "so that regulation provides a safety net that the public can rely on for its protection while new businesses innovate and use technology to better the lives of Washingtonians." The balance between "innovative" interests and those of consumers is clearly being weighed, and the council will assess "any negative unintended consequences of the pilot program" by next year.
Attacking the caps ignores the fact that they are associated primarily with the pilot program and initial regulation. You can think of it as a form of risk management for a trial, not dissimilar from that exercised in a medical drug trial.
[1] http://clerk.seattle.gov/~scripts/nph-brs.exe?s1=&s3=118036&...
Much of the information coming from the Malaysian officials tasked with communication is confused or inaccurate. Naturally it's unclear whether this is a case of "right hand not talking to the left" or broader incompetence, but I think you're right to be conservative in building hypotheses atop this information.