Some will say that it’s necessary to balance privacy against security, and that it’s important to find the right compromise between the two. Even if you believe that, a good negotiator doesn’t begin a conversation with someone whose position is at the exact opposite extreme by leading with concessions.
And that’s exactly what we’re dealing with. Not a balance of forces which are looking for the perfect compromise between security and privacy, but an enormous steam roller built out of careers and billions in revenue from surveillance contracts and technology. To negotiate with that, we can’t lead with concessions, but rather with all the opposition we can muster.
> How can open source software be in competition with anything?
Market share is power. Popular open-source projects can, and do, shape the industry. If you believe your trajectory is the right one for the industry, competition matters a lot.
As an example, Mozilla's Firefox was created to compete with Internet Explorer. It succeeded, and now Mozilla is working to defend the open web, so market share is still crucial for Mozilla even today.
I didn't take your use of “documentation” to be so loose, but I agree that it should have an explanation for the use of “magical” in the title. The author has since added an explanation.
That's a good reason to downvote or stop reading, but I question whether attacking the author for having the audacity to publish the post is a good move.
Writing bad articles is a great way to move toward writing good articles.
Writing in the public view is a great way to get feedback on your writing and the subjects you discuss—e.g. corrections, further education, etc. For some people, it also increase the pressure to improve.
Vanity is only one possible reason for writing in the public view, and it's an exercise with large potential gains. Your perspective is entirely off, and you've decided to take an opportunity to attack someone who was either brave enough or indifferent enough to risk being attacked in the first place.
It's a single file. It works with or without the ruby-dependent parallel plugin installations and upgrades. It allows for plugins to be loaded only when they're needed (e.g. only for JS files). That's minimalist.
I switched to vim-plug from Vundle a couple of weeks ago, and I'm in love. Lazy initialization and, if your vim is built with ruby, threaded plugin installations and upgrades. As a bonus, it's beautiful.
It would be a shame for man-millennia of work to be lost, but it would also be a shame for advancement to be stalled by these kinds of concerns. Experimenting with new approaches and ideas, direct competition between projects, excitement over new languages and frameworks. These are all factors that lead to advancing the state of the art.
It's worth being concerned about losing the lessons learned from Qt, but this is a kind of false dichotomy between the old and the new.
With that said, I don't think those lessons will be lost anyway. Qt can't (and shouldn't!) last forever or remain in its current form. C++, though it will live for a long time yet, will eventually fall out of favor, and large sections will eventually be purged from Qt as the project matures. The man-years that went into the portions that were, or some day will be, removed have taught Qt developers and users a great deal.
Qt developers and users will bring knowledge and wisdom to new projects that will compete with Qt (directly or indirectly). Some projects will survive and some won't. Some will be much the same as Qt, while some will be completely different from the start. Conrod, as it happens, is an approach to a different kind of GUI development (see this comment: https://news.ycombinator.com/item?id=8244224).
This, of course, doesn't include developers who do their own things without ever using Qt. Hopefully, they will encounter blog posts and articles about some of those lessons, as well as attracting developers who've learned some of these lessons.
This isn't a case of getting away with reinventing the industry. In this nascent stage, computer science, with all the renegade hackers and developers, is still a necessary occurrence when new languages and frameworks are invented.
As a novice, it took several hours to wade through the configuration files when setting up an IRCd, and additional time to configure services daemons. I also continually run into issues with configuration decisions I made before using the daemon more actively.
While I could have relied on the defaults, I wouldn't trust my users' data with a default configuration. It would be irresponsible at best, and this is even more important to companies.
I assume the the people choosing the methods of communication for startups are capable of learning to use irssi or weechat, but both of those clients take quite a bit time to learn and require significant amounts of customization to make them truly comfortable. It isn't a good business decision to require your teams to learn to use these tools.
Is IRC an acceptable medium for a company? Maybe it can be. Is it wise? Not with tools like irssi.
I wonder which title attracts a larger audience. Maybe confident developers would assume “five things every competent Javascript developer must know” would contain nothing new to them, while “5 tips to become a better Javascript developer” promises to offer something new.
And that’s exactly what we’re dealing with. Not a balance of forces which are looking for the perfect compromise between security and privacy, but an enormous steam roller built out of careers and billions in revenue from surveillance contracts and technology. To negotiate with that, we can’t lead with concessions, but rather with all the opposition we can muster.
http://thoughtcrime.org/blog/we-should-all-have-something-to...