You can take a fresh install of MacOSX and do anything with Ruby. Only issue is you need to install some gems using sudo. Same thing with using system python. You don't need rbenv by any means. In fact our designer has no problem getting our rails site running and making styling edits.
Hard to say the same with installing Python 3 on MacOSX and getting virtualenv running, which in my experience hasn't been so easy.
How would you work on a project that uses 3.2, then another that uses the latest features from 3.5, without pyenv?
I have a tendency to install one of python 2.x and one of python 3.x and then use the --python flag to set the particular python I want my project to run against.
At that point it should work invisibly in the virtualenv.
Unlike ruby, point releases don't often make sweeping breaking changes so it is often enough to say 'this is python 3 code' or 'this is python 2 > 2.5' code, so the granularity of something like pyenv is mostly unnecessary, imo.
I seem to have all of Python 2.7, 3.2, 3.3, and 3.5 installed on my server just from APT. I happen to only use 2.7, but I certainly don't see what use I would have for some crazy tool to manage versions of Python for me... if the project needs Python exactly 3.2 for some specific reason I can just run python3.2 instead of python3.5 or python3.
If you work on multiple Django or Flask projects you'll quickly learn APT can start solving your problems but it won't be the best way to do it.
With virtualenv each project of mine has a requirements file (I use it even for Google App Engine development, having a distinct SDK per project) and runs Python from a different environment where the packages I install with pip do not interfere with any other environment. Without it an "apt-get upgrade" can end up breaking everything (to say nothing about not having the latest version packaged).
Disclaimer: I work for Mozilla, I maintain django-browserid (and StravosK is a valued contributor <3), and I have implemented Persona on many sites. This is all just my own personal opinion.
I was very bullish on Persona early on, but the fact of the matter is, we failed. And not just because (as I feel is being implied) some higher up suddenly came over and asked for an unreasonable amount of adoption for a revolutionary product.
We failed for a thousand reasons. It should've been supported directly within the Firefox chrome ASAP. It had branding different than the site you logged in to and was in a popup. It took the name of another Firefox feature that users already knew about. Because the team was experimenting fast, the code quality of the service was such that outside contribution to it (or even cross-team contribution internally) was hard to impossible. There was no (or very limited) metadata available for things like a shared avatar or display name.
We had enough time to do these things, but we didn't. The team accomplished something really amazing, but it wasn't enough, and most importantly, putting more effort into what already existed was not going to work. This idea that Mozilla can just turn around and throw effort at Persona and make it win now is, IMO, wrong.
Identity needs more experimentation, that much is certain. But harping bringing back Persona in particular is beating a dead horse. We need a successor or a new project.
 Not only did this make Persona look incredibly sketchy without a lot of priming users, it had a major privacy issue of leaking your identity provider and relying party to Mozilla via a centralized iframe we host. A mailing list thread among the Persona devs and community failed to find a solution to this.
