minznerjosh

I came away with a different read of this article. The article says the head of China’s Ministry of State Security sees AI as a threat to the CCP, specifically calling out deepfakes of party officials, cyberattacks on infrastructure, etc. He’s not calling it an existential risk to humanity.

The article then states this official accused U.S. companies of “hyping the dangers of the technology.”

So I don’t see how this article shows the U.S. and China seeing the same thing.

Yup. ChatGPT did not have proper MCP support until now. They only supported MCP for connecting Deep Research to additional data sources, and for that, your MCP server had to implement two specific tools that Deep Research is able to call.

What’s being released here is really just proper MCP support in ChatGPT (like Claude has had for ages now) though their instructions regarding needing to specific about which tools to use make me wonder how effective it will be compared to Claude. I assume it’s hidden behind “Developer Mode” to discourage the average ChatGPT user from using it given the risks around giving an LLM read/write access to potentially sensitive data.

I find it odd you included potatoes in the list of foods to give up. Boiled potatoes in particular rank at the very top of the satiety index[1], meaning they keep you full longer with less calories than other food (likely due to a combo of high water and fiber content.) I recently lost a modest 10 lbs and mashed potatoes (even with some added butter and milk) were a staple of my diet—keeping me from feeling hungry even at a calorie deficit.

[1] https://pubmed.ncbi.nlm.nih.gov/7498104/

Are you planning to offer a search API at some point?

This hits the nail on the head. Abandoning time zones would only make sense if there were no more need for time translation. But you'd still need to translate for the sake of biological clocks, and without time zones it would become more challenging to communicate that translation.

I would be in favor of doing away with DST and also eschewing AM/PM in favor of a 24-hour clock. I'm surprised this article didn't mention that.

npmjs.com seems to be down as well.

Just some feedback on the site:

The images/iconography appear to be @1x resolution, making things appear blurry on my MacBook Pro with Retina Display. I'm guessing it would be the same on my iPhone or iPad.

I don't know if I'd say Scopes are controllers after the controllers are instantiated. Scopes are more of a view-model which are, yes, annotated by Controllers.

However, if you put your Controllers on the Scope (via $scope.MyCtrl = this; in the constructor, or via the controllerAs syntax), your controllers are your controllers, placed on the view-model (the scope.)

But this is really just semantics at this point. I totally get what you're saying.

.factory('$timeout', function($window) {

  var $timeout = $window.setTimeout;


  return $timeout;

})

.service('$timeout', function($window) {

  // $timeout is a function, not an normal object. Why would I use a constructor
  //function to provide it?

});

That can be a matter of personal preference, so the best I can do is share my preference.

I usually use the "service" method because most of my services are objects, and I have no aversion to constructor functions.

However, if I want my service to be a function (a la $http or $timeout,) I'll use a factory (because I don't want a constructor to be new-ed, I just want to create a function.)

And, as the article states, I'd use a provider if I want to provide methods to configure my service before it is instantiated.

I think a lot of it comes down to semantics. Maybe it's just me, but describing my object via a constructor function (as a "service") makes it feel a bit weightier than creating and returning a POJO in a factory. But, from a practical standpoint, you can see it as this:

A provider is responsible for creating (providing) an injectable (as a singleton) object that others can request to be injected. The provider creates this object in its $get method. It can also have methods/properties other than $get that can be called/modified in the config stage to configure the object it will create.

But, often times (maybe the majority of times,) you don't need to configure your injectable before it is created, so we really only care about the $get method of the provider. This is where the "factory" API comes in. It just eliminates all the boilerplate around creating a provider that only has a $get method.

And finally, for reasons that are not entirely clear to me, the angular team also decided to provide a shorthand for creating a constructor, and returning a new instance of that constructor in the $get method of the provider (or the factory function if you like.) And that's what the "service" API is.

So, the provider is the root API, factory is sugar on top of the provider API, and service is sugar on top of factory API.

Really, Services and Factories are just a shorthand way of creating providers.

.factory('foo', function() {

  var foo = {};


  return foo;

});

is the same as:

.provider('foo', function() {

  this.$get = function() {

    var foo = {};


    return foo;

  };

});

And,

.service('foo', function() {

  this.bar = 'bar';

});

is the same as:

.factory('foo', function() {

  function Foo() {

    this.bar = 'bar';

  }


  return new Foo();

});

is the same as:

.provider('foo', function() {

  this.$get = function() {

    function Foo() {

      this.bar = 'bar';

    }


    return new Foo();

  }

});

As somebody who has built actual applications with both Ember and Angular, I think this article totally hits the nail right on the head.

Though, in regards to the "Angular is backed by Google" comment, while they don't actually "back Ember" in the same way Google "backs Angular", it seems that a ton of large companies are also invested in Ember (http://emberjs.com/ember-users/)!

And, I know the Ember folks are really proud of the community they've built as well. I theorize that Ember's lack of a single corporate backer is what has enabled its incredible community to flourish.

I think that one of the most important features of $timout is that it runs a digest cycle after the timeout completes. That's why bindings get updated when you modify data in a $timout callback. So it is related to dirty checking.