Pacabel

Yes, voting down a legitimate comment here so that it's greyed out, thus making it more difficult to read, is a form of censorship.

As for Firefox's reputation, I think it still has a reputation for poor performance because, contrary to what you and others may claim, a lot of people still find recent releases to be slower than Chrome and other browsers.

It will never be able to shed its reputation for poor performance as long as it still suffers from those problems. And these problems will persist as long as the Firefox community continues to deny that they exist, or go out of their way to suppress discussion of these very real performance problems.

Can you please address why we haven't seen much progress, even after so many years?

You and others involved with Firefox may choose to deny it, but a lot of people still find recent versions of Firefox to be slow and/or to suffer from stability problems.

For example, just look at the discussion at Slashdot today about the Firefox 31 release:

http://news.slashdot.org/story/14/07/22/1918237/firefox-31-r...

Here are some comments that specifically mention Firefox being slow and/or unstable:

http://news.slashdot.org/comments.pl?sid=5438731&cid=4751105...

http://news.slashdot.org/comments.pl?sid=5438731&cid=4751077...

http://news.slashdot.org/comments.pl?sid=5438731&cid=4751091...

http://news.slashdot.org/comments.pl?sid=5438731&cid=4751127...

http://news.slashdot.org/comments.pl?sid=5438731&cid=4751144...

Whenever Firefox is discussed, those kinds of comments seem to be quite common. While some may choose to brush them off, to me it indicates that Firefox has some real problems, and these problems just aren't being fixed. We wouldn't see people continually bringing up these problems if they truly had been fixed.

I don't think that there is a good place to do that, unfortunately.

You could file a bug, but it'll be pretty much lost among the thousands upon thousands of other ones that already exist and haven't been dealt with.

You could comment here or in some other discussion forum, but those in the Firefox community will probably just vote you down, and continue to pretend that there isn't a problem.

You could write an article, but again, that probably won't help much, unfortunately.

The best thing to do may be to find an alternative browser, or use older browsers that aren't broken in this manner.

I just don't think that those working on Firefox these days truly care to listen to what the remaining Firefox users have to say. Time and time again lots of users have loudly expressed extreme displeasure with monumental mistakes like Australis and the removal of useful functionality, only to be totally ignored by the Firefox developers. I don't see why this situation should be any different.

Unfortunately not.

There's no "seems" about it. Useful functionality has been obscured or removed from Firefox time and time and time and time again since Firefox 4 and their rush to imitate Chrome. It isn't a new problem at this point; it has been happening for years now, and people have been angered by it for years now, too.

It's a shame that your comment has been voted down, as well. The more that the Firefox community goes out of its way to deny that users are unhappy, or even to censor them like in this case, the harder it will be for Mozilla to remain relevant.

Firefox is pretty much Mozilla's only semi-successful offering at this point, and even its market share has been steadily dropping (it's probably well under 20% by now). If this slide continues, nobody will have any reason to listen to Mozilla. Their influence over the web, already waning, will unfortunately become non-existent.

Maybe you and others in the Firefox community don't realize this, but this isn't about counting "anecdotes" or anything like that.

This is about users having bad experiences when using Firefox. Your positive experience in no way negates these bad experiences.

Your response is the kind that has given the Firefox community a rather bad reputation when it comes to addressing problems reported by users.

Instead of accepting that Firefox may indeed have performance problem, you immediately discount this possibility, instead blaming it on mr_november's computer.

It's irrelevant that it isn't happening on your laptop that's over 2 years newer than his is. It's irrelevant that it isn't happening on your Ubuntu system. None of that matters.

I don't doubt for a second that he is in fact running into performance problems with Firefox. He isn't alone. Many people report Firefox having worse performance than Chrome does on the same system. I've experienced this, too.

