"Failing hard" and "severe dysfunction" probably aren't the most realistic ways of describing it. The situation isn't good, but it also isn't bad enough for terms such as those to apply.
While it isn't exactly a pleasant tool to use, it's not like it's totally broken either. I've used other similar software that was much worse to use than pgAdmin 4 is.
It's slightly better than pgAdmin 3 in some ways, but it's also worse in other ways. Overall, it's mediocre. That might be the underlying problem: it doesn't live up to the high expectations that the rest of the PostgreSQL ecosystem tends to set.
If I had to give it a grade, I'd say it's a B- or a C+. It could be a lot worse, but it could also be a lot better.
> They do (and any service basically). You don't want to run a large-scale service without having some way for your users to self-reset their passwords.
I don't buy that. There are other similar services that allow an email address to optionally be provided later, for password-resetting purposes. I believe reddit is like that, as is this site.
This site gives me a "Please put a valid address in the email field, or we won't be able to send you a new password if you forget yours." message when I view my preferences, for example.
I don't buy your phone number claim, either. There are many other services out there, including ones that very likely have a presence in a country like Germany, that support user-posted content but that don't require a phone number to sign up.
When I last tried to sign up, they requested a phone number, I assume as some sort of an attempt to make it harder for spammers to sign up. I don't think they have any legitimate reason for that sort of information, so I didn't provide it. I don't remember the specifics, but either I couldn't finish creating the account, or it was created and then automatically locked/suspended a few minutes later. The end result was that I couldn't sign up and use the service in any meaningful way.
I don't know if that's still the case or not. After that rather awful experience trying to sign up, I've lost all interest in trying again.
I'm not surprised they're having trouble growing when they impede the ability of people to sign up! There's no reason for their signup process to need anything more than a username and a password. They don't need my email address. They surely don't need my phone number or any other information about me.
It was the extension signing that caused me to move on. I had written several small, but useful, extensions for my own personal use. I knew they were harmless, yet Firefox made it difficult for me to actually use them.
If I'm remembering this right, I think there was initially an about:config option for disabling the signature checks. But that was eventually removed from the stable releases. The workarounds were to waste my time getting the extensions signed, or to use some special unbranded build, or to use the Nightly or Developer Edition releases. None of those were acceptable to me. Then I learned about the planned WebExtensions changes, and knew it was time to move on.
I'm aware of the security-related reasons that were used to justify such changes. But for me they ended up taking away the main benefits that Firefox offered, namely being easy to extend, and giving me the freedom to use the browser as I see fit.
I think the "Why?" section's conclusions are off the mark. It basically blames Google's advertising of Chrome for Firefox's decline, and even goes so far as to say "Firefox’s decline is not an engineering problem."
While I don't doubt that Google's advertising of Chrome has drawn away some Firefox users, I also don't think that we can ignore or deny the many controversial changes to Firefox that have likely had an impact, too.
Just off of the top of my head I can think of things like:
* Frequent breakage of extensions when first switching to the more rapid release schedule.
* Frequent and disruptive UI changes that didn't bring users much benefit, such as Australis.
* Removing the ability to easily disable JavaScript.
* Taking many years to get multiprocess support working. (Not that I'm suggesting they should have rushed it, of course.)
* The inclusion of Pocket and Hello.
* Sponsored tiles.
* Users who report experiencing poor performance and high memory usage.
* Disruption caused by requiring signed extensions.
* The removal of support for OSes or OS releases that are moderately older, but still do have active users.
I'm sure there are others that I'm forgetting.
Even if they seem minor, those are the kinds of things that can cause users to switch away from Firefox, or not even start using it in the first place. Losing a small number of users for a variety of minor reasons can add up very quickly, as well. Furthermore, those issues don't really have anything to do with Google or Chrome.
The big problem I have with having conversations on Twitter is that I wasn't even able to sign up for a Twitter account the last time I tried. It wanted me to provide a phone number. I refuse to do this, as they have no legitimate need for that information, even if it is just a lousy technique to try to avoid spammers from using their service. I think the account was automatically canceled or locked or something like that, just a few minutes after opting not to give my phone number. I don't know if this is still the case, but it turned me off of Twitter.
The thing I dislike is how such languages try to abstract away the filesystem representation of packages/modules/libraries/etc.
The conventions and resolution approaches that are needed to accomplish this often end up being opaque, less flexible, and harder to work with.
I much prefer the approach of C, C++, and even PHP to some extent, where the interaction with the filesystem isn't hidden.
When using C or C++, it's trivial to reference a globally-installed library, such as the standard libraries of such languages. It's also simple to reference third-party libraries, or even to include local copies of third-party libraries within one's own source tree. Relative or even absolute paths can easily be specified when referencing external code.
This also gives so much more flexibility with regards to how a project is laid out, and how it pulls in other code or libraries it depends on. I can follow an approach that works for me, for my project, for my team, for my version control system, for my development environment, for my deployment environment, and so on.
I want the language to conform to my needs. I don't want to have to modify my behavior and my environments to conform with what the language's developers deem to be the "right way" of doing things, especially when this isn't compatible with my needs.
Maybe this means there's slightly less consistency with how libraries and dependencies are handled across projects and libraries, but that's a cost that I'm willing to pay, and in practice it actually isn't that much of an issue when using languages like C and C++.
I'd much rather spend a few seconds specifying "-I" and "-L" and "-l" options when compiling or linking than trying to remember a bunch of conventions or how the high level package names end up mapping to the installed modules or libraries.
I'm not saying that the C approach is perfect, or that I'd want other languages to use a C preprocessor like approach of actually combining separate source files just prior to compilation or even execution.
But I would really like it if modern languages didn't try to hide the existence of files and directories so much, and didn't try to force conventions on me. I'd rather deal with the very small cost of explicitly telling the compiler where to find dependencies rather than relying on conventions or opaque resolution processes.
> If somebody can get React Native to run on PostmarketOS, then we could start building up an ecosystem of non-walled-garden apps that are compatible with iOS and Android!
What leads you to believe this would actually happen? PhoneGap/Cordova have been around for ages, and they could have already enabled such an ecosystem to have formed, but we haven't seen that happen. Of course, there are other similar technologies out there, too. Even Firefox OS failed, and that was with the backing of Mozilla and its eager community. What's different about this case?
> Does it strike anybody as strange that an operating system is getting worse over time rather than better?
I somewhat expect it, as we've seen desktop OSes come to be influenced by mobile OSes, or worse, as we've seen desktop OSes modified to also act as mobile OSes.
Trying to combine these two very different types of usage into one product, like we've seen with recent versions of Windows and open source desktop environments (like GNOME 3), results in the worst of both worlds.
Even in the case of macOS, where there's at least some separation, the influence from the mobile side can still harm the desktop experience.
I wouldn't consider Servo to be "quite good", at least in its present state.
The Browser.html UI is quite minimal, in the sense that it really doesn't do much at all. It's basically a list of tabs along the right side. I also find it quite laggy, and sometimes it locks up completely. I'm not sure why you think people should be impressed with it.
As for Servo itself, there are noticeable rendering problems with pretty much every web site I've ever tried with it. Even the servo.org home page had rendering glitches when I last tried it several days ago! The scrolling is very broken under macOS. I've also had it crash now and then.
Maybe it will get better in the future. But at this time I'd consider Servo to be pre-alpha quality software. Trying to impress people with it would probably do more harm than good. They'll likely encounter problems with it right away, and it won't leave a good impression on them.
It can't help that Google hasn't released a phone comparable in spirit to the Galaxy Nexus, Nexus 4 and Nexus 5 phones.
We're talking about phones that have a practical size, reasonably good specs, and a $300-$400 price tag.
The Nexus 6 and 6P were impractically sized for many users. Even the 5X was too large.
The Pixel's sizing is perhaps more tolerable, but the price tag is much too high.
People hanging on to a Nexus 5 are out of luck, since it isn't getting Android 7 and beyond. Those with a Nexus 4 are even worse off.
While I'd like to use a newer version of Android, I've yet to find a suitable device on the market. Google filled this niche a few years ago, but their recent offerings are no longer suitable.
I don't know if it's still like this, but when I last tried to create a Twitter account it required a phone number and some kind of verification by phone. That's something I refuse to do.
I can sort of understand requiring that to try to combat the creation of spam accounts, for instance. But it made the service pretty much unusable for me.
Unless it's as easy to create an account there as it is to create one here or at reddit, I'll never bother with Twitter.
It's a similar situation for me. I've used Firefox for a long time, and it currently gives me the least-worst experience of the major browsers. That's probably the only reason I still use it.
I wouldn't say I like using Firefox, though. In fact, I think the user experience has gotten a lot worse for me over time. On more than one occasion I've wanted to move away from it.
Really the only thing that keeps me using Firefox is that none of the other major browsers offer a significantly more compelling experience at this time. I find all of the major browsers to be mediocre at best.
If a better non-Firefox browser did come along, I'd likely switch away from Firefox as soon as I found out about the alternative. I have no real ties to Firefox itself.
We should be careful when comparing the growth or package counts of CPAN and npm. While conceptually similar, they're still very different from one another.
A lot of the npm growth is just the JavaScript ecosystem catching up to where CPAN was ages ago.
Then there are the npm packages that add functionality that's typically included by default with Perl, so there would never really be a need for equivalent CPAN modules.
I think there is much less duplication within CPAN, while it's not unusual to find several similar npm packages that more or less do the same thing.
CPAN modules also tend to be larger and include more functionality, while it's not unusual for npm packages to include just a single function, or otherwise limited functionality. Sometimes several npm packages are needed to approximate the functionality of individual CPAN modules.
That module count graph should perhaps even be treated as worrying. Npm is clearly an outlier compared to every other package management system listed. There's not much suggesting it's inherently better than all of the other systems, either. So it's likely more negative factors, such as an excessive need for functionality, and many duplicate packages, and unreasonably small packages, and so on causing such inflated numbers.
I think you may have misinterpreted what was meant by the "Most certainly use Python3 for any new projects." sentence.
I don't think it's using "Most certainly" in the sense of "Most developers using Python use Python 3 for any new projects.", like you appear to be thinking it says.
Rather, it appears to be saying, "Without any doubt, if you're using Python use Python 3 for any new projects."
It appears to be a statement regarding the suitability of Python 3 for new projects, rather than some quantitative claim regarding the number of users of Python 3.
It describes the various methods that are available, it lists implementations of each, it explains the tradeoffs involved, and so on. Table 25-1 summarizes the information.
Regardless of the database system being used, replication is just inherently complex. There isn't really a one-size-fits-all solution. The method to use depends on the requirements and context of a given implementation.
Funnily enough, Facebook is one of the sites where I've seen these non-technical users have to use the dev tools to make the site usable again!
I think it was a login prompt overlay shown on business profile pages. These users didn't want to log in to Facebook, yet needed to view the business' Facebook page. The overlay would cover a significant portion of the page, without any good way to get rid of it. So the users would use the dev tools to clean up the page, essentially, even if they didn't really know what they were doing.
The dev tools can be very useful to average users, even if they don't use them the same way that developers might.
For example, I know several non-technical users who use the built-in dev tools to remove the annoying overlays that some sites show, but that don't allow to be hidden without logging in or something dumb like that.
These users don't really know what the DOM is, but they do know that they can open the dev tools, click the node selection button, click on the overlay they want to get rid of, press the Delete key, and now they're able to use the site again.
While it isn't exactly a pleasant tool to use, it's not like it's totally broken either. I've used other similar software that was much worse to use than pgAdmin 4 is.
It's slightly better than pgAdmin 3 in some ways, but it's also worse in other ways. Overall, it's mediocre. That might be the underlying problem: it doesn't live up to the high expectations that the rest of the PostgreSQL ecosystem tends to set.
If I had to give it a grade, I'd say it's a B- or a C+. It could be a lot worse, but it could also be a lot better.