CVE-2015-0311 – Adobe Flash Player Remote Vulnerability - <AUTHOR> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0311

<comment><USER2> Chrome users: keep in mind that the builtin "click to play" is not actually a security boundary:

[https://crbug.com/174963](https://crbug.com/174963)

Therefore the recommendation, if you can't disable Flash entirely, is choose "Block by default" in Chrome's plugin settings so that you have to right-click and "Run This Plug-in" when you really want Flash to play. You can still whitelist if you want.

<comment><USER3> Ahh crap. Thanks for this. I did not realize click-to-play was so pointless.

<comment><USER4> Me too. I am every day more appalled by the lack of security of browsers. That being said, logically, if you also have javascript disabled, I presume click- to-play should be secure.

</comment></comment></comment><comment><USER5> Disabled ALL plugins on Chrome about a month ago and barely noticed any change. Seriously advice everyone in favor of disabling all plugins now. [Edit] chrome://plugins/

<comment><USER6> When I switched to Firefox from Chrome, Flash didn't come with it, and I left it like this. In the very rare case, I pop open IE or Chrome. Works great!

<comment><USER7> Agreed. Oddly enough, one of the only website I have to open Chrome (which has Flash installed) for is ... Google Music. It has an HTML5 setting, but that seems to do nothing.

<comment><USER8> As far as I know, the HTML5 option for Google Music does work in most browsers, but not Firefox.

Apparently this is because it needs MediaSourceExtensions with HTML5 MP3 support, neither of which are in Firefox currently - [https://bugzilla.mozilla.org/show_bug.cgi?id=911837](https://bugzilla.mozilla.org/show_bug.cgi?id=911837)

</comment></comment></comment></comment><comment><USER9> Apparently(1) EMET prevents this Flash vulnerability from working. Might be time to install it from (2) with the extra "Popular Software" settings on your own PC and any you control.

(1) [https://twitter.com/SwiftOnSecurity/status/55846182290312806...](https://twitter.com/SwiftOnSecurity/status/558461822903128065)

(2) [https://technet.microsoft.com/en- us/security/jj653751](https://technet.microsoft.com/en-us/security/jj653751)

<comment><USER10> "InfoSec Taylor Swift" (@SwiftOnSecurity) is a parody account, and I wouldn't trust it on whether EMET prevents this vulnerability or not. Not saying that it doesn't, just that we'd need more serious sources on that.

<comment><USER11> Swift on Security tends to be surprisingly on the pulse with respect to this sort of stuff. Of course check a second source but don't write Tay Tay off right away!

I'd love to know who runs it.

<comment><USER12> It's not too hard to figure out. He/she's on Twitter and admits that he/she hasn't been great with the OpSec. :-)

</comment></comment></comment></comment><comment><AUTHOR> Note: under Windows, Chrome will install Flash by default, so it's not enough to uninstall the standalone Flash Player. The latest Chrome has Flash 22.214.171.1247, which _is vulnerable_.

If you use Chrome, and want to be safe, go to about:plugins, and disable it manually.

Under Linux the latest is 18.104.22.168, which is not vulnerable (but I'm using Chrome 40.0.2214.10 beta, so YMMV).

<comment><USER13> I thought that the latest Flash for Linux was 11.2. Where did you get v 15 from? Thanks.

<comment><USER14> I think it was the version bundled with Google's Chrome browser being referred to, and not the standalone Adobe Flash Player for Linux, which is quite old now.

<comment> experimental- It isn't actually very old – not much older than current releases on other supported platforms, because quite often security bugs affect it as well, and Adobe updates it as well.

Adobe has promised to support the NPAPI Linux plug-in for a few more years (IIRC till 2017). It doesn't get any new features, but security issues will be fixed, usually at the same time as on other platforms.

</comment></comment></comment></comment><comment><USER15> NOTE: Adobe Flash Player 11.2 will be the last version to target Linux as a supported platform. Adobe will continue to provide security backports to Flash Player 11.2 for Linux. [http://i.imgur.com/A5IFIBF.png](http://i.imgur.com/A5IFIBF.png) Source: [http://get.adobe.com/flashplayer/](http://get.adobe.com/flashplayer/)

<comment> experimental- Note that Google provides newer versions of Flash player for Linux with alongside Chrome. That version works on any browser that supports the Pepper plug-in interface (currently Chrome/Chromium (+forks)/Opera/? – and not Firefox).

</comment></comment><comment><USER16> And what is funny is that I noticed this morning some users with admin privs (long story) were ahead of my already delayed patching schedule (I am not in the US). Adobe has a distribution page for companies to deploy Flash and other stuff internally with "enterprise-y" installers, and I had to refresh until like mid-afternoon local time to see 188.8.131.526 and wondered if it was laziness or rushing.

Well, question answered.

</comment><comment><USER17> Following on from [https://news.ycombinator.com/item?id=8942395](https://news.ycombinator.com/item?id=8942395), is Firefox affected when click-to-play ("Ask to Activate" in Firefox terminology) is enabled?

</comment><comment><USER18> Shame on you Adobe! Yet another hole in Flash, isn't it time to pack up your tent and move onto the dust bin of history?

Furthermore it's more shameful to release an update for the manual update users two days after the automatic update users get it. Get over yourselves already. This is already being exploited, push fixes out faster or atleast at the same time.

Steve Jobs was so right.

<comment><USER19> They are certainly not going to bin themselves, we have to do it for them.

Uninstall flash, and refuse to reinstall it. And see if your nontechy friends and relatives will let you do the same to protect them as well.

There are a lot of sites that have multiple streaming options, but when flash is installed it's what they default to.

<comment><USER20> And are you going to bin Apple and Microsoft too? Not going to use USB? Not going to DNS? What hardware and software do you use that had no security flaws in the last year?

<comment><USER21> This is not the point. When you definitely can do something, you should do it. Other problems should not distract you from removing this particular software.</comment></comment></comment></comment>


Show HN: Easily split large CSVs for free - <AUTHOR> https://www.splitcsv.com <comment><AUTHOR> Hey HN, we built splitcsv.com to handle extremely large CSV files that break excel and other desktop programs. Give it a try and give us some feedback!</comment>


More clarifications from Dropbox blog - <AUTHOR> http://utestme.com/dropbox-tos-update-update/

<comment><USER2> Flagged for being content-free and not even linking to the post in question.</comment>


Maintainers Matter: The case against upstream packaging - <AUTHOR> http://kmkeen.com/maintainers-matter/ <comment><USER2> I agree with a lot of this. GNU/Linux distros are going down a very dangerous path with Snappy, Docker, Flatpak, Atomic, etc. I think a lot of this is responding to the fact that traditional systems package managers are quite bad by today's standards. They are imperative (no atomic transactions), use global state (/usr), and require root privileges. Snappy and co. take the "fuck it, I'm out" approach of bundling the world with your application, which is terrible for user control and security. Instead, I urge folks to check out the functional package managers GNU Guix[0] and Nix[1], and their accompanying distributions GuixSD and NixOS. Both Guix and Nix solve the problems of traditional systems package managers, while adding additional useful features (like reproducible builds, universal virtualenv, and full-system config management) and avoiding the massive drawbacks of Snappy and friends.

[0] [https://gnu.org/s/guix](https://gnu.org/s/guix)

[1] [http://nixos.org/](http://nixos.org/)

<comment><USER3> As a happy nixos user, I have to say that it's conceptually great, but that right now, the management tools are abysmal. Not only are the command line utilities unintuitive to use and pretty slow, but there is simply no graphical frontend, which means that I'm unable to switch family members to it.

<comment><USER4> Your complaints have been heard, and there are a lot of efforts to address them :)

There's currently an effort to make the command line utilities easier to use[0]. There's also an effort to bring PackageKit to NixOS, which should make a few GUI package managers work[1].

[0]: [https://github.com/NixOS/nix/issues/779](https://github.com/NixOS/nix/issues/779) [1]: [https://github.com/NixOS/nix/issues/233](https://github.com/NixOS/nix/issues/233)

<comment><USER3> That's really good to hear, I'm looking forward to it.

</comment></comment></comment></comment><comment><USER5> I feel like this article is sort of attacking a straw man.

> The promise: Sandboxing makes you immune to bad ISVs. The reality: It > protects you from some things and not others.

Well yeah, but the same could be said of maintainers. Maintainers let things through all the time, and sometimes they _cause_ problems (hello, Debian weak keys).

The reality is a bit complicated, and it boils down to something boring like: if the maintainers are better than upstream, maintainers are good, and if they are worse than upstream, then they are bad. But that is both tautological and vacuous, so it is not especially useful insight.

The real insight is this: there just aren't enough maintainers to go around. Debian has 1500 contributors and 57,000 packages, which is 38x as many packages as people. Now maintainers have a lot of tooling to make that more tractable, and upstream developers have their time split between multiple packages too, and some packages are important enough to get the attention of several maintainers fulltime. But do we really believe 1/38th of a person is judiciously considering how to overrule upstream's decisions, attentively investigating user bug reports, and so on?

More likely, the maintainers do not even _claim_ to be doing that, because they have not packaged the software at all. I use lots of unpackaged software; until recently nobody was packaging Chromium for example. Java packaging is really unreliable. And so on.

Ultimately, Ubuntu Snap exists because there is a lot of unpackaged software, and a lot of software packaged poorly. It would be nice if we could wave a magic wand and get 38x more maintainers, but we cannot.

<comment><USER6> > sometimes they cause problems (hello, Debian weak keys).

> until recently nobody was packaging Chromium for example.

To name one example, SlackBuilds.org has had Chromium since 2010, although admittedly that's not so long ago as the Debian weak key cockup, which was 2006.

Maybe your examples could use an upgrade to the latest stable version.

<comment><USER5> Chromium may have been packaged in 2010, but it was _released_ three years before. The Debian weak keys "cockup" may have been _created_ in 2006, but it was _discovered_ two years later. Maintainers had long windows of time to add value. Did they?

I don't mean anything personal by it. If I was maintaining 38 packages on my nights and weekends I'd do a bad job too.

But examples don't go out of date unless you present some force that takes 30k unmaintainable packages and turns them into 50k maintainable packages. What specific advance in software maintenance do you believe improved the art of software maintenance by an OOM?

But if you want to talk recent examples, we could talk about how nobody's packaging Swift.

<comment><USER7> Chromium only became compatible with linux in 2010. [https://googleblog.blogspot.com/2009/12/google-chrome-for- ho...](https://googleblog.blogspot.com/2009/12/google-chrome-for-holidays-mac- linux.html)

Arch Linux packaging files have source history going back to then as well.

Chromium is also an example of a package that took a long time to appear in other distros, because it's really written with the app mindset. It copies and incompatibly customizes most of its dependencies. No one would consider that a great idea for ongoing maintenance and security patching for a typical project, but of course this is a google product-oriented thing with nearly a thousand well-above-average-skill developers assigned, so it's not a problem for them to manage surprisingly huge volumes of code and changes.

Web browsers like Chromium are also a good example of the kind of modern software which doesn't work well with the debian release model, because it's "unsupported and practically broken" in like half a year. That's not true for the "make" utility, or for gimp or inkscape or libreoffice or audacious or countless other useful applications and tools which are not browsers.

I really don't like the fact that modern browsers are a crazy-train and there's just no getting off it.

<comment><USER8> Yeah Chromium is a mess. To get and build the source you first have get the special tool set they use from their git repo.

</comment></comment></comment></comment></comment><comment><USER9> This seems like an overly optimistic view of the abilities and resources of distribution package maintainers. The reality is that no matter how hard they try, it's almost impossible for them to keep up, and even with a non-LTS Ubuntu release train I _still_ need to use a number of PPAs and other mechanisms of install to get some things I use on a daily basis.

And that's with both Canonical and Debian's resources involved in making sure that I get a relatively up to date base set of packages.

Never mind the issue of when your politics don't quite align with any distribution maintainer's in the whole.

(Note: edited to clarify 'bleeding edge ubuntu' as meaning the non-LTS release train)

<comment><USER10> When you serve out an entire system for a group of diverse users with lots of installable programs, it's important to ensure that parts will work together. Especially in Unix where namespace clashes in /bin, /lib and /etc may cause serious problem for system administrators and users. Thus, every stable release has to ensure that none of provided software shall do nothing nasty.

But with bleeding edge, you lose the control over this. It may be worth it for some users, and not for some others. That's a trade-off, and I myself am at the maintained-package-repo+use-only-stable-releases side; thus I use FreeBSD. Debian and Ubuntu mainly provide stable server OSs, so they're on my side too. If you want bleeding edge software, you should migrate to an OS that provides bleeding edge software, tho should know that it's called bleeding edge is called bleeding for a reason. An OS that has to release a version that'll be stable for the coming five years simply cannot provide bleeding edge packages.

<comment><USER11> > An OS that has to release a version that'll be stable for the coming five > years simply cannot provide bleeding edge packages.

Wanting software more than every five years is hardly "bleeding edge".

<comment><USER10> If what you have is fine and works, why want new software? And if you want more frequent updates, you can (a) use a faster-moving branch, which BTW Debian and Ubuntu have; or (b) switch to an OS that provides you with more recent software, e.g. Arch Linux, Manjaro, Gentoo (? not that sure about this last one). Declaring sth. stable takes time, especially if you also incorporate new stuff into it. Even after five years of development, Debian and Ubuntu release patches, because of errata in their releases.

But if you want secure, stable OS that wont drop the eggs, and also rolling release, well, nobody can do anything about it.

<comment><USER12> I don't want to switch to ubuntu-devel or sid just to get a new version of VLC.

I just did a `snap install vlc` and got a recent version of vlc without having to upgrade my entire operating system.

<comment><USER10> That's OK. Nobody has an objection that you do it that way. It's just that there are acceptable flaws and shortcomings for some use cases, and some OSs care more about those.

</comment></comment></comment></comment></comment></comment><comment><USER13> While I agree with a lot of this as well, I feel like downstream packaging has a lot of issues.

I'm working on a project (licensed under the GPLv3) and I have decided to be my own maintainer, i.e: building and distributing packaged versions of my project all by myself:

1\. my project is young and unknown, I have no choice but to package it myself (I really like AUR by the way);

2\. it lets me write and maintain step-by-step documentation;

3\. it allows me to enforce a consistent interface for my project across operating systems, I know my project can be used the exact same way on any operating system I have packaged it for;

4\. I have had bad experiences with maintainers having no idea what they are doing and completely breaking my software;

5\. It allows me to build a full release pipeline including both source and binary releases.

The first point is sort of a big deal, having packages is important to drive adoption, therefore I need to invest my time in that. I'm not gonna wait for some random folks to package it a few years down the road (if that ever happens).

My work is not incompatible with downstream packaging, but I do intend to work closely with (or directly maintain) any downstream package.

I really feel like this is sort of a catch-22.

<comment><AUTHOR> I presume you mean lightsd. Nifty stuff. What do you think of Suse's OBS? I believe you're squarely in its target audience.

And hats off to you for going the extra mile for your project! Your PKGBUILD even looks quite good. Would you like some assistance in writing a -git pkgbuild for people who want to try the absolute newest commit?

<comment><USER13> Thank you! Yes, I was referring to my work on lightsd.

I didn't know about Suse's OBS until this thread, I guess I need to look into it. I have been building my own CI/CD pipeline on top of Buildbot so far. It's a PITA, but leaves a lot of room for creativity, hopefully it will be rewarding down the road.

I don't know about the -git thing for PKGBUILD, what's the syntax/documentation?

<comment><AUTHOR> It is briefly mentioned in the manpage, [https://www.archlinux.org/pacman/PKGBUILD.5.html](https://www.archlinux.org/pacman/PKGBUILD.5.html), but basically a pkgbuild can use a git repo as a source directly. Here's an example:

[https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pacma...](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pacman- git)

Compare it to pacman's release-based pkgbuild:

[https://git.archlinux.org/svntogit/packages.git/tree/trunk/P...](https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/pacman)

The major differences are the "git" url in the sources, the provides/conflicts metadata and the dynamic pkgver() function.

<comment><USER13> Nice, maybe I'll consider this for dogfooding, thank you for the explanations!

</comment></comment></comment></comment></comment><comment><USER14> Preface:

1\. I use Arch Linux for my desktop and I like it.

2\. I hate docker's repository systems (and other upstream packaging)

But this article writer sure is putting the maintainers on a pedestal.

 __ _More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support overhead. Non-bugs are caught and filtered out. Low-quality bugs reported to the distribution 's tracker often becomes a good bug when the maintainer reports it upstream.

...

Maintainers also shield users from developers, offering a layer of quality control...choosing a subset of the (subjectively) best software FOSS has to offer. Maintainers will disable features that they feel act in bad faith. Maintainers' greatest power is the ability to outright say "This is not good enough for our users" ___

Really? Then what about this poor sap who had the misfortune of releasing one buggy minor version, and is now forced to support that for the next 5 years even though the bug was fixed in the next version?

[https://news.ycombinator.com/item?id=11452432](https://news.ycombinator.com/item?id=11452432)

The maintainers actively tried to sabotage his attempts to tell people to upgrade to a new version in the name of 'consistency.'

Sure, consistency is great, but only if we (the maintainers) don't have to do any work (such as backporting). We offload all the supports to the developer and have him do support work for us. Then when he complains we will call him a whiner and laugh him off...

<comment><USER15> _The maintainers actively tried to sabotage his attempts to tell people to upgrade_

Ah, poor maintainer. Releasing software with a self-destruct timer is not an acceptable way to "tell people to upgrade".

<comment><USER16> No, but it's an effective way to say "f __k you " to stubborn/lazy/backwards maintainers and/or distros who wont update.

<comment><USER17> Yes, those pesky stable distributions that prioritise bug fixes are clearly to blame. While it might be annoying for _you_ (and me to some extent), some people actually need to have a stable system. If I was installing a GNU/Linux distro for a family member I would pick Debian or openSUSE Leap over a more rapidly updating distribution -- I just got burned by such a distro yesterday and I'm still reinstalling my machine.

<comment><USER16> > _While it might be annoying for you (and me to some extent), some people > actually need to have a stable system._

If desktop packages like the XScreensaver is what makes your system unstable, then you have worse problems...

</comment></comment></comment></comment></comment><comment><USER18> Personally I think Nix ([https://nixos.org/nix/](https://nixos.org/nix/)) does this right: packages are easy to install and upgrade for users, and developers and maintainers can easily create and update them. And if someone does not like the default collection of packages, it is as easy as starting one from scratch, or forking the existing one on GitHub, but at least it doesn't require reinventing the entire system.

<comment><USER8> Pretty much.

The base problem is not ISVs or maintainers. But that the rigidity of the package managers force maintainers to either use one version of a lib for the duration of the distro version, or play musical chairs with the package names to get around conflicts.

Either option makes it hard for third parties to produce packages.

The likes of Nix allows multiple versions of a packages to exist side by side, and ensures that each program gets the version it wants.

This allows a third party package to request a newer version of a lib than the distro provides, as it will not conflict with the distro provided packages while retaining the naming scheme.

</comment></comment><comment><USER17> I cannot agree with this enough. I help package the container tools for openSUSE and SLE (I'm also an upstream maintainer of one of the tools as well, so I see both sides of the picture). But I personally am against ISVs making packages (especially "universal" ones) -- if they want to provide a container deployment method then provide the Dockerfile so people can build and curate it themselves.

It's really frustrating when upstream turns around and says "actually, we provide packages -- not you". In fact, we've had cases where a certain project suggested that a reasonable compromise would be that we _change the name of the package in our distribution to "reduce confusion to users"_. Wat.

However, I do understand their point somewhat. If you have users pinging your issue tracker and they're using distro-supplied packages, then you are getting a lot of noise. But the right way of reporting bugs is to complain to your distribution (we actually live and breathe the distro you're using!) and I feel like upstream projects should make this communication model more clear rather than complaining to distros about users submitting bugs in the wrong place.

EDIT: Thanks for the SUSE shoutout! OBS is pretty cool and the people developing it are pretty cool people too.

</comment><comment><USER19> Yes, upstream vendors would love to have total control over how any user uses its software. But there is no guarantee that at least _one_ of the vendors will not have a really shitty install or uninstall script which will do something like this:

      #!/bin/sh
      DIR=/home/$USER/ftp
      rm -rf $DIR
      rm -rf /home/guest
      adduser guest

.... assuming that /bin/sh is symlinked to bash (it isn't always), assuming $USER exists (it doesn't always), assuming the user 'guest' doesn't already exist with important files to keep... you really don't want to know how many ISVs actually have install scripts like this.

Users can still install ISV-packaged software in distros. But ISV packages typically hurt the system by removing things like vital dependency tracking information, or replace files that other packages provide, or won't be tracked for security patches, or will be installed into non-standard paths.

\--

I have been a package maintainer for 6.. no wait 8... no, 9 Linux distributions. I have created thousands of packages (easily 10,000). I have maintained forked distributions for corporate use. I have also developed dozens of individual software projects which all were designed to be packaged by maintainers, and were adopted into Linux distributions _by somebody else_.

And i'm telling you: Anything other than maintainers packaging software is a fucking nightmare for everyone involved. We have a good system! Devs, make your software so it's easy to package. Maintainers, package it for your particular distro. Users, just use what's in the distro, OR follow the upstream's instructions on installing _at your peril_.

</comment><comment><USER20> Enough of this. People have the right to install last version of software easily without having to upgrade the whole server at once. ISV have the right to package their own software.

If MongoDB is a commodity I can gladly stick to the distro version. If I'm developing something of more cutting edge I want and will install the latest version from the ISV repo.

<comment><USER21> Yes they can, there is nothing preventing them creating the package. But it shouldn't be a primary way of installing package. If you really need bleeding edge for development you can build it yourself.

<comment><USER22> This type of attitude completely ignores regular desktop users who may one day want to use Linux over Windows.

<comment><USER23> A regular desktop user does not want bleeding-edge software; he will do just fine with last year's VLC. (A notable exception being the web browser.)

The priority for a regular desktop user is a nicely integrated system, and that is something that ISVs cannot deliver because they don't know what to integrate with.

<comment><USER8> Except for the security stuff, i think many would be quite happy with last years Firefox, Chrome or even IE.

</comment></comment></comment></comment></comment><comment><USER21> That's really good case about upstream packaging. Do we really want yet another android story? I trust maintainer which is volunteering it's time to ensure the package complies with distributions guidelines.

With universal packages we would have universal config file paths. So for example: apache2 on debian based systems will store documents on /var/www while something like arch will store them at /srv/httpd. Similar thing happens with a `sites-available` accross distros. Different distributions are doing things differently, which users are expecting and putting upstream developers in charge of that will make a huge mess, because it's more convenient for them to store configuration at a specific location accross every distribution. Yes that makes a pain to write deployment scripts accross difrerent distros, but IMO consistensy is a key to a good distribution.

Another good key point here would be testing, different distributions aim for different things, while debian aims for maximum stability and uses quite dated packages that are known to work. Where there are distributions which are always on the bleeding edge. Will upstream backport security patches for old packages? I really doubt they would like to maintain packages for years to come.

I don't say it would be all bad, there certainly would be great developers which would benefit from universal packaging, but that will not always be the case.

</comment><comment><USER11> Linux has never had crap bundled? I guess the author forgot Canonical's "shopping lens" debacle, which was fully as sleazy as any ask toolbar bundling nonsense.

<comment><USER24> that's not the kind of bundling people are talking about.

<comment><USER11> Did you even read the article? That's _exactly_ the kind of thing the author claims distribution maintainers protect users from.

<comment><USER25> "This is why Linux doesn't have spyware, doesn't come with browser toolbars, doesn't bundle limited trials, doesn't nag you to purchase and doesn't pummel you with advertising."

The shopping lens was openly added as a marketed feature, and could be turned off with one action. You could, I suppose, class it as spyware, but it wasn't surreptitiously sideloaded - it was touted as a default feature. It didn't alter the browser, wasn't limited run, didn't nag you, and while I didn't use it much, it could hardly be called 'pummelling with advertising'.

It was an openly-acknowledged experiment that failed, and was removed.

</comment></comment></comment></comment><comment><USER26> In other news: [https://www.nginx.com/blog/supporting-http2-google-chrome- us...](https://www.nginx.com/blog/supporting-http2-google-chrome-users/)

<comment><USER27> Note: It may be worth providing a bit more info about why you are linking the article. It's a relevant example of the counterpoint playing out in real-time, which people may miss from the simple preface "In other news:"

 _To ensure the operating system is stable and reliable, OS distributors do not make major updates to packages such as OpenSSL during the lifetime of each release._

Not entirely true. RHEL backports bug and security fixes continuously, and select feature enhancements are rolled out with point releases. For example, RHEL 7.2 updated mod_nss, and enabled TLS v1.1 and v1.2 in NSS (I'm not sure how that interacts with Nginx, if at all). I imagine RHEL 7.3 should be coming out any time now. Maybe it will help with this.

1: [https://access.redhat.com/documentation/en- US/Red_Hat_Enterp...](https://access.redhat.com/documentation/en- US/Red_Hat_Enterprise_Linux/7/html/7.2_Release_Notes/servers_and_services.html)

</comment></comment><comment><USER28> I don't see the contradiction between Flatpack/xdg-app and keeping packages downstream. [http://openbuildservice.org/](http://openbuildservice.org/) could end building xdg-app images in addition to rpm, deb, Arch and images it already builds. Why not?

That would keep security, reviews & processes while stopping the nonsense of requiring root, global state & single versions rpm/deb enforce to the user.

</comment><comment><USER29> The author's point about "dogfooding" jumped out at me more than he probably intended, but that's probably because it's an aspect of Slackware's SlackBuilds repository (SBo) that I can't say enough about.

Quite often, SBos are maintained by folks who use (even depend) on the software they are responsible for. As such, well-tested and sanely configured software tends to be highly valued by maintainers, and package responsibilities will commonly change hands when a maintainer no longer uses what (s)he's responsible for.

The mechanics of an SBo are also dead simple, making package review and modification by the user straightforward. This means that rolling your own package is straightforward, enabling you to easily become a "dogfooding" maintainer yourself for any package not already in the repo. Few distributions allow ordinary users to close the official package loop with anywhere near the ease--both technically and bureaucratically--that SBos do.

SBos are not the Perfect Package model by any means. But in terms of "dogfooding", ISVs and big distributions (especially Canonical) could stand to learn a few things from a relatively unstructured community of volunteers with a taste for the KISS principle.

</comment><comment><USER30> Unless I'm misunderstanding, I think Chef has been doing this for years with omnibus packages.

The reason we did this is that we had to support RHEL5/6 and old Solaris and AIX distros.

We struggled for several years (and I personally struggled for at least a year) with supporting RHEL5 and it simply failed. That distro came with ruby-1.8.5 and upgrading it to even 1.8.7 was a major PITA. The ruby-1.9.2 in RHEL6 was also buggy and crashy and segfaulty and we didn't remotely have the resources to attempt to debug it and patch it for RedHat.

The reality is that we just wouldn't have been able to support those old distros at all.

I think there's a myth here that the human resources to support packaging and debugging apps against distro-supplied libraries and supporting packages magically appears out of thin air. It does not. As those supporting libraries age it consumes more and more time to support "back porting" onto aging versions of frameworks, which cannot be upgraded in the distro because of compatibility with other apps. That creates a large amount of serious shit work (seriously, nobody enjoys doing that) and open source doesn't make it magically appear.

I also think there's a misconception that user's have chosen to use those versions of software. Largely they've chosen that because they need the compatibility with a large body of their own custom in-house software and their internal porting effort is costly in time and labor. Largely they don't care if you install an upgraded version of supporting libraries so long as it doesn't impact any other running software and its contained.

For another example of software that has been doing this for years, check out vagrant.

Admittedly, there's issues with this since openssl vulnerabilities require the release of new software versions to upgrade the embedded version.

<comment><USER8> I maintain that the best of both worlds is a scheme like Nix or Gobolinux. It allows multiple versions of libs to exist, without having each program come packed with half a distro.

</comment></comment><comment><USER31> The case against distro packaging:

\- Desktop Linux has a small user base. Further splitting it up with different packages for each distribution makes it further a non-target.

\- You can only install software cleanly that is packaged by your distributor. No distributor packages software that costs money. Many distributors try to prevent you from installing software with licenses they don't approve.

\- If your user is using a stable distribution they will have old software. The distribution might only push bug fixes if they are security related. Users will report bugs that are already fixed.

\- Maintainers often have no idea what they're doing, because they aren't working on the project and there are rarely other developers that check their patches. Worst case this leads to something like the Debian random number generator bug.

Distribution packaging for user facing programs has large drawbacks with marginal benefits, which can be mostly broke down to the not invented here syndrome.

</comment><comment><USER32> All true. And yet, Steam is the most used package manager of the linux desktop today and the exact opposite in every single point. If Distros don't adapt they will become just kernel maintainers.

</comment><comment><USER33> Anyone tried 0install?

</comment><comment><USER34> Not to get unnecessarily political, but there is almost certainly an analogy to be drawn here to American federalism and the state v. federal government interplay on behalf of their citizens.

Taking the analogy further, the App Store trend is analogous to the 17th amendment[1] superseding the states' right to appoint senators. The relevant implication being that tribal power inevitably gravitates toward centralization on behalf of the "user."

[1] [https://en.m.wikipedia.org/wiki/Seventeenth_Amendment_to_the...](https://en.m.wikipedia.org/wiki/Seventeenth_Amendment_to_the_United_States_Constitution)</comment>


Samsung Galaxy S III dethrones iPhone 4S as smartphone sales champ for Q3 2012 - <AUTHOR> http://www.engadget.com/2012/11/08/samsung-galaxy-s-iii-dethrones-iphone-4s/?utm_source=twitterfeed&utm_medium=twitter

<comment><USER3> A slightly more accurate headline: "Flagship Android phone beats year old iPhone in sales in the same quarter the newest iPhone was released".

If you add iPhone 5 sales for that quarter to the iPhone 4s sales you get 24 million, 6 million more than for the S III. You have to look at this data with extremely narrowly focused, Android tinted lenses to make this look like any kind of victory for Samsung.

It does show that at last a flagship Android phone is managing to sell in iPhone-like numbers. That's a good thing for Android and for the health of competition in the smartphone market. Samsung are doing well.

<comment><USER4> How is that headline more accurate? The original one clearly states the facts, that the S3 had more sales than the 4S in this quarter, making it the best selling piece of hardware. And the article itself says that this was probably because of the iPhone 5 release.

I don't understand why you're so quick to defend Apple by changing the metric, despite nobody saying that this is any sort of "victory" for Samsung. It's an obvious result of the iPhone 5 release, it will be on top of the charts the next quarter as usual. If you're going to make it an iPhone vs. Android thing then you should compare the sales of all iPhones and all Android phones, you can't pick and choose a few from each category.

</comment></comment><comment><USER5> While the Galaxy S III is doing very well for Samsung, once again the article makes the mistake of comparing "shipped" numbers verses "sold" numbers.

Given that those have been wildly inaccurate in the past (see the evidence in the Apple Samsung trial) it somewhat undermines the point of the article and the title itself.

</comment><comment><USER6> Even if the iPhone4S sales were canabalized by the upcoming iPhone5, its still a major achievement for a single Android phone to come close to the iPhone sales numbers, which is basically one of the most hyped/popular consumer electronic device of all time.

</comment><comment><USER3> Alright, time to burn some Karma because this isn't realy on topic. It's provoked by a few of the comments on the Engadget page. Easy come, easy go.

It seems like the new iPhone that comes out each year being lighter, thinner, faster with a sharper, brighter screen and better build quality and better software than the previous phone, and every other phone on the planet isn't enough. It's boring. There's a sentiment out there that Apple has to do something radically, magically new that delights us with childlike wonder every year on a consistent production line schedule. If they don't, they're a washed up hasbeen that has betrayed Steve Jobs' legacy.

And no, bringing out devices that are lighter, thinner, faster, etc, etc is not radically new. It's what they did last year, and the year before that, ad nauseam. What did they do for is this month, that nobody has ever done before, is all that counts. Don't give us better. Better is next door to mediocre and only a few steps away from bad. So better might as well be bad. We demand magical!

I honestly don't think I'm straw-manning here. Is that not what the "iPhone 5 is boring" brigade mean? I honestly don't know what to say to that. It's kind of hard to comprehend that grown adults can think about things that way. It mainly seems to affect Apple users too, people who have bought Apple products. It's as though they're disappointed and upset that what they got was only an excellent, high quality product.

Note: I'm not saying Apple haven't made missteps. The iOS 6 release with mapping issues and various other niggles has shown that they're not perfect, but then when were they ever? They've always had their fair share of awkward updates and failed products.

<comment><USER7> I believe the major reasons why people were saying "iPhone 5 is boring" is because the iPhone didn't do anything that other manufacturers weren't already doing. iPhone 5 doesn't compete/exist only with other Apple products - <USER2> competes with Android and W7. When you tout your latest phone as 'revolutionary' and it's only adding features that have been on other phones for months already, you're gonna get backlash.

</comment></comment><comment><USER8> Pointless article. Galaxy S III outsold the iPhone 4S because the iPhone 5 came out.

<comment><USER9> Wait a second, is there any reason why the SIII (or any other phone for that matter) _shouldn't_ be able to outsell the iPhone 5?

<comment><USER10> Typically the iPhone sells the most because the whole iOS ecosystem is limited to a few devices. With android there are so many options to chose from that one brand rarely outsells its Apple counterpart even though Android as a whole has a far greater marketshare.

The S3 outselling the iPhone 5 would be a pretty big deal.

</comment></comment></comment><comment><USER11> The article forgot to mention that the Galaxy S III also outsold the iPhone 4 and the iPhone 3GS!

<comment><USER7> Neither of those were top sellers last quarter.</comment></comment>


Meteor 0.4.1: Sending email and Node 0.8 - <AUTHOR> http://www.meteor.com/blog/2012/09/24/meteor-041-sending-email-and-node-08 <comment><AUTHOR> The demos are super slick and make it seem like a huge productivity saver. When I first looked at it, I had to dismiss it on the sole reason that it could not be crawled by Google and therefore not SEO friendly. However with Meteor 0.3.9 (back in August) that problem was solved.

</comment><comment><USER2> I'm loving meteor - one of the more promising javascript based platforms/frameworks in my opinion</comment>


XSS vulnerability in GitLab prior to 6.5.0 - <AUTHOR> http://blog.gitlab.org/xss-vulnerability-in-gitlab/

<comment><USER2> Looks like this is the fix: [https://github.com/gitlabhq/gitlabhq/commit/d6c037de81096680...](https://github.com/gitlabhq/gitlabhq/commit/d6c037de81096680db07397a44a0824355c703c8)

</comment><comment><USER3> CVE and exploit at [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-731...](http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-7316)

</comment><comment><USER4> That's quite surprising, it's a textbook XSS vulnerability. It seems to me that their markdown library should escape entities by default or they will have many other vulns.</comment>


Tuning LAMP systems, Part 3: Tuning your MySQL server - <AUTHOR> http://www.ibm.com/developerworks/library/l-tune-lamp-3.html

<comment><USER2> .. and very good too the Part 1 and 2:

Part 1: Understanding the LAMP architecture

Part 2: Part 2: Optimizing Apache and PHP

<comment><AUTHOR> Here is all of the articles about tuning LAMP systems:

<http://fuseurl.com/94></comment></comment>


Using Blockchain to Short Circuit Recidivism - <AUTHOR> Last summer, I announced the launch of 70MillionJobs, a YC for-profit platform for helping Americans with criminal records find jobs. We've grown our community of active job-seekers to over a million, and have placed hundreds of people in jobs.
Today, I'd like to share that we're launching an ICO in support of our mission.
Corporate America has millions of unfilled jobs, yet they have a negative bias towards hiring people with criminal records. Millions of formerly incarcerated men and women desperately need a job, yet the jobs generally available are frequently awful, paying minimum wage.
Utilizing blockchain technology, we've developed a program that incentivizes companies to hire those with records while simultaneously incentivizing these folks to accept and retain employment, and avoid re-arrest, thereby tackling recidivism head-on.
Our 70M Coin unlocks this potential in an elegant and efficient manner (we believe). For accredited investors, the White Paper is available at 70MCoin.com. Questions? Contact firstname.lastname@example.com <comment><USER2> Mark Hopkins, CTO here. Happy as well to answer any technology questions.

WP Link: [http://www.70mcoin.com/assets/Whitepaper- compressed-4eee04cb...](http://www.70mcoin.com/assets/Whitepaper- compressed-4eee04cb4ced96fbf87db2a0e31758efd0ddec6e75d3763f15f4fb8a11e52409.pdf)

</comment><comment><USER3> Co-author of whitepaper here, welcome any feedback and thoughts! Or questions!</comment>


Trump Cybersecurity Advisors Resign, Citing 'Insufficient Attention' to Threats - <AUTHOR> http://fortune.com/2017/08/26/trump-cybersecurity-advisors-resign/ <comment><USER2> It's a shame everything has gotten so overly politicized nowadays, this is the adult-equivalent of "I'm picking up my toys and going home." The obstructionism and whining has got to come to an end, the election is over and Trump won. Deal with it.

It's time to put aside the grandstanding and political virtue signaling; it's time to put on your big-boy pants, roll up your sleeves, and get to work solving problems. Us versus them has no place here, the stakes are too high. We're all in this boat together.

<comment><USER3> > It's a shame everything has gotten so overly politicized nowadays, this is > the adult-equivalent of "I'm picking up my toys and going home." The > obstructionism and whining has got to come to an end, the election is over > and Trump won. Deal with it.

No. Trump needs to be fought every single day. Democrats won on healthcare because the republicans screwed up, not everything will be that easy.

It's also really fun to hear people whining about obstruction when the republicans control the house, senate, and presidency.

It's also worth noting that the people quitting here wanted to work with Trump and are giving up because they've decided it's not going to work out.

<comment><USER2> "#RESIST"... he quietly scratched into the walls of the cave in total darkness, careful not to make any sound that could alert the hordes of starving mutant cannibals lurking outside.

Sure, after the DPRK caused cyber-911, things would never be the same. All those nuclear plants melted down and millions of people starved to death, but there is always a silver lining, right? At least I got to voice my opposition to Drumf's withdrawal from the Paris Accord and bump my instagram following.</comment></comment></comment>


Show HN: Devlids – Gallery of Stickered Laptops - <AUTHOR> https://devlids.com <comment><USER2> I like it. Assuming you're tagging them manually as they come in. The tagging is super useful for discovering other devs w/similar interests. [https://devlids.com/all/tag:ruby](https://devlids.com/all/tag:ruby) I think it should be highlighted (or at least have some indication that there is tagging somewhere on the landing page). Maybe just list the top tags across the top or something, with a tag-specific page listing all of 'em. Nice work

</comment><comment><AUTHOR> DevLids.com is a gallery of stickered laptops from tech/design/science-related fields.

</comment><comment><USER3> thank you!</comment>


Why Race Relations Got Worse: Our Conversations Are Increasingly Tribalistic - <AUTHOR> http://www.nationalreview.com/article/439431/race-relations-getting-worse-america-why?target=author&tid=997024 <comment><USER2> Unless the underlying economic issues are tackled (basically blacks being hit with a huge economic disadvantage for generations due to racism and issues stemming from it (redlining, segregation, Jim Crow, poorly funded school districts, etc.), race relations can't progress much further.

That's because they are also "class" relations, and US society sees it fit to offend, deride and look down upon the poor. So when blacks are predominantly poorer, the will be looked down.

People are less inclined to be racist to middle class/richer families (and the inverse is the reason that most can be trivially discriminating and offensive against poor white people "white trash", "trailer tress", the homeless, etc -- the poor, even white ones, are fair game for discrimination and abuse).

And this can't be trivialized to "it's 2016, slavery stopped in 1865, they had all the chances to bounce back". Black people alive today, in their 60s, have faced segregation. It's not some ancient history. Their parents faced Jim Crow. They couldn't get job opportunities, study where they wanted, etc.

When parents are held down, their kids wont get the education their white middle class peers afforded for theirs. And that will pass on to the next generation, keeping them poorer. And there has been plenty of racism in hiring decisions, redlining, etc since the 70s to assure this goes on. "Affirmative action" compared to the damages done is a drop in the bucket.

<comment><USER3> That sounds right, but is it right?

If I understand your position correctly then there is no room for the possibility that blacks (or the so called white trash) are getting in their own way. You have to look upon that possibility as a hypothesis to test for. Otherwise we might as well be treating minority group X like our pets instead of being autonomous human beings.

There have existed a great many persecuted peoples in recent history, the Irish, the Jews, the Chinese, the Roma. My race I know did much better abroad than in our home country, evidently institutional constraints were real.

If you don't look at all the data you're going to open to the reasonable accusation of the Texas sharpshooter fallacy.

In my view the question to ask is: Do there exist places on earth where this minority X have better metrics (or subgroups within the population)? Here we ignore genetics and environment questions entirely, we are simply searching for evidence contrary to our (often considered disagreeable in our present culture) hypothesis that the people X are the cause of their own suffering.

If not, then by induction we accumulate evidence in favour of the hypothesis. If so, then there is something that can be changed to improve circumstances.

For what it is worth, it seems clear to me that whenever there exist new frontiers, fresh cultural experiments can take hold and there can be new beginnings, with America itself being an example of that.

Even were it all genetics I would still have some optimism because this is something we can intelligently design around with our technologies, although that line of reasoning is treated as being deeply suspect in our present culture and time. I don't think that can last for much longer though, I and many others see those moral qualms as preposterous as the protests of the anti-vax people.

The last thing I'll say is more subjective, but I agree that class issues are _the_ problem the US and Western countries face today. Had we superior economic growth these could be papered over but we don't have the kind of growth we need for that and so they shall have to be faced head on. Stephen Pinker's book on violence reminds me of the futurists who predicted permanent state of peace before world war 1, I think we're heading into some choppy waters.

<comment><USER2> > _If I understand your position correctly then there is no room for the > possibility that blacks (or the so called white trash) are getting in their > own way. You have to look upon that possibility as a hypothesis to test for. > Otherwise we might as well be treating minority group X like our pets > instead of being autonomous human beings._

I could acknowledge a subgroup of a larger group "causing their own harm". E.g. white trash, or a subgroup of blacks.

On the other hand, I don't see how a group like blacks can in general, and for its majority, "cause its own harm", in a different amount than another group.

Unless there is evidence of genetic differences to cause discrepancies, I would expect both blacks and whites to have similar percentages of people that "cause their own harm" all other things being equal.

Which is not what we see.

But of course, all other things are not equal either. One group was extracted forcefully from their native culture and country and forced to work as slaves for centuries, the other was not. One group faced persistent persecution and specific laws against it until late in the 20th century, the other did not.

<comment><USER3> > On the other hand, I don't see how a group like blacks can in general, and > for its majority, "cause its own harm", in a different amount than another > group.

Alright, I see that to be in error.

Suppose we were talking about sex differences. Feminists frequently point out that men are murderous. They commit almost all murders. Usually of other men. Clearly this is a subgroup in the general population that causes disproportionate problems in an area that another group i.e. women, do not.

I'm not a feminist but I've no trouble or dispute with the notion that men are more violently dangerous than women. We are. It is a fact.

This of course is not an argument to discriminate against all men. Evidently there are different sorts of discrimination. Some wise, some sexist.

> Unless there is evidence of genetic differences to cause discrepancies, I > would expect both blacks and whites to have similar percentages of people > that "cause their own harm" all other things being equal.

That is exactly what conservatives, reactionaries and others do say. They say there is evidence of genetic differences which lead to different outcomes.

This is not a black/white thing by the way, that is just an American-centric example. We could easily talk about Europeans and Japanese people too, Europeans are significantly more likely to be violent than Japanese people.

Of course average rates of violence is not the only criteria on which people should be judged. There are other things humans do besides that!

> But of course, all other things are not equal either.

Right, exactly.

> One group was extracted forcefully from their native culture and country and > forced to work as slaves for centuries, the other was not. One group faced > persistent persecution and specific laws against it until late in the 20th > century, the other did not.

That is true, and yet if I remember correctly poor whites in Appalachia have fewer years of education and lower incomes than poor (predominately urban) blacks.

This is incidentally why I believe class issues are more problematic for America in the future than race. Race has and is been used as a proxy for class and this is failing to make sense of the world as it is.

To put it like this: I see America a big place where a lot of people got jumbled up together in a haphazard fashion. Then over time, and especially in the last century assorted mating has resulted in concentrations of similar people.

Birds of a feather flock together.

It is funny because in Europe the opposite is kind of happening. At least these are my impressions for whatever they are worth.

It does though give a policy prescription for poor people. They could be distributed randomly by family over a wide geographical area.

At least that is one view, I had better stop now before I get called Stalin or Hitler. ;-)

<comment><USER2> Let's lay it out more clearly.

Let (a) => a group can have a much larger subgroup of its members be something X compared to other groups (e.g. more black criminals than whites, more violent Europeans than Japanese, etc.).

Let (b) => an X subgroup is X because of itself ("caused its own harm").

So, I'm not saying (a) or (a)+(b) can't happen.

What I'm saying is that for (b) to hold, the group should have either a genetic reason to be so, or a cultural one, and the cultural one must also be of their own choosing (e.g. not imposed upon them by external pressure/circumstances).

What I'm also saying is I don't see (b) holding for blacks.

I haven't seen evidence (aside from far-right/racist writings) that they have genetic reasons to be more criminal, etc.

And I haven't seen much in their criminality / culture that can't be explained by their status as ex-slaves/racism targets/subjects of racist legislation/practices, etc.

In other words, I think that for (b) to hold, you have to be in control of your destiny/world in a way that slaves by definition are not, and ex- slaves/second-rate citizens arguably are not.

<comment><USER3> > Let (a) => a group can have a much larger subgroup of its members be > something X compared to other groups (e.g. more black criminals than whites, > more violent Europeans than Japanese, etc.).

Sure.

> Let (b) => an X subgroup is X because of itself ("caused its own harm").

It is a tautology.

> What I'm saying is that for (b) to hold, the group should have either a > genetic reason to be so, or a cultural one

Hmmmmm. We agree that there exists a reason for everything. Any subgroup (even My Little Pony advocacy groups) exists for a reason.

Whether in the case of violence and/or criminality it is genetic or environmental is one I'm not going to address here because I think it is too complicated to answer convincingly in one way or another and I think we would be fools to be totally confident an answer without years of study.

> and the cultural one must also be of their own choosing (e.g. not imposed > upon them by external pressure/circumstances).

Violence can be opportunistic because you're a war-like tribe and have spotted a weakness in another tribe. Consider the Mongols attacking Europeans or the Zulu wiping out the Bush people.

Do you consider that an external circumstance or a cultural choice?

Seems like it could be both simultaneously.

> What I'm also saying is I don't see (b) holding for blacks.

Wait, I thought we were talking about subgroups in a subset? Which is it? The group or the subgroup?

> And I haven't seen much in their criminality / culture that can't be > explained by their status as ex-slaves/racism targets/subjects of racist > legislation/practices, etc.

Ok. Well I don't live in the United States, but I can tell you that the same subgroup exists in places that never had a history of slavery e.g. Ireland. We have people directly from Africa who live here, and that same subgroup exists here, freshly minted as it were. That is inside of twenty years. Racism is quite unusual here, and you certainly couldn't claim 'structural racism'.

I don't claim to know if it is genetic or cultural, but I am not buying the historical slavery/oppression argument. Groups of people are just not that sensitive to trauma over generations or we (the Irish famine) would have never have survived. What happened to the Jews was just as bleak and yet they have rebounded in living memory.

That's not to say it does not matter. Just that I am not accepting that line of argument. The Irish and Jews are not notably more violent and criminal than they were pre-genocide, and they were also oppressed for centuries.

Now if some analog of the IRA or Mossad's assassination squads existed, then a historical oppression argument would tally up better. The recent sniper shootings for example, seem to fit into that category better.

<comment><USER2> >> Let (b) => an X subgroup is X because of itself ("caused its own harm").

>It is a tautology.

Yeah, I meant:

"a subgroup of group G is X because of itself ("caused its own harm")"

Or:

"a subgroup is (a bad thing) X because of itself ("caused its own harm")"

> _Violence can be opportunistic because you 're a war-like tribe and have > spotted a weakness in another tribe. Consider the Mongols attacking > Europeans or the Zulu wiping out the Bush people. Do you consider that an > external circumstance or a cultural choice?_

A cultural choice.

> _Ok. Well I don 't live in the United States, but I can tell you that the > same subgroup exists in places that never had a history of slavery e.g. > Ireland. We have people directly from Africa who live here, and that same > subgroup exists here, freshly minted as it were._

Those "fresh from Africa" weren't slaves in the US, but do come from the same legacy of several centuries of colonialism in Africa itself.

Heck, even their countries' borders where drawn on the map by white men to divide their plundering. Usually with a "divide and conquer" approach, to mix hostile or unrelated local groups/tribes in the same borders and control things playing each other against them. And the meddling, support of friendly lackeys in power, and "divide and conquer" has never stopped since (e.g. for one example few heard/care: [http://www.independent.co.uk/news/world/africa/inside- france...](http://www.independent.co.uk/news/world/africa/inside-frances- secret-war-396062.html) ).

> _That 's not to say it does not matter. Just that I am not accepting that > line of argument. The Irish and Jews are not notably more violent and > criminal than they were pre-genocide, and they were also oppressed for > centuries._

Well, the Jews did establish a quite oppressive and one of the most war-ready and vigilant nation states to protect their identity post-WWII. And a lot of their culture was informed by the persecutions over the centuries.

That said, those persecutions were of a different nature than being held 2-3 centuries as slaves. And their being white, they could always mix far easier into society and climb socially, which they were fully allowed post-WWII. Britain had a Jewish PM back in 1874 -- for them to have a black PM back then would be unheard of and not just protested but derided.

Merely "group a was persecuted too, but is not X like group b" doesn't say much. The specifics of the persecution, and the relative historical accounts of both groups needs to be taken into account.

At some point or another, everyone has been persecuted (e.g. even whites living Europe because of religious persecution) but not all persecution is the same, and not all has hold for the same period, and not all took the same form.

<comment><USER3> > At some point or another, everyone has been persecuted (e.g. even whites > living Europe because of religious persecution) but not all persecution is > the same, and not all has hold for the same period, and not all took the > same form.

I acknowledge that may very well be so, although now we are in the realm of some subjectivity.

The only thing I've left to say is that with some imagination and creativity e.g. genetic manipulation, changes to legal codes, the development of new frontiers, it may be possible to improve the circumstances of all including the marginalized. A lot of legacy problems just drain away when you have economic growth and a clear vision of a better future. Absent that, old wounds tend to materialize to be the scapegoat for further conflict. It's not great, but it is human.

One observation I've made recently is that when people have a common overriding identity e.g. geeks in a hackerspace, other potential sources of conflict such as identifying as transvestite while others may identify as christian tend to fade away. That is the essence of tribalism and I'm convinced it has a lot to do with the future and the Net.

In one related example; consider 'African-Americans' stopping identification with Africa and instead black but America first i.e. a black American, not an African American. That in of itself would help enormously but not without some controversy.

A second but negative example is the Europeans and the recent migration issue. All manner of Europeans are feeling more 'European' purely by virtue of the other being not plus a potential common enemy in their midst. Ironic but true.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Only halfway done, but a good article so far. This coming from someone who is biased to skepticism toward the National Review.

> Alone among the countries in the world, it has attempted to construct not > just a state of different tribes, but a nation of them — white and black, > Christian and Muslim, and many others, too.

This perception of exceptionalism is amusing to me, since I'm currently sitting in South Africa.

Update: Just finished the article, and I remained impressed. Unfortunately for the author, he's probably going to have to switch parties to find an audience for his ideas. It's really, really tough to imagine the GOP being able to rebuild the bridges it has burned with minorities in the Obama era.

We're headed for a huge realignment in American politics. The GOP elite who have stuck with Trump have sealed their own fates. The Democratic elite are already courting them. But neither are doing much to appeal effectively to the poor, white or black.

It remains to be seen whether we'll see a movement that captures both, as well as grabbing some of the intelligentsia. The Sanders campaign came close, but what's needed is something on the order of a political party.

<comment><USER5> >But neither are doing much to appeal effectively to the poor, white or black.

Trump has not stopped talking about economic protectionism and the blue collar workers, job creation etc. If that's not appealing to the poor I don't know what you want.

<comment><USER4> That's true. I phrased my point poorly. He's certainly appealing to a sense of frustration. But he's not providing actual viable solutions. Of course, mere pandering is more than the party elites are doing. They've been counting on success repackaging the same tired ideological lines that no one really cares about when they're actually losing their clout.</comment></comment></comment>


A new direction for web applications - <AUTHOR> http://www.mikealrogers.com/posts/a-new-direction-for-web-applications-.html

<comment><USER2> Interesting thoughts about the evolution of the web and the problems that people are solving. However, designing applications that require state to be maintained in a single process can come back to bite you in the ass when a single process can no longer keep up / falls over. Most people don't hit that ceiling, but then again most people's systems are "just fine" with having a thread blocked on their I/O.

I like node.js because it is much faster than ruby and it provides a very thin layer of abstraction that takes most of the pain out of dealing with async io. I also happen to like JavaScript as a language. Further, I enjoy developing in primarily one language as it reduces the cognitive burden of context shift between front and back-end development. Finally, I enjoy the node.js debugging tools more than anything ruby has to offer (thanks Danny Coates and the chrome dev tools team!)

However, telling people that you cannot connect to multiple databases with ruby or python and saying that node is unique in its ability to build systems that maintain state within a process isn't intellectually honest; node.js doesn't have a particular advantage over netty, eventmachine or twisted for the particular use-cases that you gave; there are already non-blocking variants of most of the libraries available to the node.js community in python, ruby and (increasingly) java.

</comment><comment><USER3> While I appreciate the fact that many "traditional" MVC frameworks fall down when it comes to threading, events, long running connections, event handling, actor-based concurrency, asynchronous processing, and multiple data / presentation resources ... I don't think MVC is the root of the problem.

In fact, MVC doesn't really have anything to do with those issues: it is a pattern addressing the separation of concerns, whereas the shortcomings in the article relate to specific implementation of frameworks that also happen to follow the MVC pattern.

That said, there certainly is a new direction emerging for web applications: we're entering the world of sophisticated software. :)

</comment><comment><USER4> The author gives an analogy which implies that node.js makes Rails irrelevant for a certain kind of apps, but I'm not convinced by the examples given.

In addition, if you're making a single process talk to a PostgreSQL, Redis and CouchDB database, send email and SMS, and talk to a couple of APIs then you're doing it wrong.

I'd like someone to show me the code and a real example.</comment>


Startups : Stop thinking about fucking aqusition - <AUTHOR> http://svenduplic.com/post/12601995015/startups-stop-thinking-about-fucking-aquisition

<comment><USER2> This seems to be the new theme: Create a startup that has no long-term plans and the goal of being bought out by a larger company.</comment>


NodeOS: Operating system powered by Node.js and NPM - <AUTHOR> http://node-os.com <comment><USER2> next, we need a lightweight node/electron based wm, and we have a nice JS based OS all around</comment>


What really caused the Titanic tragedy - <AUTHOR> http://dyingwords.net/fatal-flaw-what-really-caused-the-titanic-tragedy/#sthash.MltnyiiJ.dpbs <comment><USER2> Anyone who has studied this event at any length will know it was a death by a thousand paper cuts. Trying to assign ultimate responsibility to Captain Smith is tenuous at best.

> 1\. Why were the iceberg warnings ignored?

Its not the Captain's fault if information never reaches him. Trying to say Smith ran a sloppy ship or that was a "systemic failure of communications" is merely displaying ignorance.

> 2\. Why was the iceberg not seen until too late?

The important phrase here is "The Titanic was going too fast for the crew to react because Captain Smith allowed his ship to exceed a safe speed for navigation conditions." And I'll grant this is fair. This was one of the situation where 4-5 unlikely things happened all at once. However, I will note that not all of this was on the Captain. Some of this is on the White Star Line and the macaroni operator. Without relevant info, Smith was justified in his expectation to not have to worry about iceburgs at that time of year.

> 3\. Why was the Titanic traveling too fast for navigation conditions?

This is just a reiteration of point 2. Therefore I refer you to what I said there.

> 4\. Why did the rivets fail?

"Captain Smith knew how dangerous an iceberg collision could be yet he still risked his ship being operated in unsafe conditions." I'm sure he also knew what would happen if a boiler exploded, yet he still allowed them to be fired on his ship. This article is just grasping at straws at this point. Captain Smith is in no way responsible of the construction of the ship and all accounts say he was not fully briefed on issues until _after_ the collision. And there was no reason to expect him to be! He was the Captain, not the architect. He had a reasonable expectation of quality of construction, just like when you buy a phone you expect it to function as advertised without having to be an expert on electrical and hardware engineering to make sure.

> 5\. Why were there insufficient lifesaving equipment and procedures in > place?

Again, this is the fault of the White Star Line. Blaming the captain for "allowing" the ship to be taken out of port shows a gross misunderstanding of the relationship between Captain and Company. A pilot expects the mechanics to make a plane airworth, and is not at fault for mechanical failure in flight. The captain is responsible for operation of the ship, not the construction or engineering or basic preparations of the ship. Are we going to blame him for lack of preparation if the bar ran out of martini olives?

This article is trying to bank on "TITANIC MYSTERY FINALLY SOLVED" and shows a fundamental lack of understanding. Which is quite shocking, to be honest, since they got a lot of the facts correct. The only thing I can guess is that they went into this article with an agenda and twisted interpretations until they got what they wanted.

As I said above, the Titanic was a death by a thousand paper cuts. Unfortunately, it was a necessary death to give us the marine safety regulations we have today. If any number of things had been just slightly different on the Titanic, it would be a footnote in history and we would be talking about a different ship that would have inexplicably had everything go wrong.</comment>


.NET framework source code to be released - <AUTHOR> http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

<comment><USER2> Unfortunately they are licensing it under "Microsoft Reference License" which means read-only access. While not the ideal access mode, I think its certainly a step in the right direction. A little bit at a time, and sooner or later Microsoft might actually embrace open source. ...Maybe.

<comment><AUTHOR> Right, I don't think Microsoft is open (pun intended) to just anyone modifying their baseline code. It's almost as good, but if you've got access to base class code for instance, instead of extending a class you could instead grab the base code and strip out all the crap you don't need (which is more often than not, quite a bit).

It's a great start.

<comment><USER3> You seem to be suggesting that Open Source projects allow just anyone to modify their code.

Nobody is open to just anyone modifying their code, whether Open Source or proprietary.

Random people from the internet cannot have their code accepted into the Linux kernel, Firefox, GNU, Java, Ruby, or any other popular Open Source project. They do not have commit access, and the people that can commit code vet contributions quite extensively.

The only group who suggests otherwise is Microsoft - I'm surprised your comment has been moderated up.

<comment><USER4> Although commits to central repositories of os projects are guarded, open source means that random internet users _can_ take the source and modify it as they like for their own personal use (as regulated by whatever license they've chosen). The ms license is read-only (according to the parent comments; I haven't read it) and so is not open source, by common-usage definition.

<comment><USER3> I don't think jkush was talking about personal use.

Jkush: "Right, I don't think Microsoft is open (pun intended) to just anyone modifying their baseline code. "

Clearly Microsoft wouldn't mind at all if someone modified the code for their personal use, as it wouldn't affect MS - the user would have an obviously unofficial version of whatever.

It seems the parent poster is implying that 'just anyone' could modify the actual mainline source code of an Open Source app. This is consistent with past statements from Microsoft about Open Source, usually along the line of "anyone can add code, you don't know where it comes from". Both are incorrect.

</comment></comment></comment></comment></comment><comment><USER5> I'm not typically a Microsoft basher but this isn't a big deal. The .NET source code has always been available via Reflection. Download Lutz Roeder's Reflector, disassemble one of the classes shown in the blog post and compare the disassembled code with the screenshots. Having access to the set of debugging symbols and code commentary is obviously a good thing however.

<comment><AUTHOR> I think this is a big deal for two reasons: it signals that Microsoft is starting to open up a little and the other reason is that getting code definition information through an IDE like Visual Studio is vastly superior to disassembling a .NET framework dll and inspecting the code.

<comment><USER6> No it's not. Reading CIL code in the Reflector is often better than reading it in Visual Studio: the Reflector is an amazing little tool with one of the best integrated cross-referencers I've used.

I'm guessing you've never actually used it, because you're using the word "disassemble" to describe it. Like JVM bytecode, CIL is unambiguous, explicitly typed, and doesn't rely on aliasing; therefore, like JVM bytecode, it is easily reversed back out to a high level language. You're not reading CIL opcodes in the Reflector, you're reading C#.

I wonder if this is a valuable lesson for developers here. Bytecode VMs do not offer strong protection of your source code.

</comment></comment></comment><comment><USER7> This is actually tremendously useful despite the fact that it isn't Open Source. Being able to view method implementations in the debugger will be a boon to performance, and will definitely remove a lot of guesswork.

</comment><comment><USER8> Excellent - it will pretty much eliminate toggling between reflector and vs.net! This should greatly improve the blog post quality, documentation, books, and community feedback related to .NET.

This seems a bit out of character for Microsoft, doesn't it?

<comment><USER6> Not really. First, they have very little to gain from keeping .NET closed: there are strong open-source replacement projects for the "proprietary" framework classes, and .NET assemblies don't really protect source code, even when obfuscated.

Second, even if that weren't true, opening things up is actually not out of character for MSFT, despite the conventional wisdom. For instance, you can download near-complete debug symbols for the underlying operating system. If you've ever read assembly with and without PDB files in IDA Pro, you know what a big deal that is.

</comment></comment><comment><USER9> 2 words: too late.

To me it seems much more motivated by desperation than by conviction.

In about 5 years we will see all of Windows(R) source code released, but again, it will be too late...</comment>


When Silicon Valley goes political - <AUTHOR> http://media.bemyapp.com/silicon-valley-goes-political/ <comment> jim-jim-jim Weird to see terms like liberalism, socialism, and technocracy thrown around interchangeably in this piece.

Socialism in particular is primarily about how power is allocated to labor. It has little, if anything, to do with UBI. The Silicon Valley vision for America is incredibly hostile to labor and doesn't qualify as socialist simply because it jockeys free software/is open to the idea of feeding table scraps to the unemployed.</comment>


Indian space rocket explodes after lift-off - <AUTHOR> http://www.newsdaily.com/stories/tre6bo0n0-us-india-satellite/ <comment><USER2> Whenever I read about something like this my first reaction is to wonder if it was caused by a software bug.</comment>


Squigly – image search by only a squiggle. - <AUTHOR> http://squig.ly/ <comment><USER2> I imagine there are some significant technical challenges.. but a well- performing product in this industry would be substantial!</comment>