Yet instead of addressing and fixing these very real performance problems that have been brought up time and time again by many users, the Firefox community and developers seem content to deny that they exist, or refuse to consider that it may be a problem with Firefox (like you've done), or point to useless and totally unrealistic benchmarks to suggest it isn't a problem.

But worst of all is how mr_november's comment has been voted down. It's one thing to deny that the problem exists, but it's much worse to try to actively censor those who have merely pointed out a very legitimate and troubling issue.

Firefox has been losing market share for some time now, and this trend will only continue as long as Firefox's performance problems go unaddressed, and the Firefox community mistreats anyone who dares mention that such problems still exist.

I think the exodus from Slashdot has been beneficial. It has shown that the various problems there are in fact severe enough to drive a large number of users away.

It may not be an ideal situation, of course, but it's better than the problems continuing to build under the surface, and users remaining miserable.

Now that the discontent is much more visible, there's at least some hope that real improvement may just happen there. That would not have been the case if people had remained, even if they were merely just vocal about their discontent, without acting upon it in some measurable way.

I merely pointed out one recent example that I could demonstrate quickly, because it happened to involve some of my comments and those of somebody else who happened to express similar ideas.

It isn't the only instance, of course. Mis-moderation is quite frequent here. Some of the discussion under this submission is a good example of that. I see I have once again been targeted by people who find it easier to downvote than to bother discussing the matter at hand like adults.

I wish that people here were more willing to discuss stuff that they might happen to disagree with, rather than engaging in censorship.

I think this is partially due to the informality that many GitHub users tend to have with respect to managing their projects.

It's rare to see a GitHub-hosted project that offers proper releases, proper planning for those releases, proper documentation, and the organization and project management efforts that enable such things.

The lack of such basic project management structure leads to projects that see very erratic development, or outright abandonment. Many GitHub-hosted projects are barely more than a hobby, rather than an ongoing concern. Their code may be somewhat usable, but it's rarely comparable to what we see from more organized projects.

Ruby on Rails is somewhat of a special case, though.

Early web technologies like CGI, PHP, JSP, ColdFusion, ASP and ASP.NET arose due to real-world needs.

Ruby on Rails, on the other hand, arose mainly due to hype.

From a technological perspective, there really wasn't anything special about Ruby on Rails. Many of us who had been doing web development for some time had already built or used proprietary/in-house frameworks that offered the same functionality, but were written in Perl, Python or Tcl instead.

If it weren't for strong and very loud personalities within the Ruby on Rails community, combined with some very lucky timing with respect to the rise of the so-called "Web 2.0", it likely wouldn't have been seen as "special", and wouldn't have garnered the hype that it did.

Technologies that come out of an environment of hype, rather than solving real problems, tend not to stick around as long. Systems built using technologies that solve real problems continue to be used and maintained. Systems built using technology chosen purely because some manager or executive saw a webcast full of nice-sounding buzzwords tend not to survive very long.

Reversing a bad moderation or operational decision when it's widely pointed out as having been a bad decision isn't what I consider giving the community any control or influence. That's merely fixing mistakes that probably shouldn't have been made to begin with, had real community involvement been in place.

What I mean, for example, is that while submissions and comments may be critiqued, there's pretty much no formal way for users in general here to critique that critiquing. The best that can be done is a submission like this one, which for whatever reason ended up off of the front page rather quickly. That's what I'm talking about.

Slashdot has its meta-moderation system, for example, which is somewhat useful and somewhat accessible. There's nothing even approaching that here, as far as I know.

It's a problem when there is discussion about a submission, then the URL is changed to a somewhat different article, and the existing discussion no longer makes as much sense.

Ripping away the original context unexpectedly is the problem. So making the original context more accessible is one good solution to this problem.

I wonder why the parent comment was voted down. I don't see anything wrong with it. In fact, it has some perfectly reasonable ideas and suggestions.

I find it odd that people within the discussion here can suggest that bad flagging or bad voting isn't an issue, when we have a perfect example of it involving what's currently the 7th comment from the top.

Here's one example of systematic downvoting that I can think of: https://news.ycombinator.com/item?id=7836937

So sum it up, me and somebody named jsmthrowaway happened to point out some painful realities regarding the Rust programming language. The facts we brought up must have hurt the feelings of some within the Rust community (several prominent figures were involved with that discussion), and so numerous factual and perfectly legitimate comments of ours within that thread of discussion basically ended up censored.

Now, I personally don't care about karma, or whether people agree or disagree with opinions I express or facts that I may happen to point out. What I don't like, however, is seeing perfectly good content grayed out, regardless of who posted it. Censorship is always harmful.

These days, I find the grayed out comments more disruptive than beneficial. Many of them are perfectly valid content. Some of them often are quite insightful, in a way that some people probably find painful.

So instead of being comments that I feel comfortable ignoring, I usually find myself trying to read the grayed out ones even though they've been obscured and are harder to read. They're often the most worthwhile comments within a submission's discussion.

I don't think that we can really consider Perl 6 and Parrot to be anything but abysmal failures at this point. The people developing and advocating for them have had many years now to product something that's even minimally usable, and we just haven't seen that happen.

Writing traditional compilers and interpreters, or emitting C, or targeting LLVM have all proven to be good ways of getting production-grade programming language implementations created and usable quickly. Messing around with Parrot has never resulted in anything useful.

This is very true.

Many of the subreddits that are very specific to a given technology or programming language or something like that are often the worst. The audience is comparatively small to begin with, and mostly made up of people who hold the technology in high esteem. Any user who submits comments that may be deemed as slightly negative or questioning of the technology are targeted and "eliminated", so to speak.

This leads to a very toxic environment where quality content and discussion become totally non-existent.

I think the problem extends beyond submission flagging.

There have been enough times where I've witnessed completely factual and legitimate comments here that happened to criticize or even just question Mozilla, Rust, Ruby on Rails, NoSQL, or some other "revered" organization or technology get heavily voted down without justification.

Some of this may just arise naturally. Certain submissions may draw the attention of people directly involved with the given organization or technology. They may take it personally when the discussion touches on perfectly valid, yet perhaps painful, topics. They respond by downvoting these comments that are totally valid and raise some good points. Even if these people are not intentionally acting maliciously, this misvoting can still be quite harmful.

I'm not certain that there's a good way of dealing with this, however.

Just because a situation isn't as bad as it once was doesn't mean that it's somehow "good" now, though.

Let's be honest, this website isn't a democracy or a republic or anything like that, even if there is "voting" on submissions and comments.

Average users really have no say while they're here. There's no real ability to control or even influence how this site is operated.

Leaving, or choosing not to actively participate any longer, probably does have the biggest impact of all of the options available to a user. Discussion forums need participants, and participants leaving over time can have a huge impact.

Slashdot is a good example of this. Various site owners/operators started changing things in ways that users did not like. Many users spoke out, but they were ignored. In many cases, they were subjected to downmodding, especially those who spoke out against bad UI changes or the recent beta site. Seeing that discussing the problems had no impact on the situation, they left. Now Slashdot is a wasteland compared to what it once was, a decade or so ago. The decline in participation may be gradual, but it's very real, and its impact is significant.

The modified/edited/curated title and/or URL could always be shown underneath or beside the original title and URL, which remain unchanged.

I ignored the JVM because it really isn't that special at all, and its supposed benefits haven't been proven to exist in reality.

Various types of VMs predated it by decades, including ones that used various forms of GC and JIT compilation. See some of the Pascal and Smalltalk implementations from decades ago as an example of these systems. These did see a fair amount of use, in practice.

The JVM isn't particularly portable. It may support most of the major mainstream OSes used today, but it's not like portable C or C++ code (including other language implementations for Perl, Python, and so forth) that can run on all sorts of obscure and ancient systems.

Its performance isn't particularly remarkable, either, even with all of the effort that some very large companies have put into it. Its been pretty much relegated to server-side use at this point, and even then we're seeing more and more effort made to move away from it. People are realizing that it's often better to go native, as we're seeing with newer languages like Go and Rust.

The JVM did get a lot of hype, and has seen a lot of use, but it's mediocre at best. There's nothing particularly earth-shattering about it.

Has there really been that much actual progress made lately, though?

I'd say that C++, Erlang and perhaps Haskell are the most recent languages to bring anything new to the table in a way that's at least somewhat usable in practice. And they're decades old at this point.

C++ helped make OO and generic programming feasible. Erlang helped with developing concurrent, distributed, fault-tolerant software. Haskell brought pure functional programming and laziness to a wider audience.

Otherwise, the widely-hyped languages of today, including Scala, Ruby, JavaScript, Go, Rust and even Kotlin generally just rehash what C++, Erlang, Haskell and other languages offered several decades ago.

Some of those languages, like JavaScript and even Go, are arguably worse in many ways than languages developed in the 1980s or way earlier.

At best, we're seeing small, incremental improvements. More realistically, we're just seeing old ideas rehashed again and again, with minor syntactic differences. Thus we aren't really seeing real "experimentation", and we aren't witnessing much "progress".

Isn't listening to users the least that we should be able to expect from any open source project? Some projects (like GNOME and Firefox) have not done this very well lately, but it used to be pretty standard. The BSDs and their affiliated projects have generally been more receptive to the needs of users than most open source projects, as well.

I'm disappointed to hear that the use of -Werror was removed, though. I wish they'd been more specific in the email about how far they've gone with this. Is it only removed for certain platforms/compilers where it was problematic, or is it gone for all builds?

There's a difference between the creator of a software system and who actually adopts it and advocates it in practice.

Yes, git did originally come from Linus and the Linux kernel development community. But since then, their original use of it has been eclipsed by the larger and more vocal GitHub/Ruby on Rails/JavaScript segment of software developers. The fact that both groups use git does not mean that they're otherwise connected in any way. Traits (such as the propensity to be a hipster) specific to one of the groups very likely do not apply to the other.

Many of these GitHub/Ruby on Rails/JavaScript people do advocate very loudly for git's use everywhere, even in situations where it is not the best choice, or even where it's obviously a bad choice. Some of them have elevated git from being a tool to a quasi-religion. They've done this with some of their other "chosen" tools, too, so it's not just limited to git.

They do make the git community as a whole look quite bad. But they're obviously very distinct and separate from the Linux kernel developers who created git. The two distinct groups should obviously not be confused.

In addition, correctness and security should always be prioritized ahead of portability. It does no good for software to be portable if that just means it's incorrect and insecure on more platforms.

It's not the state of the software itself that's being questioned here. It's how security wasn't put first and foremost in this case. Putting an extraordinarily high degree of emphasis on security is something a lot of us have come to expect from OpenBSD and related projects. Security comes first, even if that means waiting a bit longer for an official release, or something like that.

While LibreSSL does appear to be going in the right direction, especially after the disastrous few months that OpenSSL has had, the community at large does want to be reassured that the LibreSSL project truly does revere security. A more security-conscious release in this case would have helped with that.

Menus aren't merely about hiding functionality. They're about organizing oft-used functionality in a way that's easily and consistently accessible, while at the same time not consuming too much screen space.

The traditional horizontal menu bar with multiple consistently-titled menus is a system that has worked very well for decades. For developers and UI designers, it's generally quite obvious where menu items should go. For users, it's generally obvious where the developers would have put the menu items for some specific functionality.

The Chrome-style single-obscure-menu-with-everything-poorly-organized-inside-it approach throws all of this away. It results in the worst of all trade offs. It's harder to find, the menu itself is an inconsistent jumble, the amount of functionality within it is less, it's not worth gaining a small amount of screen space for the inefficiency such a broken menu system brings, and it's just plain harder to use. It really is bad in every way.

I don't want to deal with numerous bookmarks to internal pages, or site maps, or any crap like that.

I want to be able to type "haskell.org" into any browser, and from there be able to quickly get to the standard library documentation, to the language spec, to Planet Haskell, to the downloads, and so on, without having to dig through subpages of subpages of subpages, and without having to scroll.

The Rust website at http://www.rust-lang.org/ is a good example of how a programming language home page should be laid out. There are many relevant links at the top. I can almost always find what I want within the first inch or two of the page. Yet it still shows all of the marketing junk for those who want that stuff, but it's placed well below the useful content.

The new Haskell design is the complete opposite of that. It puts a lot of useless junk front and center, and almost totally discards everything that actually is useful.

This "your UI shouldn’t mimick [sic] the native style of the platform" advice reminds me of what we used to hear when using Java and Swing a decade ago.

It resulted in a bad user experience then, and I think that still holds true today. Swing apps never felt right on any platform, even when using a native theme. It's probably no different for apps built using Cordova, too.