Once they stop supporting addons which are actually capable of doing their job...
You've been invited to jump in and help specify the necessary APIs, to be sure they are actually capable of doing their job, so what is this bleating about? Keep in mind that XUL and XPCOM need nasty kludges to work with separate processes and the new API takes care of that by default. Even better, read the FAQ, did you? Or are you in the habit of hoping Hairy will do your thinking for you?
Except they are getting rid of the only reason anybody uses their product...
Rest of post clipped because initial premise is wrong. I use Firefox mainly for entirely different reasons like tabs being competently implemented. Second reason is, if there were no replacement extension API then you would not be full of crap but there is so you are. Have a nice day.
Hopefully, WebExtensions will provide all the same functionality as the deprecated APIs
this is explicitly one of the goals of WEs. It's thus highly likely that they won't provide the same functionality
Yes, the FAQ clearly states that security and privacy issues dictate that some access will not be available to plugins. It will require actual analysis rather than shoot-from-the-lip opinionating to know whether that is a good thing. Are essential capabilities are affected, and if so then does the possibility exist to recover additional functionality in some way? Maybe consider including add some informed commentary in your next post instead of hiding behind some largely content free generalization.
My principle concern, quite naturally, is: are the addons I use implementable using WebExtensions. It is entirely possible that some will work better, for example, I have yet to find a video auto-start blocker that works naturally and reliably. Tends to suggest that the addon API has problems rather than addon developers.
I am still using kmail. It works fine, for the most part. I can GPG encrypt and decrypt emails, but it fails if I try to GPG sign an email. Before kmail, I used pine, and it was pretty easy to drag my pine emails into a kmail archive folder.
I am still using kmail. It works fine...
OMG, surely you don't mean Kmail 2 with its crappy database backend (mysql by default!), loaded with races and inconsistencies that you are 100% guaranteed to hit if you put any kind of load on it, and which contributed absolutely no new functionaly, only killer bugs? I used to love Kmail as a preeminent example of the fine work that open source development can do, until some insane incompetent became the project lead. I tried to tough it out for years, but basically, just lost my ability to handle email effectively, until I finally gave up and threw it away forever in favor of Thunderbird and Trojita, a promising new project that seems to be everything that Kmail is not in terms of precision, as opposed to the amateurish "vision" that sunk Kmail.
I thought Mozilla had stopped development on Thunderbird.
They tried that one on, and learned that the TBird user community is much bigger and relies on it much more than anybody imagined. And that it is more representative of reality than some other wild-eyed adventures such as Mozilla-branded handsets.
[Mozilla needs to be forked again] For XUL and Npapi compatibillity puerposes.[sic]
Mozilla is already forked for exactly this reason. But please read the WebExtensions FAQ before telling us again what you don't know about how and why Mozilla foundation intends to replace those previous-century APIs with something modern that benefits from an additional decade of experience with, among other things, security, privacy and performance issues. And maybe think about a thank you for opening the process up to public debate nice and early.
One point I would suggest paying particular attention to: Will I be able to do everything I can in a legacy technology? The answer is no. The details of that no are awfully important. This is for sure a place where educated feedback would be useful and most probably well received.
What the report also doesn't say... is that the smartphone market is really the Android market.
Because it isn't true. Android is dominant, but Apple still hangs onto a significant and lucrative portion of it. Not that I will shed a tear when Apple finally goes the way of Blackberry, but I fervently hope that viable forks of Android/Linux are well established by then, otherwise we the world are truly in trouble.
As a long-time user though, I can hope that this is finally the act that causes share to plummet enough to make them realize that extensions are the ONLY good thing left about Firefox.
They already realize that. From the FAQ, they want to announce the intention to deprecate XUL, XPCOM[1] et al early, in order to enhance community involvement in honing the new WebExtensions model. Hopefully, WebExtensions will provide all the same functionality as the deprecated APIs, plus important advantages.
The perception issue seems to be that a plan to improve extensibility has been misinterpreted as a plan to abandon extensibility. I for one am convinced by the FAQ, but that is just a quickly formed opinion. Only someone actually involved in extension development, with experience in both the old and new models can tell you the real story.
Look at the mindless monoculture you're advocating when you say that it's OK for Firefox to become a late-to-the-party Chrome clone.
Firefox has one feature of greater importance than any other: it is not ruled by corporate overlords whose primary goal is to invade your privacy and auction it off the highest bidder. Otherwise, Firefox differs from Chrome in many ways that I like, and some that I do not. I see it as a good thing if the latter are addressed. And even if Firefox somehow became exactly the same as Chrome, much to my distress, it would still possess that all-important quality of not being under the thumb of an evil monopolist.
Firefox works for me just great, and on all my devices. I just dont understand the hate.
I do. Google employees have a lot of time on their hands, including a lot of time for shit-posting. It's hard to imagine why anybody without an agenda would spend time and effort attacking.
Firefox remains my primary browser for multiple reasons:
* Handles hundreds of tabs easily, by default
* Avoids reloading pages until needed when restarting with multiple tabs
* Superior url suggestion algorithm keys on text in mid-url
* The addons of course
* Google monoculture threatens freedom and progress
* Google hostile takeover of browser market at expense of community-owned Firefox using tactics learned from Microsoft still rankles
* Google's advertising business conflicts with user's desire for privacy (remember Eric Schmidt's self-serving quotes
I use Chrome too of course, but every time I do I think about how unpleasant the world will become if Google manages to exterminate all its rivals, both proprietary and open. Remember that thing about absolute power. But the more mundane reason is that Firefox just works better for me and is more pleasant to use. I am also pleased with the acceleration in development that came about when Mozilla foundation finally woke up and realized that sucking at Google's tit forever would be an existential threat.
Please don't be patronizing. The post you replied to apparently went "whoosh" for you. Try this superficial observation: you aren't stuck with the templates in STL, you can write your own. Judiciously of course.
If I saw some really nice code, I would copy the style and start using it.
That is not how you learn a professional programming language. This is how. You learn by writing. When you have learned enough by writing to understand what it is that you are reading, then you continue your learning by reading, and more writing.
There does exist a breed of C++ programmer whose primary technique is copying. They are easily recognized because they tend to be incapable of accomplishing anything at all unless handed a class library, and then are only able to accomplish trivial things.
Good C++ style includes never using some basic C constructs (such as arrays and strings) except for APIs...
Good C++ style includes no such thing. It includes using the correct tool for the job. In case you have not noticed, plain old arrays of char tend to be significantly more efficient than std::string, sometimes by orders of magnitudes. If you are unable to employ these tools in cases where the benefit is large then by hiding behind unsupported claims about style, you are actually just masking incompetence.
Here is what good C++ style really is: suppose you are faced with a situation where you must work at the char * level for efficiency, because std::string just doesn't cut it. Did you employ the power of C++ - templates, custom allocation, classes, data hiding, etc etc - to make your code more resilient, readable and extensible while still yielding top performance? That is good C++ style.
C++11's style and philosophy is something you get used to after a while.
Much of it is cringe worthy, some of it makes me want to harm someone, but in the end, it is the go to choice for complex projects where performance is critical. It is quite amazingly good at catching issues at compile time instead of run time, and surviving deep design changes and refactoring without introducing bugs. You pay for that in often horribly opaque compile time error messages. It will generally be slower to develop in than modern scripts like Python, so think seriously about prototyping in some other language. B.CmpSci or equivalent skill level is essential. I get the feeling that critics weighing in on the thread are mainly venting because of not having the necessary grounding. Like wanting to do surgery without going to medical school. It just won't work out, and if you listen in on a conversation between surgeons, the things they are saying will make little sense to you. You can weigh in with your opinion of course, but you are likely to be ignored or worse.
OK, maybe I should show less disdain and more sympathy for the space you are in. "BSD networking APIs are so difficult..." No, sorry, not difficult, doesn't even move the needle. Add a new feature to a compiler, or to a network stack, for example. That's more like it. You have a whole lot more time to do as an apprentice before you should even be looking at the grown-up stuff.
What I'm still missing though: standardized networking (Boost.ASIO looks like a monster at this stage, don't know if that would or even should make it into the ISO standard anytime soon).
Given that boost::filesystem is landing in C++17 it is not much of a stretch to expect the network counterpart to follow in C++20. Networking is considerably more complex than filesystem access especially with the asynchronous element, so it will be better for everybody if they take their time and bake it well. Meanwhile, libc provides everything that 99% of networking applications need, in a mature and powerful form.
Slashdot Mirror
As far as I can see, the desktop is the only place to run Windows.
And only for people who enjoy being anally raped by malware.
Linux is a kernel, not an OS although we think of it that way.
No, you think of it that way because you do not know what you are talking about. The software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals. Hint: if it doesn't have a scheduler, it's not an operating system. Think please, don't make me barf.
Agenda much? Sellout, sheesh. Sucks to be you.
Once they stop supporting addons which are actually capable of doing their job...
You've been invited to jump in and help specify the necessary APIs, to be sure they are actually capable of doing their job, so what is this bleating about? Keep in mind that XUL and XPCOM need nasty kludges to work with separate processes and the new API takes care of that by default. Even better, read the FAQ, did you? Or are you in the habit of hoping Hairy will do your thinking for you?
Except they are getting rid of the only reason anybody uses their product...
Rest of post clipped because initial premise is wrong. I use Firefox mainly for entirely different reasons like tabs being competently implemented. Second reason is, if there were no replacement extension API then you would not be full of crap but there is so you are. Have a nice day.
Hopefully, WebExtensions will provide all the same functionality as the deprecated APIs
this is explicitly one of the goals of WEs. It's thus highly likely that they won't provide the same functionality
Yes, the FAQ clearly states that security and privacy issues dictate that some access will not be available to plugins. It will require actual analysis rather than shoot-from-the-lip opinionating to know whether that is a good thing. Are essential capabilities are affected, and if so then does the possibility exist to recover additional functionality in some way? Maybe consider including add some informed commentary in your next post instead of hiding behind some largely content free generalization.
My principle concern, quite naturally, is: are the addons I use implementable using WebExtensions. It is entirely possible that some will work better, for example, I have yet to find a video auto-start blocker that works naturally and reliably. Tends to suggest that the addon API has problems rather than addon developers.
I am still using kmail. It works fine, for the most part. I can GPG encrypt and decrypt emails, but it fails if I try to GPG sign an email. Before kmail, I used pine, and it was pretty easy to drag my pine emails into a kmail archive folder.
I am still using kmail. It works fine...
OMG, surely you don't mean Kmail 2 with its crappy database backend (mysql by default!), loaded with races and inconsistencies that you are 100% guaranteed to hit if you put any kind of load on it, and which contributed absolutely no new functionaly, only killer bugs? I used to love Kmail as a preeminent example of the fine work that open source development can do, until some insane incompetent became the project lead. I tried to tough it out for years, but basically, just lost my ability to handle email effectively, until I finally gave up and threw it away forever in favor of Thunderbird and Trojita, a promising new project that seems to be everything that Kmail is not in terms of precision, as opposed to the amateurish "vision" that sunk Kmail.
I thought Mozilla had stopped development on Thunderbird.
They tried that one on, and learned that the TBird user community is much bigger and relies on it much more than anybody imagined. And that it is more representative of reality than some other wild-eyed adventures such as Mozilla-branded handsets.
[Mozilla needs to be forked again] For XUL and Npapi compatibillity puerposes.[sic]
Mozilla is already forked for exactly this reason. But please read the WebExtensions FAQ before telling us again what you don't know about how and why Mozilla foundation intends to replace those previous-century APIs with something modern that benefits from an additional decade of experience with, among other things, security, privacy and performance issues. And maybe think about a thank you for opening the process up to public debate nice and early.
One point I would suggest paying particular attention to: Will I be able to do everything I can in a legacy technology? The answer is no. The details of that no are awfully important. This is for sure a place where educated feedback would be useful and most probably well received.
Completely agree with you, that Apple dominates the market of shallow prats.
Five years out of date. Even though we know how it continues, that graph does not tell us.
What the report also doesn't say ... is that the smartphone market is really the Android market.
Because it isn't true. Android is dominant, but Apple still hangs onto a significant and lucrative portion of it. Not that I will shed a tear when Apple finally goes the way of Blackberry, but I fervently hope that viable forks of Android/Linux are well established by then, otherwise we the world are truly in trouble.
As a long-time user though, I can hope that this is finally the act that causes share to plummet enough to make them realize that extensions are the ONLY good thing left about Firefox.
They already realize that. From the FAQ, they want to announce the intention to deprecate XUL, XPCOM[1] et al early, in order to enhance community involvement in honing the new WebExtensions model. Hopefully, WebExtensions will provide all the same functionality as the deprecated APIs, plus important advantages.
The perception issue seems to be that a plan to improve extensibility has been misinterpreted as a plan to abandon extensibility. I for one am convinced by the FAQ, but that is just a quickly formed opinion. Only someone actually involved in extension development, with experience in both the old and new models can tell you the real story.
[1[ Remember COM? Yikes.
Look at the mindless monoculture you're advocating when you say that it's OK for Firefox to become a late-to-the-party Chrome clone.
Firefox has one feature of greater importance than any other: it is not ruled by corporate overlords whose primary goal is to invade your privacy and auction it off the highest bidder. Otherwise, Firefox differs from Chrome in many ways that I like, and some that I do not. I see it as a good thing if the latter are addressed. And even if Firefox somehow became exactly the same as Chrome, much to my distress, it would still possess that all-important quality of not being under the thumb of an evil monopolist.
Firefox works for me just great, and on all my devices. I just dont understand the hate.
I do. Google employees have a lot of time on their hands, including a lot of time for shit-posting. It's hard to imagine why anybody without an agenda would spend time and effort attacking.
Firefox remains my primary browser for multiple reasons:
* Handles hundreds of tabs easily, by default
* Avoids reloading pages until needed when restarting with multiple tabs
* Superior url suggestion algorithm keys on text in mid-url
* The addons of course
* Google monoculture threatens freedom and progress
* Google hostile takeover of browser market at expense of community-owned Firefox using tactics learned from Microsoft still rankles
* Google's advertising business conflicts with user's desire for privacy (remember Eric Schmidt's self-serving quotes
I use Chrome too of course, but every time I do I think about how unpleasant the world will become if Google manages to exterminate all its rivals, both proprietary and open. Remember that thing about absolute power. But the more mundane reason is that Firefox just works better for me and is more pleasant to use. I am also pleased with the acceleration in development that came about when Mozilla foundation finally woke up and realized that sucking at Google's tit forever would be an existential threat.
Worst IT company cozies up to alt-right usurper. Who woulda thunkit?
Try them and see.
Please don't be patronizing. The post you replied to apparently went "whoosh" for you. Try this superficial observation: you aren't stuck with the templates in STL, you can write your own. Judiciously of course.
If I saw some really nice code, I would copy the style and start using it.
That is not how you learn a professional programming language. This is how. You learn by writing. When you have learned enough by writing to understand what it is that you are reading, then you continue your learning by reading, and more writing.
There does exist a breed of C++ programmer whose primary technique is copying. They are easily recognized because they tend to be incapable of accomplishing anything at all unless handed a class library, and then are only able to accomplish trivial things.
Good C++ style includes never using some basic C constructs (such as arrays and strings) except for APIs...
Good C++ style includes no such thing. It includes using the correct tool for the job. In case you have not noticed, plain old arrays of char tend to be significantly more efficient than std::string, sometimes by orders of magnitudes. If you are unable to employ these tools in cases where the benefit is large then by hiding behind unsupported claims about style, you are actually just masking incompetence.
Here is what good C++ style really is: suppose you are faced with a situation where you must work at the char * level for efficiency, because std::string just doesn't cut it. Did you employ the power of C++ - templates, custom allocation, classes, data hiding, etc etc - to make your code more resilient, readable and extensible while still yielding top performance? That is good C++ style.
C++11's style and philosophy is something you get used to after a while.
Much of it is cringe worthy, some of it makes me want to harm someone, but in the end, it is the go to choice for complex projects where performance is critical. It is quite amazingly good at catching issues at compile time instead of run time, and surviving deep design changes and refactoring without introducing bugs. You pay for that in often horribly opaque compile time error messages. It will generally be slower to develop in than modern scripts like Python, so think seriously about prototyping in some other language. B.CmpSci or equivalent skill level is essential. I get the feeling that critics weighing in on the thread are mainly venting because of not having the necessary grounding. Like wanting to do surgery without going to medical school. It just won't work out, and if you listen in on a conversation between surgeons, the things they are saying will make little sense to you. You can weigh in with your opinion of course, but you are likely to be ignored or worse.
OK, maybe I should show less disdain and more sympathy for the space you are in. "BSD networking APIs are so difficult..." No, sorry, not difficult, doesn't even move the needle. Add a new feature to a compiler, or to a network stack, for example. That's more like it. You have a whole lot more time to do as an apprentice before you should even be looking at the grown-up stuff.
What I'm still missing though: standardized networking (Boost.ASIO looks like a monster at this stage, don't know if that would or even should make it into the ISO standard anytime soon).
Given that boost::filesystem is landing in C++17 it is not much of a stretch to expect the network counterpart to follow in C++20. Networking is considerably more complex than filesystem access especially with the asynchronous element, so it will be better for everybody if they take their time and bake it well. Meanwhile, libc provides everything that 99% of networking applications need, in a mature and powerful form.
The code would be cleaner using auto in places, and some of the iterations would look much better replaced with range-for loops.
Your analysis is pathetically shallow. Problem could be you?
MIT license or equivalent is an absolutely necessary ingredient for Google's final descent to full evil.