clarkbw

We'll be revising our free storage model in the future to accommodate more open source usage. There are a lot of base layer images people use that are built on GitHub and should be freely available. Those base images should become part of the public space and you only pay for private storage built on top.

Apologies for that. :(

I hope you'll give this a try. GHCR is based off an all new code stack. You'll notice that now you need to associate Containers and the repositories they come from instead of publishing "into repositories". Our new model has packages / containers published into orgs which will make other services simpler as elevate them as well.

We (the GitHub Packages team where I work) are working on a fix for this and a number of issues with the current docker service. You can join the beta too, details here https://github.com/containerd/containerd/issues/3291#issueco...

x-linking to insights discussion https://news.ycombinator.com/item?id=23092966

Codespaces discussion happening over here https://news.ycombinator.com/item?id=23092904

Yes, we (internally) call this a "Bill of Health" and believe that all packages should have this kind of diff-able information available. Understanding what's happening at the source level is key to being able to trust any package published.

Yes thank you! We believe namespaces are a good thing and will continue to promote it as best practice.

Hopefully we can integrate repository information to packages meta data such that you could be aware of a change of ownership even for a globally namespaced package.

The post covers this.

> Later this year, we will enable npm’s paying customers to move their private npm packages to GitHub Packages—allowing npm to exclusively focus on being a great public registry for JavaScript.

Packages will continue to develop its npm registry. We have a lot of work to do in securing the software supply chain.

Part of GitHub (I work at GitHub and lead the Packages team)

Private repos aren't scanned and if we did offer the service to scan private repos we would only ever contact the repo owners and not the service providers. In the case of public repos we're in a race against time where bad actors are scraping the site and have automation created to use your tokens within seconds of a leak. Private repos scenarios are much simpler to deal with.

We use this at GitHub to power the commit token scanning. It is very fast and handles multiple regexes at once. We are looking for secrets from multiple providers. Couldn’t find a better option for this type of usage.

Sorry you've been fighting this. We're actively working on the documentation as well as improving the setup workflows for Actions which should alleviate lots of this pain.

Those one line snippets are likely going to be taken down, most systems are too complicated for those to work. It looks nice for a couple package systems but that Maven one is obviously flawed.

I'd be happy to help you dig through whatever you're trying to do; I'm @clarkbw on twitter. I'd also love another set of eyes on the changes to the setup-java action, specifically getting Maven authentication to work well.

https://github.com/actions/setup-java/pull/29

(I'm the PM heading up the Packages project at GitHub)

There are a couple of other attributes that can be useful from Linguist.

The vendored can help maintain your language stats which show up on your repo page and in GH/explore.

For rails you could add something like this so all the JS you've imported isn't counted.

``` vendor/* linguist-vendored ```

- author

There goes any hope of the HomeKit support promise coming through in the Ring Pro.

The linked article about the problems with battery storage is from 2011 and battery technology continues to change at a rapid pace that couldn’t have been predicted then. The article uses lead acid as the example of cheapest batteries that still can’t scale but science wasn’t looking to solve that st the time. I’ve see several new battery options built from simpler and more available materials. Assuming storage is viable the arguments against solar and wind don’t hold as much weight.

A switcher is under consideration but we're focused on some other (what we believe are) more important aspects right now and wanted to get this part out the door quickly for people to start using.

I wouldn't consider a switcher implementation details as much as another user flow.

Since you bring it up I wonder how often users find that switcher and "do the right thing" in GitLab. I would expect that number is pretty low and instead users submit with the template they arrived on. As in I would assume the feature is likely useful for advanced users to more easily switch (certainly good there) but I'm skeptical that new users would look to use this. What do you think?

You can leave the last S for off (for savings) if you want /ISSUE_TEMPLATE(S)/ or /PULL_REQUEST_TEMPLATE(S)/

As Firefox moves to WebExtensions all these debugging tools should become just as available. Currently it is difficult for extension authors to support Firefox as well but that is changing.

React DevTools is about to convert. Redux already has a working WebExtension. We are working with Angular Augury right now. VueJS should also be coming to Firefox soon.

I'm making a list and checking it twice: https://twitter.com/clarkbw/status/870609788366934016

This is going to get a whole lot better. Try nightly now to see what's coming.

Thanks for all your hard work! If you want to check out the new model of development take a look at the debugger, its the first in series of new panels coming to Firefox. https://github.com/devtools-html/debugger.html

> As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.

That percentage is actually pretty close to correct. For that reason and user studies of regular users Edge has already turned off their DevTools by default ( https://blogs.windows.com/msedgedev/2016/11/22/balancing-use... ).

Firefox is currently pursuing moving the DevTools out of the browser and will likely use a similar system to Edge / Safari for activating them. Going the extension route does have complexity drawbacks but being able to ship fixes faster, to a wider audience will be a greater benefit. Additionally as all browsers adopt WebExtensions this could mean that any Firefox panel developed as a WebExtension will be available for use within Chrome or Edge.

Yes, in 2017 we'll be shipping DevTools outside of Firefox. At first it will probably be an add-on and we'll evolve from there. But it should mean less time between features and fixes and deliver to developers.

Developer Edition enables a number of features not currently available for regular Firefox. The two major ones are build time features which can't be enabled in other releases (besides Nightly). One build feature is Unsigned Add-ons, which allows for add-on development where it isn't possible otherwise. The other is Async JavaScript callstacks which are very useful to capture but tend to slow down regular browsing otherwise. Besides build features there a lot of prefs we turn on to make development easier. If you try using Chrome or Firefox release with DevTools you will need to do something extra to be able to "paste into the console" (something that prevents people on facebook from owning themselves) and that guard isn't on by default in Developer Edition. [I'm the Product Manger for Firefox DevTools]

To be honest, it feels like you didn't actually look at the link.

This is only for development of the debugger itself and shouldn't be used for a production release. Within Firefox there is no node process it is run purely as a web application.

That's James Long, lead engineer for the project. He gives a great demo of the debugger.html integration with Emacs. :)

The debugger landed in Nightly today, its not quite ready for prime time yet but on by default and getting updated regularly. https://nightly.mozilla.org/

The Firefox DevTools team is moving away from XUL, so the .html suffix is a wink to moving to HTML.

As of a couple of weeks ago this has patches and momentum to finally be integrated into Firefox.

Firefox add-ons that use the XUL overlay system would need to be written as SDK style add-ons.