20140724-3 选题

sources/talk/20140724 Best Linux Browsers.md

@@ -0,0 +1,81 @@
+Best Linux Browsers
+================================================================================
+> Pros and cons of the best browsers for the Linux desktop, including Firefox, Chrome and other browsers.
+
+Choosing the best Linux browser for your needs requires just a bit of homework: Web browsers for the Linux desktop have evolved over the years, just as they have for other popular desktop platforms. With this evolution, both good and bad revelations have been discovered. Revelations from new functionality, to broken extensions, and so forth. In this article, I'll serve as your guide through these murky waters to help you discover the best in Linux browsers.
+
+### **Firefox** ###
+
+– [Firefox][1] has long been a friendly browser for Linux users. Accessible on both 32bit and 64bit Linux installs, Firefox also offers extensive extensions to choose from. It's a fast loading, easy to navigate Web browser that has found itself in a popular place with Linux users.
+
+**The good**: It's easily installed from most common Linux software repositories, if not already installed on the distro by default. Thousands of extensions to choose from to make your Firefox browser more fully featured. Nearly every website on the Web (including government and banking sites) render properly.
+
+Also important: Firefox respects your privacy. In addition to a straight forward privacy policy, they're not in the "same business" as Google. Therefore, most users feel more comfortable allowing Firefox to see their daily browsing activities whereas other browsers, might have more profit-driven interests. Firefox is also great for web developers, thanks to its element inspection tool, built right into the browser.
+
+**The bad**: Not too long ago, I was finding that Firefox's frequent updates were breaking my extensions. This meant I needed to verify that my favorite extensions were compatible with new Firefox updates BEFORE I updated my browser.
+
+To be blunt, this caused me to rethink which browser would be my default tool to browse the Internet. In fairness, Mozilla does post a blog post with each browser update for extension developers. In these posts, developers are told what has changed and what needs to be done to keep things working smoothly.
+
+### **Chrome/Chromium** ###
+
+– Google promotes its browser named [Chrome][2], however I tend to put [Chromium][3] into the same group as Chrome since Chromium is used as its base for development. Unlike Firefox, Chrome/Chromium was late to the game for Linux. Linux users only considered it worth trying at the time due to the fact that Chrome/Chromium was perceived by many as being the fastest browser.
+
+**The good**: Even today, Chrome/Chromium is considered pretty fast. Even with the recent updates made to other competing browsers, Chrome/Chromium hasn't lost its speed. Extensions for Chrome/Chromium are plentiful and even better, updates to the browser have no affect on said extensions. This means that, unlike Firefox, I haven't dealt with extension incompatibilities. Like Firefox, Chrome/Chromium also has an element inspection tool, built right into the browser. After trying syncing options with other browsers, only Chrome/Chromium has proven itself to be truly idiot-proof. Without question, Chrome/Chromium syncing is the best in the browser space, from my perspective.
+
+**The bad**: Chrome/Chromium doesn't always render pages correctly. Be it rare, some sites like Ebay don't always render correctly. Case in point, if I create a new Ebay submission, I find there are buttons missing in some cases. I've also found that sometimes Chrome/Chromium can lockup completely if an open tab is rendering heavy script. Sites like Google Plus and Facebook are the most common offenders.
+
+### **Qupzilla** ###
+
+– When it comes to lightweight browsers, I've found [Qupzilla][4] to be among the most awesome. Based on Webkit, it provides decent rendering support while maintaining a very small resource footprint.
+
+**The good**: Qupzilla is ideal for lightweight desktop environments where you need a modern browser capable of rendering pages correctly and generally providing a solid web browser experience. It's extremely lightweight and will run on older PCs without missing a beat. Access Keys and [GreaseMonkey][5] extensions are installed (but disabled) by default.
+
+Like Firefox and Chrome/Chromium, Qupzilla provides access to an element inspection tool as well. And finally, having [Adblock][6] installed by default makes this a clear lightweight winner for me.
+
+**The bad**: HTML5 video doesn't seem to work reliably. Also, in order to watch Flash videos, you must visit the preferences and uncheck Click to Flash in the Extensions, Webkit plugins area. This is a poorly thought out decision to essentially disable Flash out of the box, while HTML5 video remains completely broken.
+
+### **Midori** ###
+
+– I like to call [Midori][7] the lightweight Chrome alternative. Like Google's browser(s), Midori offers a minimalist experience with its "hamburger menu," which is nice as it takes up less browser space. Not only do you get a solid browsing experience without the usual browser politics found elsewhere, Midori is also quite fast.
+
+**The good**: Midori is fast, lightweight and feels familiar out of the box. I'm also happy to report that it renders pages correctly and works great with sites like YouTube. The best part, in my opinion, is the built-in functionality for creating browser profiles and actual launchable links for Web apps. For example, you can easily create a web app on your desktop for Gmail or Facebook. You can also setup user specific browser profiles as well, without creating new Linux user accounts.
+
+**The bad**: Despite mentioning user extensions for this browser, the selection available is less than impressive. Also, the browser layout takes a bit of getting used to. A trash can for previously visited websites – seriously?
+
+### **Opera** ###
+
+– [Opera][8] has long been one of the misunderstood browsers out there. Very early on, Opera provided Linux support despite being dismissed by the overall Linux community. In addition to being a compatible, fast web browser that has been nothing but good to Linux users, it's also a full of configurable options.
+
+**The good**: It's fast and it's full of user controllable settings. You can import and export everything from RSS feeds to email, and skin Opera with easy access to breathtaking themes. Plus, Opera offers an extensive library of extensions to choose from. Not to mention the ability to read RSS feeds and email, from your browser! Relive the days of the Mozilla Suite by using Opera's extended suite functionality. And perhaps best of all, Opera Turbo – super-charge your browser speed with selective compression to provide a faster experience.
+
+**The bad**: A nag for the Terms of Service on its first run. Also, Opera Turbo can slightly alter your browsing experience – YouTube for example, may not show a video's thumbnail. Opera also provides so many options that it can feel a bit overwhelming to the casual user. And lastly, it's a closed source browser that hasn't been well recognized for desktop use. Most folks think of Opera as a mobile browser only these days.
+
+### Which browser is right for you? ###
+
+With so many great choices, it can be a tough call to say which browser is right for you. Speaking for myself, I've found that I rely heavily on Firefox and Chromium due to specific extensions I put to work each day. For someone with a lower end system or netbook, my suggestion is to try Midori first and if that's not a fit, fallback to Qupzilla.
+
+So what about other web browsers for Linux? Such as the [Epiphany][9] browser or [Konqueror][10]? Browsers like these are great, but I feel strongly about the browsers I've shared above specifically. Each of the options listed above are browsers I use often and have found to be something I feel good about recommending to friends and family.
+
+That said, by all means, share any browsers you're passionate about in the Comments below so others can benefit from your preferred method of browsing the Web.
+
+--------------------------------------------------------------------------------
+
+via: http://www.datamation.com/open-source/best-linux-browsers-1.html
+
+原文作者：[Matt Hartley][a]
+
+译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
+
+[a]:http://www.datamation.com/author/Matt-Hartley-3080.html
+[1]:https://www.mozilla.org/en-US/firefox/new/
+[2]:https://www.google.com/intl/en_us/chrome/browser/
+[3]:http://www.chromium.org/
+[4]:http://www.qupzilla.com/
+[5]:https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
+[6]:https://adblockplus.org/
+[7]:http://midori-browser.org/
+[8]:http://www.opera.com/
+[9]:https://wiki.gnome.org/Apps/Web
+[10]:http://www.konqueror.org/