To me, Persona never _shipped_. They still discourage self-hosting the identity verification code, so even on a happy path where the user somehow managed to get an email provider that natively supported Persona you still had to talk to Mozilla servers. That's not federated identity, it's centralized; it offers nothing above Facebook Connect.
Would doing that alone have made Persona a success? Probably not. But as it is, it's not even in the running.
(Context: I wrote my own IdP, so in theory I could have been on that happy path.)
I agree with you on most of this. And yes, a "Persona 2.0" should really just take the Persona lessons and learn from them, avoid the mistakes.
That's also why I mentioned in my other reply that I'd be willing to help a project that has a chance to succeed - and that means being lead by someone who has themselves learned all the lessons from Persona. Someone who was on the original dev team.
But this also needs backing from Mozilla, or a corporation like mozilla (there aren't many).
While a lot of devs, including Mozilla devs, agree that Persona needs a successor... there's no sign of any such backing.
> It should've been supported directly within the Firefox chrome ASAP.
That could have been fixed, and could still be fixed.
> It had branding different than the site you logged in to and was in a popup.
That could have been fixed, and could still be fixed.
> It took the name of another Firefox feature that users already knew about.
That could have been fixed, and could still be fixed really, but it's pointless now.
> Because the team was experimenting fast, the code quality of the service was such that outside contribution to it (or even cross-team contribution internally) was hard to impossible.
That could have been fixed, and could still be fixed.
> We had enough time to do these things, but we didn't. The team accomplished something really amazing, but it wasn't enough, and most importantly, putting more effort into what already existed was not going to work. This idea that Mozilla can just turn around and throw effort at Persona and make it win now is, IMO, wrong.
Why wouldn't it make it work? Persona was only alive for 2 years. It saw slow adoption, in part due to usability issues. If you fix the usability issues and give it more time, why wouldn't it be more successful? The issues holding it back were not fundamental. In fact, the fundamental design of Persona was sound and worked very well.
Now, yes, merely fixing things and making the project supported again won't make it more successful overnight. It may need rebranding, it may need a lot of promotion, strategic partnerships, etc. But to declare it completely dead and waste effort on recreating what you already have is silly and counterproductive.
Persona already has many sites - and people! - using it. It already has some (limited) brand recognition. It already has a solid protocol and design, a working codebase, a hosted service that is usable.
The hypothetical successor to Persona? It has none of this. A hypothetical new approach? It has none of this. Could that change? Sure, but you're still starting from zero, and you have to re-do everything.
But why start again when what you had wasn't fundamentally broken?
> We need a successor or a new project.
Why? What could a successor or new project bring that Persona couldn't?
Well, yeah, but Persona/BrowserID didn't fail, YOU (Mozilla) failed. BrowerID was the right concept, and it was insanely stupid to create a different frontend branding, to not build the browser integration, to not explain anything well, and then to describe the project as a failure when it hadn't even been implemented at all on your side.
The only thing that has a chance of happening is some external party coming up with a different protocol or extending the existing one, and gaining traction as an identity provider. Then, like we did with Pocket and "Save for Later", it's not unreasonable to think that Firefox would accept a system add-on that is compatible with this protocol to ship an in-browser UI.
"gaining traction as an identity provider" being the hard part, of course.
Frankly, the name was the worst of it It took some effort to kill the UI-theming Persona with fire (and there were very good reasons to do so); anything that even hinted at the possibility that you'd have to resurrect that in order to do something that looked useful wasn't going to fly unless there was a lot of forgetting time in between uses. Yer average user doesn't monitor tech news sites in order to determine whether or not a product of the same name from the same outfit is really something completely different.
>it had a major privacy issue of leaking your identity provider and relying party to Mozilla via a centralized iframe we host. A mailing list thread among the Persona devs and community failed to find a solution to this.
Basically, Persona by design needs to transmit a keypair and a signed certificate between the identity provider and the relying party. Without in-browser integration, the way this was done was using localStorage on the login.persona.org domain, making Mozilla a trusted third party. This was deemed okay as a temporary measure until in-browser support for BrowserID became commonplace, replacing the trusted third party with the user-agent.
Reading the thread again, my memory was a little off: possible solutions were proposed, but the conversation fell off before consensus could be reached, and no one had the time to drive any attempt to implement the change.
It's also quite hard to file a bug. I did just that the other day, didn't want to make an account tried to use my github account, failed at that eventually did make an account. It's a pretty annoying bar to have to create an account with some system just to report a bug (which one should be able to do even anonymously). I understand you're trying your very best and work extremely hard but these little details all taken together add up to a fragmented and inconsistent picture which is something I really find a pity because Mozilla is an absolutely excellent product from a group of extremely capable people.
Really sorry about that -- there was a snag in the case when someone has multiple github emails and no bugzilla account.
It was fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1223590 and that should be going live this week (last weak was a rarity, no code push).
As far as I know, people working on bugzilla have github based login on their radar. Don't ask me for a roadmap though, but people hanging out in #bmo on irc.mozilla.org should be able to fill in details.
Fully anonymous login is an open door to way more spam that we want to handle ;)
Ah, that is exactly the case, I have one for 'business' and one for 'private' stuff. Thank you for the clarification, it was quite a confusing situation because you ended up in an endless merry-go-round.
From years watching and occasionally contributing a tiny bit to Mozilla, I got that sense.
I understand that creating and maintaining technical documentation takes more resources than most people assume, but there are compromise solutions ...
> it's not like Mozilla itself decided that fmarier's blog was the best place to put this, he just posted it because it's his blog and he's a smart person.
... instead of posting such things to personal blogs, where few people can discover them, how about just posting the exact same things to a central wiki? For the same amount of work by the authors, they would be far more discoverable by people who need the information; the authors would reach a much wider audience. Wiki updates could publish in Planet Mozilla. (I'd make the wiki editable only by Mozilla employees, to reduce the burden on authors who might not want to get into debates with the world over what they post.)
It may not be authoritative documentation, but it would be far better than what's available now and at little additional cost. You can make clear to readers that it's ad hoc documentation (e.g., call it the Beta Wiki, put a notice at the top of each page, etc.), and at the top of each page post the date the page was last revised in a way that nobody will overlook.
Right now you are wasting a lot of great knowledge by hiding it where nobody will discover it; it's like developing great features but hiding them in the interface where nobody will find them.
> Firefox is so friggin' big ...
It is, but to be fair there are many comparable or larger software projects out there where detailed technical documentation is more discoverable. Windows comes to mind.
All easier said than done. Good luck to you guys; you do great work.
One thing to keep in mind is that even if we can't use Gecko on iOS, having _something_ on iOS rather than nothing means that people who use Firefox on Desktop or other platforms will be less likely to switch away due to issues like their bookmarks / tabs / etc not syncing between devices.
It's an indirect way of getting more people to use Firefox (which promotes standards) over another option, but it's certainly better than telling iOS users "If you want synced stuff, switch to Chrome or Safari."
I agree with you. I think it's really interesting to think about what a "browser" or "user agent" really is. It's clearly more than just rendering, it's things like bookmarks/syncing/plugins/etc. I just worry that if Mozilla doesn't figure out their mobile-first strategy, having will Firefox on iOS will only serve to slow the bleeding, not really help with getting back to growth.
It's a pretty simplistic view of things, Chrome on iOS isn't that great, even if you use Chrome on all other devices the account sync and all the other Google features might not be worth the performance issues compared to Safari.
FF Account Sync isn't as robust as Google's (not saying it's bad, it's not intended to be as universal and or invasive) so you will get for the most part even less out of it.
FF on Android is a true FF build, you can run most addons on it and it uses Gecko as their rendering engine.
The problem with iOS is that we are going back to a single eco-system when it comes to rendering engines this means that everyone needs to get inline with how Apple thinks that the web should work which we had to suffer through before when Microsoft polluted the web with their own interpretations and "proprietary" standards.
Also from a security POV this is pretty damn awful if there is a vulnerability in WebKit/iOS Webview or however Apple wants to call it, there's a good chance that every browser will be vulnerable this means that until Apple can patch it out there is no alternative non-vulnerable browser for the iOS ecosystem.
This pretty much reminds me of the late 90's early 2000's where there were a billion "alternative" browsers like NeoBrowser and the like that were nothing more than a reskin of Internet Explorer, the fact that you can't push out your own low-level components to one of the most popular mobile platforms in the western world is pretty god damn sad.
I for one would have actually loved it if Mozilla and Google would've make a stand against Apple and say if you don't allow us to build our browsers like we want too we're not going to be on your system. But sadly because Apple users are the more "important" (as they have more money to spend) than alternative platforms it doesn't seem likely to happen.
Adblock Edge was discontinued a little while back but had effectively replaced the not-fully-blocking Adblock Plus of recent months. ABE's UI integration broke in another recent FF update, but the blocking itself continued to work usefully until FF42, at which point apparently it ceased doing anything useful at all.
uBlock Origin is apparently now the blessed alternative and is OK for blocking most ads, but I immediately found a few potential tracking issues with its default lists, and its UI is awful.
Ghostery also isn't blocking various trackers effectively now, even though its UI still claims it has detected and blocked them. I can't 100% guarantee that's FF42 if Ghostery also updated its lists at almost exactly the same time, but that's when I saw things like Facebook Connect start hitting FB servers even though it's supposedly blocked.
This is almost a brand new machine, BTW, which just happened to update FF and lead to changes in the plug-ins a few days after initial set-up. There's relatively little chance of odd things going on or historical baggage distorting these results.
Bottom line: The day I bought the machine and installed FF and my usual set up add-ons, my browsing experience was fine, and then a few days later FF updated to 42, and my browsing experience immediately sucked.
> I immediately found a few potential tracking issues with its default lists
I am curious: what are these "few potential tracking issues" specifically?
Whatever default lists uBO is using, unlike with ABE (which is essentially ABP filtering engine), users have the last words in what is blocked:
- The `important` filter option can be used to override exception filters.
- Dynamic filtering override all static filters. For example, you do not need a special filter list to block Facebook everywhere, it's a matter of a few point-and-click to block it everywhere without any way for any static filter to counter it.
Some specific examples I've noticed on the privacy side are pinging a Facebook server when a page uses Facebook Connect, and allowing the various web font services.
It's certainly possible to customise uBlock Origin to prevent these things. However, I couldn't immediately see any of the other suggested lists that would have blocked some of these potential privacy/tracking issues either, which suggests that not only do I need to manually block them if I want to stop the tracking, I also need to manually update those lists.
In contrast, with a couple of fire-and-forget plug-ins I've been installing as standard for years until recent FF updates broke them, I very rarely had to customise anything manually. They just worked as standard, and I trusted them to keep working and never noticed any significant problems, until now.
Fanboy's Anti-ThirdpartySocial is right there in the list of lists, under the Social header.
And it doesn't block any of the things I mentioned. The domain connect.facebook.com isn't in there, for example, and I ran into a page running a script from there within five minutes of switching to the new plug-ins.
Ok, my answer was meant to address your point that uBO was no replacement for ABE
Sorry, I'm not sure where I said anything like that. I explicitly noted that uBO was apparently being promoted as the successor to ABE, as you seem to have noticed. I just also noted that the plug-ins I've got running now aren't as good in some respects as the ones that worked just fine for a long time until recent FF changes.
Yes, you're right, apologies to you and to 'gorhill.
I misunderstood before and at the time I read "Fanboy's Anti-ThirdpartySocial" as "Fanboy’s Social Blocking List" not "Anti-ThirdpartySocial (see warning inside list)", perhaps because the latter sometimes seems to change its name to "Anti-Facebook List" for reasons I haven't identified. The former does block numerous Facebook addresses, just not that one.
I'm not sure any of this really invalidates my original point, though. Two weeks ago my Firefox had a couple of privacy/blocker extensions installed, and with no real configuration beyond ticking the "everything" boxes in the Ghostery wizard, they blocked pretty much everything that bothered me. Today, with FF42, neither of them works any more.
Apparently the new version involves figuring out which of the almost 50 lists that are suggested but not active by default in uBlock Origin are needed to get a reasonable level of blocking. I dare say almost no-one is actually going to get that right reliably even if they want to. And while I might have guessed to just activate everything under the social heading to block Facebook Connect (at least if I'd realised something related to Facebook wasn't already blocked by default), I have no idea which of those lists to even check to see if I can disable the various web font resources that involve tracking.
> Adblock Edge was discontinued a little while back [...] uBlock Origin is apparently now the blessed alternative [...] but I immediately found a few potential tracking issues with its default lists [...]
"but", implying Adblock Edge somehow did not have the "few potential tracking issues" you said you found in uBO.
You're reading things into my posts that aren't there. Please note that the context for my original comment that you selectively quoted was the add-ons (plural) I had used before. My full comment on uBO was that it was OK for blocking most ads but didn't block some of the trackers. The next part of the comment was about Ghostery, which was what did previously block (but no longer appears to block) those trackers.
I once worked on a website that analyzed Python code in order to index it into elasticsearch for structural search queries (things like "find me all classes that inherit from SomeBaseClass"). Python's built-in ast library outputs a tree for you to traverse, and even with their provided tree walker you still deal with the internals of the tree and recursion.
Furthermore, part of our indexing needed to follow imports to find the canonical name of a value, which is a problem very well suited to a recursive solution.
You may not have encountered these situations where recursion and trees have to be dealt with, but they absolutely exist.
There's valid criticisms against WebExtensions, but the biggest misconception is that the capabilities of WebExtensions are set in stone and that X or Y addon "won't be possible". The entire point of announcing WebExtensions so early was to start getting feedback on what needs to be supported to make major and useful addons possible, and to start work on a way for experimentation outside of the officially supported spec to still happen.
> The entire point of announcing WebExtensions so early...
Their current schedule only gives a year to build an api, mature the api, get a significant number of popular ported addons, and deprecate their old api. There will either be mature apis and many casualties, or half-conceived apis and lots of addons that will need to be changed with these apis.
With enough time and design, I'm sure this move would result in many positives at the cost of some negatives. But this time frame is just too short for such a huge undertaking.
I agree that the timeline is rather short. I think it's totally possible for the Firefox team to achieve their goals within that time period, but whether addon authors can keep up is not as clear to me. We'll just have to see how it goes; I don't see why they couldn't extend the timeline if it turns out to be too short.
It really depends how many resources mozilla puts on this internally, which from what I've been reading may actually be quite a bit. But I don't think they'd move the schedule any more than a few releases, there will likely be a whole bunch of addons ported at the last minute, and they likely need the motivation.
On one hand, that link provides pretty strong (implicit) evidence that plenty of stuff won't be possible after the switch away from XUL, whether or not Tree Style Tabs is possible.
On the other hand, Tree Style Tabs is far and away the biggest extension I care about, so that link does provide me with some level of hope. For which I genuinely thank you.
On the third hand, my cynical take is that apparently Mozilla really does take community feedback into consideration. When making a wish list of things that could potentially happen in the future to put on a wiki page. I've also heard that it's possible that Pocket could be moved to an extension.
To me it seems like a decent way to say "Hey, here's an explicitly unstable way to do things that aren't possible with WebExtensions, and hopefully we can eventually get those things into WebExtensions, or you can just live your life as you do now with no hard promises about compatibility."
> On the other hand, Tree Style Tabs is far and away the biggest extension I care about, so that link does provide me with some level of hope. For which I genuinely thank you.
You're welcome! :D
> On the third hand, my cynical take is that apparently Mozilla really does take community feedback into consideration. When making a wish list of things that could potentially happen in the future to put on a wiki page.
I could talk about this _forever_, but the short version would be: That's not a false criticism of Mozilla in recent times, but it's also not entirely true. Hacker News, r/firefox, and others are very vocal minorities compared to our greater userbase. Sometimes we really need to listen more and change our plans and be more open than we have been, but sometimes the people doomsaying everything we do might have a different opinion if they had all the details and metrics and info (knowing how to navigate Mozilla to find info about something is a skill in itself).
> I've also heard that it's possible that Pocket could be moved to an extension.