Pacabel

I think that they've already voluntarily given up control over the destiny of Firefox, in a sense. By imitating Chrome so closely these past few years, we haven't seen any real innovation out of Mozilla. They've been following, rather than leading. Since they aren't calling the shots, they don't really have true control over the future of Firefox.

What is it that makes you think that the reception of Australis was "very positive"?

I'd consider the reception of a software product update to merely be "positive" if there was generally praise, basically no negativity at all, and people expressing that they are now significantly better off.

"Very positive" would involve no negativity, and complete and total jubilation from users. This is extremely rare.

A lot of people are not happy about Australis, and justifiably so. While Firefox has been imitating Chrome the past few years, Australis sealed the deal and made them nearly identical in the most critical ways.

The only mitigating factor is that there really isn't a viable alternative to either Chrome or Firefox these days. Opera has basically become Chrome, and Safari obviously has very similar roots. IE is engaging in the same imitation of Chrome. Both IE and Safari suffer from a lack of portability, too.

Many Firefox users are extremely disappointed with Australis, but they have no recourse. Switching browsers isn't really an option. And we wouldn't be in this position had Mozilla listened to all of the past feedback they've been given, so giving more feedback is probably a pointless exercise. So they suck it up, as best they can.

Australis was a debacle, at best. I think you're deceiving yourself, and people not familiar with the situation, to suggest otherwise.

Are you really suggesting that people can't have second or even third careers?

A 40-year-old who got into web design after a lengthy career in print media design, if not some totally unrelated field, is often no more experienced than a 20-year-old who got directly into web design. I know this can be true, because I've worked with both types of people in the past.

And "often" does not mean "always", obviously.

Like I said in an earlier comment, age has very little to do with this. "Hipsters" can pretty much be any age.

It's more the "hipster" mindset and attitude that's the problem. This attitude involves fashion and trends trumping all other considerations. Maybe that's okay when it comes to something like clothing. It isn't acceptable, however, when it comes to tools that are supposed to be productive, including software.

If you've got a better term than "hipster", I'm willing to consider using it. I'm just not aware of any other term that better describes the particular attitude that puts vanity, arrogance, ego, smugness and focus on appearance over everything else.

It depends on who you are, and how you use the browser. Maybe the Chrome UI is good for somebody with a tiny screen and a near-complete lack of technical ability.