sources/talk/20140724 diff -u--What is New in Kernel Development.md

@@ -0,0 +1,45 @@
+diff -u: What's New in Kernel Development
+================================================================================
+Once in a while someone points out a POSIX violation in Linux. Often the answer is to fix the violation, but sometimes Linus Torvalds decides that the POSIX behavior is broken, in which case they keep the Linux behavior, but they might build an additional POSIX compatibility layer, even if that layer is slower and less efficient.
+
+This time, *Michael Kerrisk* reported a POSIX violation that affected file operations. Apparently, reading and writing to files during multithreaded operations could hit race conditions and overwrite each other's changes.
+
+There was some discussion over whether this was really a violation of POSIX, but ultimately, who cares? Data clobbering is bad. After Michael posted some code to reproduce the problem, the conversation focused on what to do to fix it. But Michael did make an argument that "Linux isn't consistent with UNIX since early times. (E.g., page 191 of the 1992 edition of Stevens APUE discusses the sharing of the file offset between the parent and child after fork(). Although Stevens didn't explicitly spell out the atomicity guarantee, the discussion there would be a bit nonsensical without the presumption of that guarantee.)"
+
+Al Viro joined Linus in trying to come up with a fix. Linus tried introducing a simple mutex to lock files so that write operations couldn't clobber each other, and Al offered his own refinements that improved on Linus' patch.
+
+At one point, Linus explained the history of the bug itself. Apparently, once upon a time the file pointer, which told the system where to write into the file, had been locked in a semaphore so only one process could do anything to it at a time. But, they took it out of the semaphore in order to accommodate device files and other non-regular files that ran into race conditions when users were barred from writing to them whenever they pleased.
+
+That was what introduced the bug. At the time, it slipped through undetected, because that actual reading and writing to regular files was still handled atomically by the kernel. It was only the file pointer itself that could get out of sync. And, because high-speed threaded file operations are a pretty rare need, it took a long time for anyone to run into the problem and report it.
+
+An interesting little detail is that, while Linus and Al were hunting for a fix, Al at one point complained that the approach Linus was taking wouldn't support certain architectures, including *ARM* and *PowerPC*. Linus' response was, "I doubt it's worth caring about. [...] If the ARM/PPC people end up caring, they could add the struct-return support to gcc."
+
+It's always interesting to see how corner cases crop up and get dealt with. In some cases, part of the fix has to happen in the kernel, part in GCC and part elsewhere. In this particular instance, Al felt the whole thing could be done in the kernel, and he was inspired to write his own version of the patch, which Linus accepted.
+
+*Andi Kleen* wanted to add low-level CPU event support to *perf*. The problem was that there could be tons of low-level events, and it varied widely from CPU to CPU. Even storing the possible events in memory for all CPUs would significantly increase the kernel's running size. So, hard-coding this information into the kernel would be problematic.
+
+He pointed out that the *OProfile* tool relied on publicly available lists of these events, though he said the OProfile developers didn't always keep their lists up to date with the latest available versions.
+
+To solve these issues, Andi submitted a patch that allowed perf to identify which event-list was needed for the particular CPU on the given system, and automatically download the latest version of that list from its home location. Then perf could interpret the list and analyze the events, without overburdening the kernel.
+
+There was various feedback to Andi's code, mostly to do with which directory should house the event-lists, and what the filenames should be called. The behavior of the code itself seemed to get a good reception. One detail that may turn out to be more controversial than the others was Andi's decision to download the lists to a subdirectory of the user's own home directory. Andi said that otherwise users might be encouraged to download the event-lists as the root user, which would be bad security practice.
+
+Sasha Levin recently posted a script to translate the *hexadecimal offsets *from stack dumps into meaningful line numbers that pointed into the kernel's source files. So something like "ffffffff811f0ec8" might be translated into "fs/proc/generic.c:445".
+
+However, it turned out that Linus Torvalds was planning to remove the hex offsets from the stack dumps for exactly the reason that they were unreadable. So Sasha's code was about to go out of date.
+
+They went back and forth a bit on it. At first Sasha decided to rely on data stored in the System.map file to compensate, but Linus pointed out that some people, including him, didn't keep their System.map file around. Linus recommended using /usr/bin/nm to extract the symbols from the compiled kernel files.
+
+So, it seems as though Sasha's script may actually provide meaningful file and line numbers for debugging stack dumps, assuming the stack dumps provide enough information to do the calculations. 
+
+--------------------------------------------------------------------------------
+
+via: http://www.linuxjournal.com/content/diff-u-whats-new-kernel-development-0
+
+原文作者：[Zack Brown][a]
+
+译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
+
+[a]:http://www.linuxjournal.com/user/801501