I wonder if you could more easily verify past gems with something like:
git checkout <tag>
Will that work or would a version difference in the local version of rubygems used to build the gem cause checksum differences?
Every time I try to like Safari I find myself going back to Chrome or Firefox. What advantages over these browsers does Safari bring to the table that make switching worthwhile?
Battery Life is noticeably better than Chrome and FFX.
Integration of bookmarks, history, etc with Mobile Safari
It doesn’t record mic audio and stream it to google.
My favorite feature is iCloud Keychain, which makes it ridiculously easy to generate & secure passwords across my iPad/iPhone/Macbook.
Firefox doesn’t do that either, but I did say FF or Chrome :)
Not sure, as I use Safari by default. However, I do use Chrome if I need to use Google Calendar / hangouts. I also use Chrome for Scratch, because of its built-in and self-updating Flash support. (I don’t otherwise have Flash installed.)
That’s part of my issue. I used Chrome for a long time because I need multiple G+ accounts logged in at the same time. I decided that supporting OSS was important so I switched to Firefox and now use multiple profiles for this - it’s not elegant but it works.
There’s always Chromium, the upstream OSS project.
If you want to backdoor node apps, there are now plenty of available, established package names you could recreate that people already depend on. Enjoy!
This was not a possibility, actually. Furthermore, all of the packages in question have new maintainers that are being monitored very, very closely.
Do you need explicit permission to reclaim the previously used name? I didn’t gather that from the post or tweet which made it seem like you could adopt the name without intervention.
But I probably should have checked that rather than my “ready, fire, aim” approach above.
I don’t believe that you did, no. But you did need npm’s help in order to publish old versions of the package, so the new maintainers could have only made new versions.
Well, that’s still a problem then, since most people are using the caret syntax in their package.json, right?
Most of the packages seem to have been claimed by this unknown actor, who appears to have bumped the version number on every single package.
I think there’s some subtitles around the karat and 0.0.z versions in this specific case, but generally, you’re right, I think.
who appears to have bumped the version number on every single package.
Yeah, that’s the only way to get it to show up that way, you have to publish a new version so the new metadata is applied.
It seems the lack of a (default) lockfile makes this worse.
This is clearly targeted at companies and it’s a point I’ve tried to make several times with many people and failed.
“DNSimple has ALIAS”, they say. They don’t care that it’s non-standard and locks you in. They cared for a little bit a while back when DNSimple was down due to a DDoS, but they’ve now moved on. Oh well.
This is why you should design DB-out and not application-in.
I wrote the article so I obviously appreciate the value of database level constraints over or in addition to application level constructs, but I’d still classify my preferred design as “application-in”.
While developing features I’m constantly thinking about schema, but I try not to jump directly to it. However, when it’s time to write some migrations I try to be much more forward thinking than “what does the app need right now”, specifically in regards to constraints or obvious performance issues.