epoch1970
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.
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.
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.
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.
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 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.
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?
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.
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.
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 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.
They don't want it there at all, in any way. They don't want it using any of their computing resources, no matter how minute this usage might be.
They tend to see it as something that should be available as an add-on that's installed on-demand by those who actually want the functionality.
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.
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 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.
I've seen this cause MySQL query authors to use various workarounds that end up impacting the query performance negatively.
https://www.postgresql.org/docs/current/static/different-rep...
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.
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.
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.
So even with pdf.js present, I end up using a proprietary reader most of the time. The added hassle or reopening PDFs in a separate reader most of the time exceeds the supposed convenience of the reader being built in.
Only now do I see the blog article, and a submission here [https://news.ycombinator.com/item?id=11661056] that got no traction. I don't remember seeing any sort of a notice on the main Rust web site.
The fact that many participants were excluded, albeit unintentionally, makes me really question the completeness, and hence the validity and usefulness, of this survey data.
The instability of the pre-1.0 days left a very bad impression on many people who tried Rust then. They came to know Rust as a compile-today-but-not-tomorrow kind of language. What, if anything, is being done to try to inform these people that the situation has changed, to encourage them to try Rust again? What's being done to restore Rust's reputation?
If this actually is their strategy, is it being done voluntarily or out of necessity? I ask, because I've witnessed enough scepticism about Rust from C and C++ programmers. Rightly or wrongly, there are enough of them who don't appear to be receptive to Rust, and likely never will be. So the Rust community may never be able to appeal to these C and C++ programmers, even if they wanted to. The only option may be to appeal to the non-C and non-C++ programmers.
Various versions of Windows are used on probably 90% or more of desktops and laptops, in both home and business settings. It still sees widespread server use.
Word, Excel, PowerPoint and Outlook are widely used.
SQL Server is quite common within many enterprises.
Azure is a major player, and is seeing more and more adoption.
The porting of .NET to Linux and OS X is making Microsoft's development technologies available to a wider audience.
The Xbox brand of consoles is quite popular.
Microsoft has numerous offerings, across a range of sectors, that have huge uptake and are quite successful. I don't think that "irrelevance" is the way to describe Microsoft or their products.
When somebody wants to use zsh instead of bash, it's not described as "bash hate".
Or when somebody wants to use Clang/LLVM instead of GCC, it's not described as "GCC hate".
Or when somebody wants to use PostgreSQL instead of MySQL, it's not described as "MySQL hate".
Yet when somebody wants to use some other init system instead of systemd, it is described as "systemd hate".
Why are so many systemd supporters fixated on this vague concept of "hate"?