But for people with large monitors and the need to push a web browser hard, they've merely managed to strip out or hide a lot of very useful functionality, with essentially no benefit. What's left over is non-standard and awkward to use (like Chrome's menu).

No, not at all. It isn't really about age. I've dealt with "hipsters" in their 40s and 50s who've come up with very bad UI designs. Likewise, many of the managers or executives advocating for these redesigns are in their 30s, 40s or even 50s.

While it may be more of an issue with younger people due to a greater lack of experience and intuition, it's a phenomenon that's quite independent of age.

I'm always very hesitant to rely on fallbacks like that. They tend to go unmaintained, at best, but usually just get removed after some period of time.

There's the slight possibility that it might be different in this case, given that Google has many resources at its disposal. But in other cases, such a fallback is merely an attempt to temporarily mitigate legitimate complains about a now-inferior experience, without doing any actual work.

What you're saying is absolutely correct. I actually had to use Bing Maps today to look up some directions because the new version of Google Maps was pretty much unusable.

As for why UX disasters like this can happen, I think it generally comes down to one thing these days: "hipsters".

Those of us who've been in industry for a long time have no doubt seen this happen before. A relatively well-established product has a usable UI. It isn't perfect, and maybe even looks "dated" in some ways, but it generally works and is understood by its existing users.

So-called "hipsters" (that is, people who have an uncompromising view that they're talented "designers" or "UI experts", with a massive ego to back this up, and a fixation on being "trendy") get involved at some point. These people are often relatively young, often have limited experience, and are usually more focused on making designs look "pretty" and "modern" rather than usable.

Needing to create work for themselves, these hipsters, coupled with managers who need to appear to be leading something seen as "productive", start on a UI redesign. Often this is done without the involvement or insight offered by the existing developers of the product, nor any of the product's users. Changes are made purely to look "better", with limited to no consideration of how it'll impact the usability of the product.

The end result is a total cock-up like this, or like the poor UI of Chrome (and the imitations of it by Firefox, Opera and IE), or a project-killing release like GNOME 3, or an abysmal failure like Windows 8.

UIs were generally far more usable in the 1980s, 1990s, and the first half of the 2000s, before "hipsters" got involved with design. What we see today is a total jumble of inconsistent and incoherent UI design, where usability and efficiency are considered significantly less important than "looking trendy".

Do the "principles" in your case revolve around openness, freedom, and so forth?

I've heard a lot of people use such ideals when advocating for Firefox OS, but I just don't see it all holding true in practice.

Firefox OS is one of the more restrictive environments, at least for developers. I'm basically stuck using JavaScript, HTML and CSS. If I want to use any other language, I have to try to molest it through something like Emscripten. If I want to create a native app, I'm out of luck.

At least a platform like Android gives developers a comparatively wide variety of options, from Java, to C and C++, to JavaScript/HTML5/CSS.

By limiting the freedom of developers to create apps as they see fit, then it directly impacts the freedom of end users to use such apps.

And I don't see Firefox OS as being particularly open in other respects. Maybe the code is available under an open source license, and maybe Mozilla will accept minor bug fixes from the community, but I really doubt an average user would have any ability to influence/impact/control Firefox OS beyond that. Decisions are foisted upon the users. It doesn't seem any better than Android, or iOS, or whatever other platform you want to consider.

The same goes for the "But we implement open standards!" claims. The process to come up with such standards isn't very open at all. It ends up being controlled by a small handful of major browser vendors, with minimal to no input from others. Merely being published does not make a standard "open".

All in all, it makes no sense to me to choose Firefox OS on a matter of principle. It doesn't actually meet whatever standard is being set by those principles, yet it still gives a much inferior experience to the alternatives.

"Native" is not a marketing term, and we shouldn't pretend that it is.

It has a very specific definition in this context, and this definition requires that the application be represented in a form that's directly executable on whatever CPU is being used by the computer executing the application.

Anything that doesn't match that very simple criteria is obviously not a "native" app.

Maybe a new term is needed for describing this type of situation involving Firefox OS. I don't know what that would be, but I do know that we shouldn't go ruining an existing technical term.

I'm sorry, that's incorrect.

"Native apps" are ones that have been compiled down to machine code that's directly executable on whatever CPU or CPUs might be provided by the device in question. Ahead-of-time compilation is thus required.

As such, "native apps" cannot be represented solely in a higher-level code that is interpreted, regardless of how its interpreter may be implemented (this includes direct interpretation, JIT compilation, and so on).

Apps built using interpreted JavaScript clearly are not "native" apps, unless we're dealing with hardware that directly executes JavaScript code. The ARM CPUs typically found in smartphones today don't do that.

What you're describing is independent from the concept of "native apps". It's more about platform restrictions than it is about their capabilities. If an operating system like Firefox OS goes out of its way to not support real native apps, that doesn't mean that what it does support are "native" in any way.

I don't know if there's a good term to use instead, but it surely does not involve the word "native" in any way, given that that term already has very specific and existing meaning.

The Smalltalk developer experience may in some ways be one of the better parts of Smalltalk, but at the same time it's also one of the worst.

Getting tied into a particular environment often made it awkward, if not practically impossible, to integrate with other editors, code manipulation tools, version control systems, and so forth.

This might have been okay in academia, but it was far less acceptable in industry.

That's rarely a productive question to ask.

It's just a slight variation on the totally unhelpful "Why don't you fix the bug yourself?" response that's sometimes given to people reporting a problem with an open source project.

They're useless questions because the answer is pretty much irrelevant.

Maybe he doesn't know how. Maybe he isn't qualified. Maybe he doesn't have the time. Maybe he doesn't have the money to fund somebody else doing it. Maybe he just doesn't want to.

It doesn't matter why he might not do it himself. But that in no way means he shouldn't publicly express such interest in such functionality, in case there is somebody else who is willing or interested in adding it.

That's total nonsense. Binaries (or shared libraries they depend on) can be and are updated, on all sorts of systems. In many cases it's as simple as overwriting the existing binary with the updated version.

Heck, the runtimes you're advocating are generally installed as binaries. If they can get updated, then so can any other binary.

And if a user doesn't bother to update a given application's binary when a critical flaw of some sort is found, then there's a very good chance they wouldn't bother to update any runtimes that are installed, either. This is true even when some sort of update notification and installation process is offered. The end result is the same in either case: the update is not applied.

Runtimes shouldn't be portrayed as any better in this case, when they're generally no different than any other binary.

There's absolutely nothing wrong with questioning something that somebody has worked on. In fact, such questioning should be encouraged.

Good ideas and creators will be able to withstand such scrutiny without any problems at all. Bad ones can use it as an opportunity to improve.

That's what I was thinking, too. That's merely around 13,000 messages per second per core. Rates like that weren't all that impressive on low end server hardware a decade ago, so I'd hope that it's even less impressive today when using more modern hardware (or even VMs).

GCC's traction is mainly due to it being, for a very long time, the most complete and widely-ported open source compiler system available.

Its competitors tended to be expensive commercial options, or comparatively limited open source projects. Any individual or organization wanting to use an advanced, yet free, compiler system generally ended up with GCC by default.

It wasn't GCC's licensing that attracted them. In fact, its licensing ended up being a liability, especially for commercial users. That's why we've seen LLVM and Clang really take off lately. They started to not only match the functionality of GCC, but did so with a far more flexible licensing approach. This made them a much more appealing set of tools for many users, both commercial and open source.

Perhaps we need to take a second look at where the "lambasting" first took place. It was well, well before this recent OpenSSL incident.

For many years now, the security community taken as a whole has very vocally stated, "Never roll your own crypto!", and been highly critical of anyone who has attempted to do so without the security community's blessing.

For many programmers, maybe that is good advice. They probably shouldn't try to design their own schemes, and probably shouldn't try to build them, either.

But I think this attitude has also driven away a lot of very talented programmers who perhaps could have caught an issue like this much earlier on, or perhaps even avoided it in the first place.

So I believe it's misleading for you to portray the users of OpenSSL as somehow being responsible, especially given how much effort the security community has generally put forth toward discouraging more direct participation from these users.

The security community took a holier-than-thou attitude for a long time. It has now been shown that they aren't necessarily any better at avoiding critical and very harmful bugs in their code, however. So of course people will call them out. And there's not a thing wrong with doing so.

The very poor contrast doesn't help the situation, either.

Are you currently seeing that option somewhere? I looked in the settings, but I did not see it there, and I do not see any other way to disable that functionality.

Could this be a feature that is disabled by default, but that can be easily enabled if a user does wish to use it?

I don't know the best way to do this, but I'm thinking a checkbox somewhere near the search bar, or perhaps a prefix similar to "g!" that'll enable it for any further text that's entered, or something along those lines.

Most sensible people see that it's a bad idea, and they can see this today (if not yesterday). This isn't the kind of thing that requires hindsight to see that it's a bad idea through and through.

If anything should be questioned in hindsight, it should be why so many managers and executives allowed designers to seriously submit such bad ideas for consideration, never mind allowing such unusable designs to actually be implemented.

If a person or organization says that they're going to do something, even if it's qualified as only being "planned", it is indeed a promise to act.

Reputable people and organizations who make such statements will then proceed to deliver. If they suspect they won't be able to, for whatever reason, then they'll be careful not to make such statements in the first place.

There's absolutely nothing wrong with holding people and organizations to a very high standard regarding what they've publicly claimed that they will or aim to do.

While the existing approach may have its flaws, the wholesale removal of valuable information and functionality from the browser UI very likely isn't the right fix, either.

In my opinion, this is up there with the removal of the URL protocol, the removal of the status bar, the removal of the menu bar, the removal of the ability to disable JavaScript easily, and the other similar changes we've seen from Chrome and/or Firefox over the past few years.

This useful functionality is removed under the guise of "increasing usability" or "improving security" or some equally vague justification. So-called "average users" don't even notice any improvement, while power users are forced to endure a dumbed-down, less effective browser experience.

A big part of the problem is that while there are competing browsers, we just don't see any real competition these days.

Firefox and IE have started copying Chrome in appearance and philosophy. Opera is now based on the same code. Safari is based on similar code, and is unusable by anyone not using a Mac of some sort.

Firefox is perhaps the most viable alternative to Chrome for web developers or advanced users. But due to that lack of competition or original thought, it really isn't much different from Chrome at all. This has become very apparent with the release of Firefox 29, where they both now look nearly identical, and both suffer from the same dumbing-down that has harmed the experience for more advanced web users.

Not only is it explicitly stated, but it's done so in the very first sentence.

Many of the best programmers I've ever worked with have absolutely no code on GitHub. Why is that? It's because they're using their talents and abilities in industry, solving real problems, in positions where they're obligated to not share the code they've produced.

I'd hire those people any day over somebody with numerous GitHub repos filled with quasi-maintained JavaScript libraries or numerous forks of code they didn't write.

We've seen other, similar, widely-used platforms lose prominence rather quickly. SourceForge and Google Code are two such examples (both of which also support Git these days). I see no reason why GitHub would be immune from such forces.

I wouldn't exactly call Haskell "popular". It isn't as obscure as some programming languages, but realistically, it sees comparatively little use in practice.

And Haskell predates Python, Ruby, JavaScript, Java and C#. It has had a very long time to become more widely used, yet we just haven't seen this happen. It's not like people don't know about it; many students, academics and practitioners have been exposed to it for years now, and it does get a fair amount of hype for a language that has experienced limited use in practice.

I just don't think it offers enough benefit for the cost involved with learning and using it. If the balance were better, we'd see it being used. But that isn't the case, so it sees minimal usage.

A fair amount. I used ML and Haskell in the 1990s in an academic setting, and have since used Haskell, Erlang, and Scala at various times while in industry. And I've tried out a number of other functional languages out of interest, as well.

Functional programming does offer some benefits, in some cases. I'm not suggesting that it doesn't. And while I don't think it'd be harmful to know Haskell, I'm not convinced that the benefit it would bring is necessarily worth the effort involved, especially for programmers who are already busy with work and other commitments.