Facebook party invite sparks riot in Haren, Netherlands - <AUTHOR> http://www.bbc.co.uk/news/world-europe-19684708

<comment><USER2> An 84 year old resident had his head bashed in with a street tile by one of the visitors. Small towns like this are not very well equipped to deal with flash mobs of this kind, especially not when a substantial portion of those arriving has bad intentions from the start.

An interesting twist to this story is that those very same social media are now being used to identify the perpetrators with amazing speed. Names and pictures as well as movies have been made available to the authorities and 10's of people have already been arrested and/or have given themselves up at police stations.

</comment><comment><USER3> I blame the traditional media for this one. The dutch media have been reporting on it for days before the event was supposed to happen. One media outlet even went as far as setting up a live stream for the "event". The traditional media hyped this up so bad, they essentially created a self- fulfilling prophecy.

<comment><USER4> I agree, but of course they are quick to disavow any responsibility, saying only the people who decide to throw stones are to blame.

Even worse than the live stream was the radio DJ who was encouraging people to go to the 'party' (he has since apologized).

This relates a bit to the problem of copycat crimes and the reporting of suicides causing an increase in suicides. Publicity increases the problem, but it's hard to get all the media to agree voluntarily on not giving it too much attention.

I wonder how this problem should be solved. In an ideal world you could have a system as in science with independent peer review, to do fact checking and preventing hypes. But of course such a system would be much too slow and you would have lots of people complaining it's not free press.

<comment><USER5> _This relates a bit to the problem of copycat crimes and the reporting of suicides causing an increase in suicides. Publicity increases the problem, but it's hard to get all the media to agree voluntarily on not giving it too much attention._

It can work in reverse aswell. If car fatalities are reported more, people might become aware that cars are dangerous, and drive safer, hence reducing fatalities & injuries.

<comment><USER4> But does it, actually? I think there's a much stronger effect in the opposite case when it's about an idea being or not being in people's consciousness. Warning people about risks is in many cases not very effective, e.g., drunk driving, smoking, unhealthy diets.

</comment></comment></comment></comment><comment><USER6> I don't know how party invitations work in Facebook, because I don't use it.

But considering that party flashmobs like these appear to be happening regularly and often cause considerable damage and bad PR, shouldn't Facebook think about changing the way party invitations work? For instance by asking if the user REALLY wants to make the invitation public?

<comment><USER7> I think the problem here isn't Facebook, it's the incompetent and hysterical reaction of the police to those parties.

<comment><USER8> "Hysterical reaction" to a party where 3,000 people show up at a town of 19,000? That's asking for trouble.

Methinks you have too much faith in mobs; as expected, they smashed and looted. I suppose that was the police's fault?

<comment><USER9> Indeed. Even if the police over-reacted, which could mean anything from merely showing up to throwing tear gas, anyone in a mob is free to walk away. There is no obligation to throw bicycles at the police.

<comment><USER10> If you don't throw anything at the police, they may not tear gas you, and what fun would that be?

</comment></comment></comment></comment></comment><comment><USER11> I moved out of the Netherlands a couple of years ago, this makes me feel ashamed. The authorities handled this so poorly that it just had to explode into riots.

Two years ago similar problems where arising in France, called Apéro géant. The crowds intended to organize the biggest party at the Eiffel Tower, everyone feared problems. Authorities sealed the surroundings, but let everyone pass through as long as they handed in their alcohol. Once arrived at the location there was not much of a party so nothing happened.

It's going to be interesting to see what happens to social media monitoring, also interested to see what happens with the damages and the people on tape (youtube, fb et all)

<comment><USER12> Or they could just have directed people to a soccer field outside the village (since most people have probably arrived via public transit) and put on a stage with some music.

Even if some rioting would've started, there would be no houses or shops to demolish, and it would be far easier to isolate the rioting core group from other people.

The mayor refuted such plans with claims that that made the authorities responsible on the occasion something happened. As if that is worse than the current outcome.

<comment><USER4> I don't think this idea is really feasible. There wasn't time to prepare an event of such scale adequately (especially its security), and the argument about responsibility is true I think (not that the current outcome is much better). Also I tend to believe the claim that there were hooligans among them who only came to wreak havoc.

In hindsight they should've blocked all access ways to the village (train and roads). I say in hindsight because people simply didn't expect this to go so wrong.

The lesson to me is that mobs are a scary thing. They can turn angry very suddenly as people start to copy the behavior of the first person to throw a stone.

<comment><USER13> 3 days before the event it was mentioned in the media, enough time to put at least something there. I heard a rumor that they changed some street signs to confuse the people, now that is wasting time. They knew a lot of people were going to really show up, but they took it lightly. Non the less the people destroying stuff are way out of line, all the errors of the authorities don't justify that.

<comment><USER4> I really don't think 3 days is enough time to organize a large scale event like that--more people signed up than the population of the village. I agree that it wasn't handled correctly, but it's easy to criticize in hindsight. This is a new phenomenon and there was not much experience with things like this.

It seems that the authorities where too ambivalent. On the one hand they said please don't come there's no party, on the other hand they prepared a football field for people to go to (without music though). They should've stuck with the former and enforced it by not letting the trains stop in the village and putting up road blocks.

</comment></comment></comment></comment></comment><comment><USER14> When I get old, I am going to tell children that "back when I was young, we didn't call those things 'invites', but 'invitations'".

</comment><comment><USER15> This Project X shit happened some months ago here in Switzerland where I live. In fact the invites were mostly sent out with WhatsApp and not Facebook, so that the authorities could not track it as easily.

It ended with glass bottles being thrown around and riot police answering with tear gas.

<comment><USER13> We have all read about whatsapp security, it is traceable especially with government resources.

</comment></comment><comment><USER16> The sheer absurdity of the whole thing made me laugh.

<comment><USER17> Absurd may be correct and it might have been laughable had no one been injured. At some point you'll want to learn when laughing is appropriate (it's a social skill).

<comment><USER18> I am reminded of this Simpsons scene: <http://youtu.be/ClynhFKMs3c?t=40s>

</comment></comment></comment><comment><USER19> The guerilla party is one thing, and they've happened before.

Having t-shirts printed is a new touch.

But I'm more interested in this:

> A new Facebook page has since been created called "Project Clean-X Haren" to > clear up after Friday night's disturbances. It had more than 17,000 "likes" > as of Saturday morning.

I'd be fascinated to see a guerilla clean-up crew cleaning the trash, removing graffiti, fixing damage, doing a bit of gardening.

<comment><USER8> > _"It had more than 17,000 "likes" as of Saturday morning."_

I'm sure like most Facebook initiatives, people "Like" the idea, but probably won't be taking any real action on their own. That's for other people.

<comment><USER20> Not always the case. The clean up efforts after the london riots last year were quite successful.

This photo [1] is from during the riots but helped to restore my faith in people too.

[1] <http://www.flickr.com/photos/pixel-eight/6024429000/>

</comment></comment></comment><comment><USER13> Of course the event was handled wrong by regulators, but I don't think that means you can riot. What were they expecting? Police waiting with pie and drink and music? Of course not, if you go there you should expect the risk of there being not much to do.

</comment><comment><USER21> Can someone remember this presentation about a social network event going horribly wrong?

<comment><USER22> I think you mean this one: <http://www.youtube.com/watch?v=RyMdOT8YJgY>

<comment><USER21> thanks, that's the one :)

<comment><USER23> Last slide says it is fictional.

</comment></comment></comment></comment><comment><USER24> I had to check whether today is April 1.

</comment><comment><USER25> Mainstream news...

<comment><USER2> Negative real world impact of social media.

Seems like very much on topic for HN given that quite a few of us make a living and/or are creating new social media sites.

<comment><AUTHOR> Agreed, it may be my age but I think as IT professionals we have a responsibility for the real world impacts of the systems we build and/or run.

I see this as a similar to an engineer seeing a mainstream news report of an unintended side effect of large scale engineering project.</comment></comment></comment>


Beyond Castle Wolfenstein (Source Code) by Silas Warner - <AUTHOR> https://archive.org/details/BeyondCastleWolfenstein_source <comment><USER2> I'd love to see the 6502 assembly source code for the original Castle Wolfenstein.

<comment><USER3> Kuma tzee heeya!</comment></comment>


Coffee, Tea, iPhone App: One of These Things is Not Like the Other - <AUTHOR> http://www.sunetos.com/items/2013/10/10/coffee-tea-iphone-app-one-of-these-things-is-not-like-the-other/

<comment><AUTHOR> I totally agree that comparing a cup of coffee to an app is ridiculous, even if they cost the same. And I think you're right - it's because a cup of coffee is a known thing.</comment>


But nobody wants a "fast-paced environment" - <AUTHOR> http://programmers.stackexchange.com/questions/59173/why-do-ads-for-s-w-engineers-always-say-they-offer-a-fast-paced-environment <comment><USER2> There is a sort of stress that comes from a "slow-paced environment" where you've got a 50% or less duty cycle of doing real work because you're always waiting for somebody else to do something. Too little work can be just as stressful as too much.

<comment><USER3> Having not enough work to do is slightly worse than having too much, IMHO

<comment><USER4> This is the battle I fight every day. I'd rather have a workload that's 110% of my capacity than be at 50%, which I generously where I'm at now.

We're an "agile" shop that grossly under-allocates out of fear of failing a sprint.

<comment><USER5> This also happens in those implementations of Agile where they try to pretend that programmers are all easily interchangeable cogs in a machine. The problem is, anybody they get who is better than average or has some natural talent is going to be bored out of their tree.

What _I_ would do, is start picking future cards and then when they come up give ridiculously low estimates for them (because they were already finished on _my_ machine :D ).

"Oh, you want a persistence layer for all this? Okay, that will take... -17 minutes."

Or, alternately, if I didn't want to bend people's minds or break the wills of the junior programmers (messing with the jps is half the fun of these sorts of things :D ), I'd work on some technical debt, since Agile projects tend to accumulate it faster than a sophmore with Daddy's credit card.

</comment></comment></comment></comment><comment><USER6> As was pointed out in the comments, fast-paced == lots of unpaid overtime. If you had good project planners (or project managers who don't start factoring timelines based on the amount of unpaid overtime they can get you to do) then you'd be working in a "well-paced environment". Which is a nice place to work.

</comment><comment><USER7> "fast-paced environment" says more about the people than the environment...

Let's say, for example, that your environment changes at rate "10".

If you normally move at rate "7", this environment would seem fast-paced to you.

But if you're accustomed to moving at rate "15", you wouldn't even consider it to be fast-paced.

In my experience, what most junior and enterprise programmers would consider "fast-paced" would seem fairly normal to most senior or start-up programmers. It's all relative.

<comment><USER5> Although normally the Agile evangelists are whacked out wierdos, one of them did say something useful to me recently.

He said that "all coding is change". This is simple, trite and deeply profound.

 _All_ coding is change. Either you're building something new (change) or you're fixing a bug (change) or you're adding a feature (change).

The whole rhetoric about programmers who don't like other programmers being 'afraid of change' or unwilling to 'embrace change' is nonsense.

Given then, that all coding is change... I wonder what it means to say that some environments change faster than others.

What does this mean? Requirements flip-flop? Staff turnover? Starting projects and then killing them softly with this song?

<comment><USER8> While it is simple and trite, how is it profound? All human activity is change by that definition.

<comment><USER5> Because in IT we somehow have tricked ourselves into thinking that change is undesirable.

<comment><USER9> Really? I read quite a lot opinions (articles, blog posts, comments) from IT people and haven't really found anyone expressing such a blanket statement.

Even the complaints about spec changes are seldom about changes per se, but rather about the impedance mismatch between the changes and an inflexible process.

</comment></comment></comment></comment></comment><comment><USER10> Saying 'fast-paced' usually (in my experience) is a claim that the team doesn't get hung up and blocked on a bunch of minute details and 'sign-offs'. In other words - there's no committee.

Even if that isn't the norm, putting so much stock in the copy in a job ad is probably a waste of time anyway. Just because the ad says 'fast-paced' or refers to the person they're looking for as a 'ninja' doesn't mean it wouldn't be an awesome place to work -- from my perspective, quite the opposite, any text like that makes it feel like it was written by a company without an HR department (+10!).

<comment><USER11> I've written a few job ads and I'm sure I've said fast-paced and other filler words.

I wish I meant "When reality and the plan don't match, we change the plan," in reality it was "Hmm, this text needs to look longer -- I'll use adjectives!"

</comment></comment><comment><USER12> I have the great misfortune of working at a big company which has tons and tons of specs AND frequent spec changes.

Our process is waterfall that refuses to accept the reality that marketing runs this company and they change their minds a lot.

My point is only that if there was something better I would quit mediately. But I would rather deal with this at a biotech, then work at the most wonderful company working on social apps, or advertising apps, or ticketing, or booking, etc.

Pick your poison kids.

<comment><USER13> Heh, that sounds very familiar. When I got my job, it was told that the reason for using a waterfall model was that "the specifications are very clear, and developers just have to implement them".

Reality is so different... :)

<comment><USER14> Sounds like my last job. They had gotten burned a few times by waterfall projects failing, so their reaction was to try to implement waterfall even _more_ rigorously.

You had to design and document the entire project up front and then break it out into individual tasks and estimate them. Two points that I thought were particularly horrible:

Your estimates immediately became hard deadlines. If you guessed 3 months ago that gnarfling the garthok would take you 8 hours and you were wrong, it went against you on your metrics. Even better, if you finished the job in _less_ time than you estimated, they'd complain and tell you that you missed low and needed to do a more precise job of estimation next time.

I suggested to my boss once that if they insisted on having all this documentation written (seriously, we were supposed to write up docs on what the function names were going to be, what the arguments were, and what they'd do -- _before_ we were allowed to write any code) then we should probably build some time into the schedule to make sure we could update them based on what we'd learned during the actual process of writing the code. He told me "I understand what you're saying, but that's not possible. We need all of the documentation done up front so that if we're behind schedule, we can add more people to the project and they can read that documentation to get up to speed quickly."

I looked at him for a few seconds, stunned speechless, then basically said "In my experience, that never works." A few weeks later, I was laid off, I suspect because I wasn't toeing the line and buying into the "new" Lean waterfall process. Best thing that ever happened to me, in the end.

<comment><USER13> It's kind of the same here. We first have to write a design document, then get it reviewed by people all over the organisation. This reviewing _has_ to be done in a meeting, which is impractical because it is almost impossible to find a time where everybody is available AND a room is available.

Writing a design document doesn't sound that bad, but the requirements are completely unclear when you start the project. Usually, the stakeholders don't even exactly know what they want, so it's very hard to get concrete requirements. And they change their mind all the time, so if you just scrapped something, many times you have to add it back later.

Only when it is deemed OK, it is officially allowed to start programming. If not, back to the drawing board. Worst part is that the opinions differ on how detailed this design document should be. Some people complain if it is not detailed enough, others complain if it is too detailed.

When you have the OK, the red tape only starts. You have to mail or run around asking people to grant change access to their part of the source code. In many cases, simply referring to the design document for explanation is not enough. Nope, as they generally had "no time" to go over the document, if you want to get work done, you should explain everything that you're going to change in their part.

Even the SCM system that we use is slow. Checkouts take ages, builds take ages. This way of development really doesn't work for me and many others. Luckily there is an (unofficial) way to "fork" the code, so that you can start working and experimenting while writing the design document. Without this, it'd be almost impossible to get the amount of detail required.

And when you're done coding, you need to write a document with testcases, which goes through the same review process. When you're done testing, another document with test results...

In this case, the process works because it is not very rigidly enforced. Unluckily, some people in management think that code quality will improve if and only if more checks are put in place. So every half year there are more checkboxes and process steps.

</comment></comment></comment></comment><comment><USER15> A manager once told me, "multitasking may be inefficient, but that's what we do here." Let that admission sink in for a minute.

<comment><USER16> I'm sorry, I haven't got a minute. Can I let it sink in for 30 seconds, and get back to you?

<comment><USER15> The manager was admitting to doing something that he knew was inefficient. He ultimately knew that multitasking was the worst practice, but he chose to do it anyway.

There's ignorance, and then there's willfully choosing to do wrong.

Edit: This was at an investment bank, in the proprietary trading group. There are no customers or deadlines. So we (should) only work on something we believe will make money.

<comment><USER16> In such a situation I think all tasks should be globally sorted (according to business-determined weighting) by the metrics:

\- how much do we expect to gain if we do it

\- how much do we expect to lose if we don't

\- how much (black swan worst case) might we lose if we don't

\- how easy is it

and then programmers should just pick off the top of list, updating the tasks metrics if they subjectively change.

That way there are multiple tasks queued but only one in play, and context switching happens when a task changes importance.

</comment></comment></comment></comment><comment><USER17> Interesting - it would be helpful to have a definition of "fast-paced". The phrase is far too vague.

I love working very hard (potentially fast) on a product that I'm making great headway on. Perhaps I'm in the zone or I know I need to hit a deadline.

That being said if I'm being asked to produce things frantically (also fast paced) with little to no direction or thought behind it...that's not so hot.

In general job descriptions should be more self aware and try to communicate the environment more specifically.

<comment><USER18> > Interesting - it would be helpful to have a definition of "fast-paced". The > phrase is far too vague.

Welcome to the wonderful world of MBA-speak.

<comment><USER19> <http://www.dilbert.com/strips/comic/2009-05-18/>

</comment></comment></comment><comment><USER20> Reminds me of estate agent talk. "Fast-paced, agile, challenging environment" as a plus point on a job ad usually makes me skip right over. I know people say you should turn your weaknesses into strengths but I don't think this is the way!

</comment><comment><USER21> Its like the other phrase I dislike "Rockstar programmers". Now my idea of "rock stars" is that they are temperamental, have low self confidence, and spend 90% of their time complaining. I've met, and occasionally worked with, programmers that fit that particular shoe and frankly I wouldn't try to recruit them.

I am sure the HR/Recruiter is trying to convey a sense of urgency that keeps you at the top of your game, but I agree with most of the comments that companies that create their own urgency by not planning is the more common occurrence.

</comment><comment><USER22> Fast-paced environment usually describes places that lack an attention to detail and quality, which above anything else should be the core focus of a company. A lot of people are suggesting that pace refers to the amount of work which I don't think is entirely correct. A business could have all the work in the world and still move at a snail's pace. @mrspeaker made an excellent point in that the ideal environment would be "well-paced." More often than not, though, this sort of terminology was probably picked from similar job postings that the HR person (generalizing, of course) saw elsewhere.

</comment><comment><USER18> Fast paced is generally code for "we have the attention spans of fruit flies. We'll expect you to pick up the slack for our failings."

</comment><comment><USER23> "Fast Paced Environment" means:

1) The specs are not in place 2) They are a software company, mostly 3) The managers are not really managers, but engineers who were given a battle field promotion 4) They have a set of key customers who control 51% of revenue, who dictate everything and change their mind frequently

</comment><comment><USER24> It's just marketing - on the converse, no one wants to sound slow...it associates with boredom. Fast-paced signals energy and excitement, but translates to over-worked and poor balance with the rest of your life.

When I hear this it reminds me of when engineers in interviews say "I work with the smartest people." Of course you do...who works with the 2nd smartest people? Who admits to working with average people? I'd like to know how you distinguish that in an ad/interview.

</comment><comment><USER25> The fact that 'fast-paced' has negative connotations for older/wiser workers is irrelevant. They're targeting the same sort of 20-year-olds who all wanted to work for MS in the late 90s because they had free soda. The commenters criticizing this tactic seem oblivious to the fact that the companies using it don't want them.

</comment><comment><USER26> Software job postings are full of cliches. Best to ignore the description and instead use the interview to ask how project requirements are decided, scheduled, and delivered. If their process doesn't mention any input from developers other than "deliver" then ask how often morale improvement beatings are administered.

</comment><comment><USER27> I offered my last girlfriend a fast-paced environment. I'm single now.

Ladies.

</comment><comment><USER28> I want a fast-paced environment. And I want to work with people who also like a fast-paced environment.

A fast paced environment is not the same as a "ridiculous hours" environment (I've done that - 80 hrs per week, high pressure). Nor is it a "death march" environment.

What it should be is a place where people come in to work ready to go, work intensely for 8 or 9 hours, then go home to enjoy the rest of their lives. I work at one of the more aggressive large web companies and we have an "email blackout" policy on weekends, for example - if it's not an operations problem, we ask folks to wait until the work week to send emails about it so that folks can concentrate on enjoying their time off undiluted by work and be ready to go on Monday.

</comment><comment><USER29> I moved from an extremely fast-paced environment to a well balanced, well managed software shop. I regret that choice a lot. While I do have now work/life balance, sleep longer nights and never do any overtime, I can't help but feel I'm not even close to the productive levels I had before. I loved being pushed to my limit, constantly having to come up with new solutions to new problems, etc.

On the plus side, I now have the time to launch my company which will - I hope - give me once again the kind of environment in which I can push my own limits.

<comment><USER30> Well I guess in a fast paced environment you are pushed and in a balanced environment you pace yourself. We are adults not cogs.

<comment><USER29> Less challenge means less of a reason to push yourself in my opinion. I rather relished the possibility to jump on problems other people left alone.

Perhaps it's more an issue of challenge than pace, pace being a side effect of the challenge you encounter.

<comment><USER30> Or perhaps of a challenge your boss encountered. May be a wrong kind of challenge, depending on the boss.

</comment></comment></comment></comment><comment><USER31> "fast-paced environment" means getting shit done. it means rolling hard like facebook, google, zynga, groupon, etc. it means launching fast. it means getting feedback fast. it means failing fast. it means the exact opposite of the folks complaining about it who work at ibm or hp or microsoft or yahoo or aol. or worse yet, some hole-in-the-wall enterprise vendor inflating internal budgets and wallowing in mediocrity.

fast-paced to me means "if you can't keep up, don't step up."

regardless, if you have to ask, it's not a place for you to work.

m3mnoch.

<comment><USER32> Yet if you read a job ad from IBM or HP or Microsoft, they're "fast-paced" too.

<comment><USER33> And there is the problem.

The phrase 'job ad' has the word 'ad' in it and thus anything which is mentioned in the ad was probably (re)written by marketing and thus isn't true to begin with. ;-)

</comment></comment></comment><comment><USER34> I work in what I would call a fast-paced environment.

What I always took fast-paced to mean is that, as a startup who is trying to build a business we are constantly evolving our goals to develop the best product possible. This means making smart but quick decisions based on actionable data.

Whether that means adding new features, dropping ones that don't work, etc. thats what we are going to do.

</comment><comment><USER35> Interesting. When I think of fast paced environment, I think of a driven environment with lots of youthful energy that moves quickly.

Shameless self-promotion: My Chicago Startup Tap Me, (<http://tap.me>) is hiring. If this kind of work environment sounds appealing to you, my email address is in my HN profile.

</comment><comment><USER36> trying to predict how the company is based on the job listing is on the same order of magnitude of effectiveness as trying to predict how good the candidate is based on the resume. There's probably just some rough correlation on a large scale. I used to have a lot of notions from reading various blog posts but too often they prove to be totally wrong in specific instances. One of my worst experiences ever was going after a clever puzzle online leading to arduous days of coding and grilling and more puzzles (invested so much time) only to get a sub-par offer and lots of 'hard negotiating' which i always avoid. fact is words like fast-paced, multitasking, excellent communications, team player, rockstar, a player, self motivated blah blah blah, I simply ignore. I imagine the same goes on in the other direction, so I no longer put them on my resume.

</comment><comment><USER37> I want to be a Greybeard UNIX monk some day.

</comment><comment><USER38> Depends.

I'm an adrenalin junkie, so if I'm passionate about something, it better be fast-paced, or else I get bored.

But if it's boring already? Then yeah, everyone please chill.

</comment><comment><USER39> I've always assumed that "fast-paced" meant that you weren't going to encounter a company moving at corporate-speed -- you know, where a project takes 6-12 months (min.) of meetings, tiger teams, blue ribbon panels, design by committee, political posturing, ad nauseum.</comment>


Apache ignores access control when using FastCGI - <AUTHOR> https://issues.apache.org/bugzilla/show_bug.cgi?id=56084

<comment><USER2> That's not an accurate, or at least not a complete, statement. Apache ignores file-based access control in this case, because Apache isn't handling the files, your FastCGI server is. Access controls in a Location section work as expected.

Perhaps it should be added to the FastCGI documentation in a very emphatic and clear way? Maybe it should also default to no access without an explicit declaration of what the user wants (though that would break people's configurations, so would need to happen in a major revision).

</comment><comment><USER3> As it's pointed at the 3rd comment [https://issues.apache.org/bugzilla/show_bug.cgi?id=56084#c3](https://issues.apache.org/bugzilla/show_bug.cgi?id=56084#c3) This is just a mis-configuration not a bug.

      Hans 2014-01-29 04:31:41 UTC

      It's an Apache misconfiguration that's not pointed out very clearly.

      The following is the fix:
            <Location /fcgi-php-fpm>
                # here we prevent direct access to this Location url,
                # env=REDIRECT_STATUS will let us use this fcgi-bin url
                # only after an internal redirect (by Action upper)
                Order Deny,Allow
                Deny from all
                Allow from env=REDIRECT_STATUS
            </Location>

      It would be useful to point this out somewhere.

      The above restricts direct access, but not internal access via PHP-FPM sockets.

<comment><AUTHOR> Absolutely, but it turns out to be a really common misconfiguration found in default configs and tutorials. Definitely something to be aware of when configuring FastCGI.</comment></comment>


Always Be Clicking - <AUTHOR> https://www.youtube.com/watch?v=_UhroJz_eOQ

<comment><USER2> Warning to others who might be inspired to watch based on the reference to Glengarry Glen Ross: this video is an advertisement.</comment>


U.S. Air Force Requires Airmen to Praise F-35 - <AUTHOR> http://warisboring.com/articles/u-s-air-force-requires-airmen-to-praise-troubled-stealth-fighter/ <comment><USER2> I'm not sure about the other capabilities of the F-35, but judging a modern war plane based on its ability to dogfight is like judging a modern ship based on its ability to ram other ships.

Dogfighting just isn't going to happen anymore in a battlefield where smart munitions are relatively cheap, plentiful, smart, and getting smarter every year.

We are talking about skies that will soon be filled with extremely agile drones and missiles. In that environment, a manned fighter, that cannot pull high-G maneuvers (because the human pilot will pass out) cannot beat a supersonic missile or drone.

We should not build planes to perform well in dogfights in the style of the Korean and Vietnam war. Stealth or unmanned is the way to go.

Having said that, the Chinese long-term strategy of developing high performance drones to saturate the battlespace is probably the smartest idea of all. I don't think any stealth technology remains very "stealthy" for very long, in this era of software processing.

<comment><USER3> All your points are well-made and I believe you are mostly correct. However, I wouldn't be so quick to entirely dismiss dogfighting as something that "just isn't going to happen anymore".

Nobody knows exactly what combat would look like with modern weapons between actual adversaries; which weapons would would be ineffective; which countermeasures would succeed. The possibility that two aircraft could get close enough that it would become a dogfight should always be accounted for.

Munitions could be expended to the point where no long-range missiles remain. An enemy aircraft could use terrain masking in mountainous terrain to get close; no radar can detect an aircraft through half a kilometer of rock. How about the effects of inclement weather? Or, perhaps, some F-35s are themselves using terrain masking on a ground-attack mission due to enemy SAM presence and are surprised by an enemy squadron.

The point is, there is always a way things can go wrong. Ignoring that gets people killed. That said, it has been accounted for in the F-35; the Distributed Aperture System along with off-boresight missiles could actually make the turning battle of a dogfight obsolete... until the F-35 expended all its missiles.

Of course a UAV could be much better than any manned aircraft in a dogfight; but battles aren't always picked, one must always be prepared for a battle to be forced under less than optimal circumstances.

</comment></comment><comment><USER4> Well, an obvious step after putting all your eggs in one basket is to silence criticism of that basket. This is just one more reason why the Air Force's decision to reduce diversity in weapons systems is a bad idea. Not only do they become too big to fail, they become too big to criticize.

</comment><comment><USER5> I can personally say that the F-35 is the kindest, bravest, warmest, most wonderful plane I've ever known in my life.

</comment><comment><USER6> For anyone interested in the dynamics of the Air Force that explain the abysmal performance of the F-35, and why the F-16 can beat it in a dogfight despite being commissioned 40 years ago, look up John Boyd or read "Boyd: The Fighter Pilot who Changed the Art of War." The Air Force is structured to enable and shelter operational failures such as the F-35

<comment><USER7> Though I agree with you that all government agencies are political machines which have evolved to protect their bureaucrats; the F-35 was simply not designed to be a lightweight low-cost fighter. Comparing the F-35 to the F-16 is about as useful as comparing the F-105 to the F-86 (, which is to say not very informative).

Boyd thought that even the F-16 was overweight and over-sized (and he may have been correct).

<comment><USER8> > Boyd thought that even the F-16 was overweight and over-sized

... compared to what it could have been, and would have been, had he somehow completely gotten his way, sure. It was a disappointment to him, but it's still pretty good in energy–maneuverability theory terms.

And it's worth comparing the F-105 to the F-86 in dogfighting because dogfighting just keeps happening in wars, decades after it was predicted to cease.

<comment><USER9> Curious, what was the last time anyone scored with a cannon on a modern jet fighter vs another jet fighter?

<comment><USER10> Maybe one of the air-to-air kills in the Eritrea-Ethiopia war was cannon? idk...

</comment></comment></comment></comment></comment><comment><USER11> I spoke to an RAAF test pilot a few weeks ago who confirmed the stories that this plane is an absolute lemon. It's trying to be too many things and failing at all of them.

<comment><USER12> I spoke to a USAF pilot and he said the F-35 is a decent plane, easy to fly, well equipped even thus no match for specialized fighters its decently good at everything.

Here's the problem though. None of your comment or these article bring any proof and is more of a click-bait than anything else. It's trendy to hit on them, that's all really.

Also, I did actually talk to that pilot and a few others from other aircrafts as its actually an easy thing to do in the US so easy to do/verify on your own for many of us:

since many HN readers are in the bay area, just visit the boats for SF's Fleet week - it's free, and there's always marine pilots of all kinds onboard (mainly heli, but also a few F-35, harrier and osprey pilots.

<comment><USER13> I concur. The F-35 is a decent aircraft performance wise. It might not be quite as agile as an F-16 in airshow configuration, but when carrying a combat load, the F-35 has the edge.

When it comes to the F-35 sensor package, its a huge leap beyond the F-16.

<comment><USER4> Not for the price. $1 trillion is a really step price tag for a "decent aircraft". As for the sensor package and stealth, I'm not entirely sure that suitable upgrades to the F-16 and F-18 series wouldn't have been a better option. Besides, for $1trillion, it should be possible to develop three or four different aircraft with specialist capabilities and use them together.

<comment><USER12> i agree, albeit by that rationale you'd better get a Rafale - its the same kind of plane as the F35, minus a few nice features but much cheaper. Which is exactly why the only nations getting an F35 are US allies not making their own aircrafts. others either:

-make their own (Eurofighters, SU35S, PAK, etc.)

-get get older planes (F15s in particular)

-French Rafales.

</comment></comment></comment></comment></comment><comment><USER13> The USAF requires Airmen not to criticize USAF or Pentagon policy. If a 4-Star General publicly criticizes policy of the Petagon, it could end their career.

This post by David Axe is complete rubbish.

</comment><comment><USER12> The comment on the blog seems about right so ill copy:

"Lets see David Axe the nonstop liar that wrote this used the words "commands", "requires". and "demands" when referring to the document in question. No where in the document cited are any of those things. This author constantly takes any accusation about F35 and exaggerates it to the ridicules level. He uses thinly sourced quotes and seems to have a vivid imagination. WiB should be embarrassed to have such a talent-less hack writing this drivel… do you guys even have an editor?"

<comment><USER14> A poorly-written nitpick about the choice of words used "seems about right" to you?</comment></comment>


The Python Road Not Taken - <AUTHOR> http://aleph.nu/blog/2015/the-python-road-not-taken/ <comment><USER2> As I mentioned the last time this came up, I recently converted a medium-sized (about 30,000 lines) system from Python 2 to Python 3. The problem is not the language changes. Those are minor, and most of the new forms worked in Python 2.7.9. It's the state of the external modules. Important old Python 2 modules have been discontinued, and their replacements are not used enough or tested well enough to use reliably. I kept finding bugs that should have been found in the first months of heavy use of a module.[1] It took an extra month of work to find and work around all the external module bugs. These aren't obscure modules; they're ones most large server-side applications would need.

Porting was at least possible. Two years ago, I took a look at doing this, and there weren't enough modules ready to even attempt it. Now there are. There is progress. Slow progress.

The download statistics tell the story: "We can see that in the past year Python 3.x has grown from roughly 2% of the total downloads from PyPI to roughly 5-6%."[2] That's why the external modules don't work reliably on Python 3. 95% of the package use is on Python 2. Python 2 use is probably higher than that, since those are download statistics; PyPI doesn't see packages downloaded long ago and still running.

There's extensive denial about this among Python fans. That's a big part of the problem. Another problem is that PyPI is just a link farm - unlike CPAN, it doesn't centralize code hosting, bug tracking, support forums, and quality control. This allows Python fans to be unaware of how buggy the packages are.

[1] [https://news.ycombinator.com/item?id=9378898](https://news.ycombinator.com/item?id=9378898), search for "quality control" [2] [https://caremad.io/2015/04/a-year-of-pypi- downloads/](https://caremad.io/2015/04/a-year-of-pypi-downloads/)

<comment><USER3> I wish it was possible to know how much of that 5–6% were actual users, and how much were people running tests.

</comment></comment><comment><USER4> Number one reason why I haven't switched yet?... print. Admittedly is is the dumbest possible reason, it's irrational; I would never admit it in a face-to- face conversation; I would deflect to "something something third-party library...", but deep-down inside, if I'm really honest with myself, it's print. I want asyncio, I want better unicode support, but all I think about are SyntaxError's in what I __strongly__ consider to be valid python.

My stubbornness is rooted in the simplicity of print. It is so simple and stupid, why change it? Never has a production app relied heavily on print, it's just a dumb way to check shit while developing. I mean sweet jesus if it ain't broke right? I know I'm wrong in thinking this kind of thing happened everywhere in the 2->3 increment, but as I said earlier, I'm under no illusion of rationality. Python 3 broke hello world, and that just skeeves me out.

Eventually I'll write new stuff in 3, probably sooner rather than later especially with asyncio et all, but for now I'll stick with 2.

<comment><USER5> If you are saying print is gone, it isn't. It became a function in python 3.

       print "hello world"

became

       print("hello world")

If you are complaining about the format, then that really is a dumb reason.

<comment><USER6> I'm also embarrassed about it, but I also strongly dislike the change to print. With this combined with a lot of little things like the removal of __cmp__ (apparently without even a relevant mixin in the standard library!), removal of the cmp argument to sort, removal of encode('hex') and encode('base64'), and doing Unicode wrong[1], Python 3 really feels like a pointless quality of life decline. For this reason I still stick with Python 2 for my general scripting needs.

[1] [http://lucumr.pocoo.org/2014/5/12/everything-about- unicode/](http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/)

<comment><USER7> But cmp is so backwards and non-intuitive. Key is a vastly better api, and more performant too, because you can generate keys once and then do comparisons using native types.

Again, with the encoding the api is different, but it's still really simple.

These feel like walls for walls sake.

<comment><USER6> Key... well, I should elaborate on that. I don't usually use cmp in my own code, and while I can think of situations where I might want to, using a wrapper class implementing comparison methods would be easy enough (modulo the missing mixin issue!). It's semantically a lot more complex to create a new object for comparison than to specify a comparison function when the English description is "sort by X" (of course, when X is just a property, key=lambda a: a.x is enough), but since this is a rare situation, I wouldn't mind. However, I ran into that issue when trying to teach my brother programming, and for learners, semantic overhead is really hard to deal with. Now, Python has no responsibility to optimize for learners over actual programmers (indeed, I'd argue it's always been worse as a first language than people think), but this was a case of removing a feature that had minimal additional API surface or implementation complexity; it really felt like removing things for the sake of removing things.

For encoding it's mainly annoying because now I have to manually add an import, which is more typing than before. To be fair, there is a cogent argument that my issues with both print and this mean what I really want is a different language altogether: one that, respectively, allows omitting parentheses for all function calls, and has some kind of implicit import. But other languages have their own problems, and this still feels like a paper cut.

Oh, and the annoyance is exacerbated by the interfaces of binascii.hexlify and base64.b64encode being broken. They both return bytes objects, which is dumb since the whole point of hex and base64 encoding is to represent binary data as text, and the most common thing to do with encoded strings is to insert them in the middle of other text. 'foo %s' % hexlify(b'bar') => "foo b'626172'"; to get the "foo 626172" I want, I have to do even more typing and append .decode('ascii').

<comment><USER7> I find with cmp there's too much to remember - if a < b do I need to return -1 or 1? With Key it becomes really simple, and powerful:

        sorted(records, key=lambda r: (r.city, r.age, r.name))

For me there's a lot less mental overhead with the Key form.

Encoding-wise, hex and base64 are not something I do too often, so their new interfaces don't worry me too much. In the cases you've mentioned you could create a simple wrapper function to deal with it for you.

I guess there's some reason for using bytes instead of strings as the output to the interface, but, as you say, it's definitely non-obvious.

There are lots of things that are a little different in python 3; I would say overwhelmingly for the better, on the whole. There just doesn't seem to be much point fighting against those minor changes when they're easy enough to adapt to.

</comment></comment></comment></comment></comment></comment><comment><USER8> [https://python3wos.appspot.com/](https://python3wos.appspot.com/)

I'm seeing an awful lot of green there. Most of the things that are red (which might influence someone to use Python 2 on a greenfield project) have alternatives that are green.

<comment><USER9> Twisted? I still see that as a BIG python 2 Wall of Shame I mean Superpowers issue.

<comment><USER3> It's too bad that the WoS isn't able to display things like partial-support ([https://twisted.readthedocs.org/en/latest/core/howto/python3...](https://twisted.readthedocs.org/en/latest/core/howto/python3.html)).

<comment><USER10> And I'm not sure about the fine-grained accuracy here. For example, NetworkX is listed green, but its graphic subsystem, according to their documentation, does not support Python 3.

Also, Oath2 seems like a big one, and would exclude many other packages that might use it.

<comment><USER3> It is all self-reporting based on the classifiers given to PyPI (NetworkX lists itself as supporting Python 3, Python3.2–Python3.4). It seems like both it and twisted would benefit from a Python3–partial classifier

</comment></comment></comment></comment></comment><comment><USER11> I find some truths in this analogy:

I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge.

Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big.

I think, many more projects would have adopted Py3, if more extension modules would support it.

The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.

I think, when it would have cared more for compatibility from the beginning, much of the damage done would have been avoided.

</comment><comment><USER12> It raises some good points. It makes me think of other projects I've been a part of where the working, existing system was starved for resources in favor a new system which didn't exactly dominate in performance or capability.

I've been programming for almost 20 years but am new to Python. I'm currently working on an API for a product and testing it against 2.7 and 3.4. It's not the end of the world, and if it works for 3.4 it pretty much works in 2.7. Granted, it's not the world's most complex or deep piece of python, but is there a real problem in making 2.X code run on 3.X? Is it really that big of a change?

<comment><USER13> It's easy to get your own code to run on 3.x. The challenge is making sure all your C library dependencies run on it. And Python is nothing without its vast library ecosystem.

<comment><USER14> I ported APSW to Python 3 during the Python 3 beta (2008 IIRC) and thought I was being late! Porting the C code was easy - just a few #if sections selecting between Python 2 and 3. What took considerably more effort was porting my test suite. In addition to normal functionality, it does far more testing of boundary conditions and errors. I finally ended up with a codebase that compiles unaltered on Python 2.3 all the way through 3.5 (except 3.0), and the same Python source file that does testing against all those version and popular platforms with issues (ie Windows). To date I have never had a bug report where sample code was for Python 3 - it is always Python 2.

I also provide binaries for all the Python versions in both 32 bit and 64 bit (where relevant) for Windows. When hosted on Google Code, their download stats showed the vast majority on Python 2.7 32 bit with a slow increase in 2.7 64 bit. Python 3.x downloads were roughly similar to Python 2.4 downloads! Sadly since moving to Github I have no idea what the download rates are.

BTW the only reason for not supporting Python 3.0 was that the test suite needed a module that wasn't provided (base64 or something similar), which I could have worked around, but the 3.0 release was end of lifed so I didn't bother.

</comment></comment></comment><comment><USER15> For me with the headaches with Unicode and international content, python 3 is great and well worth the switch. However, I know most don't have that big of a win to switch and there is really no business reason to switch.

<comment><USER16> Not necessarily a short-term thing, but Python 2.7.x is set to be unsupported in 2020, IIRC.

</comment></comment><comment><USER17> If they'd solved the multithreading problem in Python3 so that you can get true multithreading that would have been a tremendously motivating force to get people to switch. But that didn't happen and it's really undercut a lot of the pressure.

<comment><USER18> My understanding is you can get true multithreading in both python 2 and 3 by using an interpreter that supports it (like IronPython).

</comment></comment><comment><USER19> The old road is still getting holes patched. Official support has already been promised until 2020, and features are being backported from 3.x to 2.7 [http://legacy.python.org/dev/peps/pep-0466/#implementation-s...](http://legacy.python.org/dev/peps/pep-0466/#implementation- status)

<comment><USER20> And it's quite possible that'll get unofficial support (perhaps not from the core team, but by people concerned) even after 2020...

<comment><USER21> Honestly, 3.5 is getting there. I've been pretty frustrated by Python 3, but starting with 3.5 it actually looks /possible/ to port Mercurial without tons of grotesque hacks.

</comment></comment></comment><comment><USER22> _I used this analogy to describe the state of Python 2 /3 to a friend who knows nothing about programming. Like many Python programmers, he too would continue using the old road._

Wow, that's remarkably unconvincing. I'll think of this the next time I hear of some complex ethical dilemma solved by asking a small child.

</comment><comment><USER23> I really wish we as a community just set a date and ported. As it is right now there's almost zero chance that the project I'm working on will get ported to Python 3. I'm not sure what it'll take, but I really wish we were passed this stage.

<comment><USER24> This is the "problem" with not having things controlled by some central figure. Following the road example, the Dept of Transportation would simply open the new road, and close the old. You wouldn't have a chance to continue traveling down the old. This happens (to a large extent) with Java. Oracle opens the new road, then stops fixing potholes on the old one. You're not "forced" to move over, but eventually you stop wanting to fix your suspension.

That said, who is central enough to put an "end" date on Python and "force" people to move over?

<comment><USER25> > _That said, who is central enough to put an "end" date on Python and "force" > people to move over?_

Guido van Rossum?

I'm not in the Python community - I barely know the language itself - but from the outside he seems to be a central figure? Doesn't he have enough authority to pull this off?

</comment></comment></comment><comment><USER26> The metaphor doesn't appear to make sense - at first, the new road is only "slightly wider and speed limit is fractionally higher" but then later on it appears that the road needs "enough new lanes" for all the cars on the old road.

I thought the premise of building the new road was because the old road's ground wasn't good enough, not that there was too much traffic and the road needed more lanes.

Anyway, the whole thing hinges on the authors assertion that the new road isn't that much better, so it's really up to the informed developer/user to decide whether or not they take the new road.

<comment><USER27> I tried to stay away from a which is better battle. I think the numbers speak for themselves as to which road everyday users of Python are using (scripts to scrape cat pictures don't count ;).

</comment></comment><comment><USER28> Such garbage.

Another person asserting that Python 3 is going nowhere, based on their opinion and nothing more, no science, no facts, no figures.

Without any reasonable justification for this opinion then I call this complete FUD and to be entirely disregarded.

</comment><comment><USER29> One of the nice things about Python 2 is that there will be no breaking changes introduced by an episode of CADT syndrome in the language or library design.

</comment><comment><USER30> I'll take the Python 3 road when the big stable distributions (Ubuntu LTS, RHEL & CentOS) start providing onramps to it by default, and include the packages we depend on in their default repositories.

I just can't get myself interested in rolling my own packages for the dozens of libraries I depend on, especially since they already "just work" with Python 2.

</comment><comment><USER31> > another year has gone by without considerable progress towards adoption of > Python 3

What planet does the author live on?

<comment><USER20> The real world.

<comment><USER32> That's the same real world where I routinely type "mkvirtualenv …", install a bunch of things and don't notice that I've been using Python 3 until the first time I toss a print statement in for debugging?

<comment><USER33> Which virtualenv's, regrettably, depend on OS-level packages. so when you go to deploy your app to production, you find you installed some system dependency long ago and promptly forgot about it. The real world is messy.

<comment><USER32> I've actually done this for years in the real-world. Yes, you can make mistakes. No, it's not a particularly hard problem to avoid and, as jonafato noted, --no-site-packages has been the default for awhile and I had it enabled by default for many years before then.

If this is a frequent challenge, it sounds like there's some technical debt to pay down elsewhere in your testing/deployment practice because it really doesn't need to be that hard.

<comment><USER33> I could be doing something wrong; I'm open to the possibility. And yet...

`psycopg2` is a pip package that won't install without system dependencies. Yes, I use Ansible and the system dependencies are managed. But, out of the box, on a clean system, `pip install psycopg2` doesn't just work.

<comment><USER32> The approach I use is to have the non-python dependencies managed externally – i.e. use APT/YUM for the postgres, mysql, redis, memcache etc. C libraries since those are very stable on a normal distribution – so a simple `pip install` will work as a non-privileged user inside a virtualenv.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> I realise that 3 has the nice async stuff, I get a little miffed that certain improvements won't make it into a 2.7.x (or even 2.8). Performance improvements for one.

It seems like the same attitude as the GNOME developers .. (disclaimer I use both GNOME and python, I must be a mashochist).

</comment><comment><USER35> Why hasn't someone written a good 2 to 2/3 converter which also updates old c libraries? Wouldn't that speed up conversion considerably? It shouldn't be too hard to do it for the c libraries as well, or am I missing something?

</comment><comment><USER36> Python 3's asyncio / co-routines is the reason to write any new project in Python 3.

The API is tiny, and the result is beautiful.

If you haven't seriously tried using it to implement something that really benefits from such computer science innovation, then you have simply seen nothing of Python 3 yet. There are many types of logic that are vastly simplified with such a programming paradigm. Faster to code, and far simpler to debug. By orders of magnitude. One example you could try if you cannot envision one is to implement a high performance network protocol. I for instance implemented the SSH protocol from scratch (RFCs) in a matter of weeks. I though it would take months before I tried, especially since I had never programmed in Python before! As I said, the API is tiny. Learning it (Python and Asyncio at once) was so easy and ended up taking such an insignificant amount of time compared to the vast quantities of time and headache saved, that, well, I just had to write this post with all that extra time and energy!

Check it out! You will find that it is beyond worth just addressing whatever fears or problems you have with making the switch.

<comment><USER37> As a big fan (and user) of Twisted, I'd like to see a discussion of why I might want to use asyncio instead, besides the So-You-Can-Use-Py3 reason.

<comment><USER38> I 'll add my experience with asyncio and twisted:

1) debugging is way better in asyncio, with ipdb you can step in co-routine. In twisted, you will end up somewhere in internals.

2) asyncio is end of _unhanded error in deferred_ :) (or you need to remember to add addErrback everywhere, even after addColbecks and addBoth)

3) with trial testing is frustrating, sometimes error raised in wrong test because of global event loop (for instance you forgot to mock external call). In asyncio world loop passed explicitly and this is good for testing.</comment></comment></comment>


Foreign Linux: Run Linux binaries on Windows without drivers or modification - <AUTHOR> https://github.com/wishstudio/flinux <comment><USER4> Cygwin is impressively complete - if you haven't checked in on it recently, there are over 5000 packages in the official repo (that's more than Arch Linux's official repos), and adding the [http://cygwinports.org/](http://cygwinports.org/) repo gives you full KDE, GNOME 3 and Xfce on windows (although KDE has a first-party port).

What this tool offers over Cygwin is the ability to run _unmodified_ linux binary-only software for which you do not have the source code. For me there's not very much of that although i release some at $DAYJOB.

<comment><USER5> My biggest gripe with Cygwin (aside performance on some syscalls) has been package management, which used to require setup.exe to add or upgrade packages. That was nicely mitigated when I found out about apt-cyg[1]. It's a apt-getish frontend for setup.exe command line. Not as nice as real apt-get of course, but "apt-cyg install something" takes care of the most important use case.

1: [https://github.com/transcode-open/apt-cyg](https://github.com/transcode- open/apt-cyg)

EDIT: changed to github url

<comment><USER6> It would also be really nice if Cygwin did a quick ping on all of the package hosts and then ordered them in order of least latency relative to you. Oftentimes I have to re-start the install process because I accidentally chose a host that's slow enough to delay the install for hours.

<comment><USER7> I wish it would sort by network throughput instead of latency.

</comment></comment></comment></comment><comment><USER8> This has been tried before as the author notes. E.g.

[http://lbw.sourceforge.net/](http://lbw.sourceforge.net/)

Previous experiments have stumbled on Linux usage of %gs and other segmentation issues.

The present project is possibly trying to overcome those obstacles with dynamic recompilation. It's in very early stages though.

<comment> david-given Hey, I resemble that project!

Yeah, it ground to a halt due to fundamental differences in the way Linux and Windows binaries work. I'm actually now kind of scared at how much _working_ hackery LBW ended up containing: it'd dynamically patch the binary after trapping out at instructions manipulating things that Windows wouldn't allow access to.

(The LBW instruction patching code is here. It's entertainingly bonkers. [http://sourceforge.net/p/lbw/code/ci/master/tree/src/ehandle...](http://sourceforge.net/p/lbw/code/ci/master/tree/src/ehandler.cc))

Not all the horror was Windows, mind: Linux's interface to executables is barely documented and extremely fragile, involving passing a key-value table full of magic parameters on the stack after the argument and environment tables. And, of course, I'd have to replicate this otherwise glibc would crash out. (At least, I thought I did --- I cannot now find any of the actual code. Maybe I got rid of it?)

I eventually gave up because it was obviously not a tenable approach. Plus, it'd completely fail on 64-bit platforms. Dynamic recompilation is obviously a way more preferable approach. If I ever have to use Windows again, god forbid, I'm definitely checking this out.

</comment></comment><comment><USER9> This looks like an interesting project to keep an eye out for. On the topic of cygwin, I would also like to recommend mobaXterm, that I use instead of cygwin nowadays... It is an interesting choice in the alternatives we have. So, those of you that use cygwin, take a look at it here: [http://mobaxterm.mobatek.net/](http://mobaxterm.mobatek.net/)

If you are thinking about trying cygwin, I would recommend this instead, as the installation is relatively easier when compared to cygwin. (I have no affiliation to mobaxterm)

Another new indispensible tool for me is cmder, which leverages ConEmu, clink and mysysgit to provide a wonderful UX in the commandline for me - <USER2> brilliant. Here: [http://bliker.github.io/cmder/](http://bliker.github.io/cmder/)

Memo to self: Spend the next 4 months learning powershell during lunch breaks!

<comment><USER10> The big problem with MobaTerm is that it includes really old versions of the standard unix utilities, and it's difficult to integrate with newer & missing utilities. This isn't a problem that's limited to MobaXTerm, but the way MobaXTerm does things makes it harder to fix.

Let's say you want to set up a standard dev setup. So you install MobaXTerm, vagrant, emacs, msysgit, and rsync. Each of these require SSH for full operation, so in the interest of making things easy, the installers bundle SSH. You now have up to 5 copies of SSH installed, all storing their private keys, cert stores and configuration in different places. What a mess. And some things aren't compatible with each other. IIRC, vagrant is built with cygwin, so you have to make sure you use a cygwin rsync with it, the msys rsync won't work.

To keep everything sane, start with the standard cygwin or msys installer, and install everything using that.

Does conemu include mingw-get? If so, that sounds like it might be a good solution. If not, I recommend avoiding it.

Or just reformat and install Linux. That's what I ended up doing. Putting up with poor HiDPI support in Linux was much more tolerable than the horrors of trying to use Unix utilities in Windows. And HiDPI support is improving quickly in Linux land....

<comment><USER9> I agree with your point on the very clumsy SSH tack-on take up with this approach.

About the older utilities, again, I completely agree. But, the way to create the mx3 bundles is easy. Actually, on the website/forums, several users there have been a few 3rd party utilities of the same. The format is transparent for anyone to create their own set of utilities on top of what mobs provides.

</comment></comment></comment><comment><USER11> So it's cool, and a lot of people might see it as a bad thing that if this took off could potentially bring Linux users back to Windows. I personally think it could do the reverse though and encourage people to try Linux. If they enjoy using some small selection of tools that work on Windows (presumably all CLI tools) then they might be convinced to give a full distro a go. Interesting concept though and I really hope it works out.

<comment><USER12> I think it would mainly be used by Linux users forced to use Windows for some reason (at work, for example).

<comment><USER13> I totally agree with you. Some of us who really like Linux are forced to use Windows at work. This project is really going to help a lot of people :)

<comment><USER14> But if you can run this, you can run VirtualBox, which is a much safer alternative (and simpler, if a live ISO meets your needs).

<comment><USER15> But not equivalent for some use cases. Like, say I want to use 'find' (not windows find.exe) to find files on a Windows filesystem.

<comment><USER16> What I typically miss on Windows is "rsync".

</comment></comment></comment></comment></comment></comment><comment><USER17> If this can bring me a working * nix shell under Windows, I'd be extremely happy. Windows is great for everything except I have never learned PS as well as I know the * nix shells -- with this, I could enjoy the hardware and proper multi-monitor support, speed and stability (seriously) of Windows and use the * nix command line.

<comment><USER18> To be honest, and I say this with a massive cringe, after 20 years of Unix I'm more productive with PS in a couple of months! It's quite refreshingly easy to use and I genuinely had no idea how much time I was wasting on parsing streams.

Now I feel horrible for revealing my dirty secret :(

<comment><USER19> What do you use for grep?

I tried using Powershell and did a few things with it, but while it is a great shell, the lack of good tools like grep prevented me from being really productive.

<comment><USER20> I've ended up with

Select-String "pattern" -Path file.txt | ForEach-Object { Write-Output $_.Line } | Out-File t.txt

Slightly Heath Robinson, but by default PS will _truncate_ lines to terminal width, even when writing to a file, which is a disaster for any kind of subsequent machine processing.

<comment><USER21> For the uninitiated this looks completely barbaric, but makes a whole lot of sense when you consider that PS is built around an object-based pipeline. 'Select-String' in PS doesn't actually return a string, but a 'MatchInfo' object, which contains more properties -- 'linenumber', 'context', etc, as well as the 'line' property which contains the actual matched lines as strings. The default output from any part of the pipeline is a human- readable/terminal-display-compatible representation of the object's commonly used properties, thus the truncation.

As an aside, you can replace the foreach with select-object for an efficiency gain:

        sls "Pattern" file.txt | select -exp line | out-file t.txt

<comment><USER22> You also don't technically need to go through Select-String if all you care about is the line itself:

        (gc file.txt) -match "Pattern" | Out-File t.txt

Comparison operators that get an array as their left argument return the items where the comparison returns true.

</comment></comment></comment></comment></comment></comment><comment><USER23> Always nice to have more alternatives, but I find either [http://bliker.github.io/cmder/](http://bliker.github.io/cmder/) (a tricked out console with a nicely tweaked git bash environment) or [http://babun.github.io/](http://babun.github.io/) (Cygwin but easier to install and with nicer defaults) better for daily use when forced to wallow in the Windows pool at work.

</comment><comment><USER24> Firstly, this looks brilliant. If anyone can remove the extra layers of cygwin, mingw, xming etc. and provide a direct ability to execute linux programs from powershell/cmd , I call Black Magic. Voodoo I tell you; Windows cannot be this user friendly (I work with it every day).

Secondly, completely off topic, I noticed that Github picks up 0.4% of the code-base as Objective-C ([https://github.com/wishstudio/flinux/search?l=objective-c](https://github.com/wishstudio/flinux/search?l=objective-c)) due to the files functionally consisting of a single line, `#pragma once`. Is this statement more common in Objective-C than C or C++ ? Just wondering if Github detects the language based partly on some statistical analysis of other existing code, or if it has "set rules".

<comment><USER25> Github's language detection is actually open-source — you can have a look at what it does here: [https://github.com/github/linguist](https://github.com/github/linguist)

Linguist uses a number of different 'strategies' to identify the language – in the case of C vs. Objective C, it uses a pretty simple heuristic ([https://github.com/github/linguist/blob/master/lib/linguist/...](https://github.com/github/linguist/blob/master/lib/linguist/heuristics.rb#L83-L90)) to disambiguate C/C++/ObjC where required (such as in header files, which can't be disambiguated by file extension.)

In this case, the content of the file can't be reliably disambiguated, so I imagine it'll probably fall back to the Bayesian classifier. Interesting that the classifier identifies it as Objective C though!

<comment><USER26> I'm not a programmer so bear with me.

They have a cadre of samples in the project, searching on "#pragma once" shows no examples of Objective-C (that I can see) using that line but does show C/C++ examples with it. Is that the input to the classifier?

The heuristic you linked appears to default to identifying as C; that regex doesn't look like it has anything to make the else-if return the sample as Obj-C.

I'd have expected the fact that most other files on the project were C to be the dominant factor that - without any other positive result in the classifier - would weight the files as being C. Presumably this data isn't used in classifier though?

Interesting.

</comment></comment></comment><comment><USER27> This is quite funny, since you can't run _unmodified_ linux binaries on other linuxes (that is a binary distribution on linux is generally not a thing and there will always be a distribution that does stuff just differently enough), so a recompilation on windows sounds like as good of a solution.

<comment><USER28> I remember from trying to use Linux on a desktop machine (and this was like a decade ago so maybe it's no longer relevant) that graphics drivers were often distributed only as binaries.

<comment><USER29> And I remember (from a decade ago as well) having to recompile my kernel to use those binary graphics drivers :)

</comment></comment></comment><comment><USER30> This is brilliant! Much more light weight than a VM. I hope they can iron out the remaining kinks.

I used coLinux many moons ago, but it hasn't been updated in any significant way lately, and still doesn't work on 64-bit Windows.

<comment><USER31> It's a shame - it looks like the work was started, it probably isn't _too_ much work to fix the 64 bit stuff ??

<comment><USER30> I think it's in part because 64-bit requires driver signing, and there are no funds for signing the coLinux64 driver.

</comment></comment></comment><comment><USER32> Very impressive. I'd appreciate if they could get WINE working under this though..... :-)

<comment><USER16> Actually there is an effort to make wine compile and run on Windows.

[http://wiki.winehq.org/WineOnWindows](http://wiki.winehq.org/WineOnWindows)

<comment><USER33> That's interesting, I wonder if it's mature enough to run on itself :-)

</comment></comment></comment><comment><USER34> "Linux services for Windows NT"

</comment><comment><USER35> This reminded me, with some nostalgia, of a long time ago using Cooperative Linux on my work Windows machine with sole intent of being able to use Amarok as my media player.

(Version 1.4, before Amarok turned to crap. I use Clementine now, which has a native Windows port.)

</comment><comment><USER36> I admit that I am a bit lost as to the value of this endeavour, or Cygwin for that matter, in an era where just about all commodity hardware can sustain virtualisation.

I used to have the problem of my dayjob requiring me to run Windows and use Outlook/Exchange, and Cygwin was a useful means of coping with that. But that was back in 2006. Now, it seems to me one should just fire up a Linux VM in VirtualBox, full-screen it, and pretend the encapsulating Windows doesn't exist.

<comment><USER37> _or Cygwin for that matter, in an era where just about all commodity hardware can sustain virtualisation._

I use cygwin primarily as an ssh client for my local linux VMs. My IDE is vim/tmux/zsh, and I've found ssh via cygwin provides an experience that closely resembles gnome-terminal in appearance and behavior (gnome-terminal being the best terminal emulator around IMHO)

<comment><USER38> seems overkill, wouldn't just putty do in your case?

<comment><USER37> As I said, I prefer cygwin's look and feel to the alternatives. Also, cygwin supports transparent windows out of the box. I don't think it's overkill at all, the only package you need is ssh, everything else lives in the VM.

</comment></comment></comment></comment><comment><USER39> Wondering how well fork() works?

<comment><USER40> I was wondering the same thing. The features page claims "copy on write fork implementation" but that is not universally true. A cursory look at the code suggests that every allocation is a Win32 file mapping object (aka NT section) underneath, which the fork worker (mm_fork) remaps into the forked process. This means the memory is shared between two processes, and not in a CoW fashion. A write to the memory region from the forked process will be visible in the parent. These are not correct semantics for fork.

I am hoping I misread the code and someone can prove me wrong here, because it looks like a cool project with a lot of potential.

<comment><USER39> From little I've read on cygwin mailing list (btw, cool folks over there) - <USER3> seems the problem is not very easy. If I'm not mistaken the Windows Kernel actually does support fork()-ing, but the win32k system somehow "forbids" it (lots of grains of salt). After all for a long time there was a commercial UNIX compatible offering on Windows that probably used fork() all over and must've worked (also it supported case-sensitive names for the filesystem)

BTW, the coolest usage of fork(), and granted a pain in the ass to port possibly was the one in REDIS where antirez used it to fork() at certain time the current process, then write back the state of memory knowing that it'll get a "snapshot" of it, and if writes to disk succeed, this "snapshot" would correctly and fully be written to the disk.

I know there are plenty of other uses (for example this way "lua" can do threads with just a bit of a communication library on top... e.g. any language without explicit thread handling can actually use them).

Wondering what made win32k folks disable it. Possibly there are lots of gotchas...

<comment><USER41> Using fork to get a "snapshot" of memory seems... like a roundabout way of doing things. The underlying memory mapping mechanism should expose a simple way of just doing it directly. (I _still_ don't understand the point of fork, especially when most of the time exec is just gonna overwrite things anyways. And the impact fork has is to massively increase potentially used memory, leading to the dumb memory overcommit semantics and hack fixes like OOM killer.)

<comment><USER39> Yup. indeed, but it seems so elegant, in the same way (elegant) as one can implement undo using closures - at the expense of unaccounted resources (cpu, memory, who knows what else).

From redis's page: [http://redis.io/topics/persistence](http://redis.io/topics/persistence)

"RDB needs to fork() often in order to persist on disk using a child process. Fork() can be time consuming if the dataset is big, and may result in Redis to stop serving clients for some millisecond or even for one second if the dataset is very big and the CPU performance not great. AOF also needs to fork() but you can tune how often you want to rewrite your logs without any trade-off on durability"

</comment></comment></comment></comment></comment><comment><USER42> As cool as this is, a remaining problem I'd have for using Windows is that I've found git to be slow there. For example, the responsiveness of 'git status'. I'd guess this is something to do with NTFS being optimised for things different than unix-tradition filesystems. If so, this tool wouldn't improve that. Does anyone know more about this area?

<comment><USER43> Git is built for Linux and relies on some features of Linux filesystems for speed. As long as underlying filesystem is NTFS, there's no way to speed up Git.

Although, the "Support NTFS native hardlinks and emulated symbolic links" could be relevant if it does some magic there.

<comment><USER44> > Git [...] relies on some features of Linux filesystems for speed.

Modern NTFS versions support all the things that git needs, so it has less to do with having magical features in Linux filesystems per se and more with the fact that they aren't properly mapped onto respective NTFS features in the abstraction layer (MSYS or similar).

</comment></comment></comment><comment><USER45> I really want Linux emulation for OSX, which should be much easier. FreeBSD had very usable Linux emulation on a similar kernel.

</comment><comment><USER46> Cmd.exe is an abomination though - and Cygwin defaults to using it for terminal use. I see that this project also does that.

<comment><USER47> > Cmd.exe is an abomination though

Agreed, but I don't think Cygwin defaults to it any more. It uses mintty now, which understands Cygwin ptys and has a native Windows interface.

I guess you could also use an X11 terminal emulator in this project.

<comment><USER30> Correct. Cygwin has used mintty as a default since 2011[1].

[1]: [http://cygwin.com/ml/cygwin- announce/2011-11/msg00040.html](http://cygwin.com/ml/cygwin- announce/2011-11/msg00040.html)

</comment></comment></comment><comment><USER48> I am getting error when using go

[root@ForeignLinux ~]# gccgo hello.go -o test /tmp/cc06PbMI.o: file not recognized: File truncated collect2: error: ld returned 1 exit status

[https://wiki.archlinux.org/index.php/Go](https://wiki.archlinux.org/index.php/Go)

anyone experienced this?

</comment><comment><USER49> I don't understand what this is supposed to accomplish. What's the advantage of building on GNU/Linux and running on Windows compared to building on Windows and running on Windows? Seems like it's needlessly complicating things making a binary compatibility layer.

<comment><USER8> It's trying to accomplish exactly the same as Wine, only vice versa.

There is a considerable amount of software written and compiled for Linux that is not available on Windows.

</comment></comment><comment><USER50> Unfortunately seems to crash immediately on Windows 10 Tech Preview (build 9926). It's what I can expect for using a prerelease OS though.

Edit: It looks like this might have been something on my end. Re-downloaded and extracted and it seems to be working now.

</comment><comment><USER51> Personally I have been using Scoop with ConEmu. I find that is enough for most things :)

[http://scoop.sh/](http://scoop.sh/)

[http://www.fosshub.com/ConEmu.html](http://www.fosshub.com/ConEmu.html)

<comment><USER31> Is Scoop better than Chocolatey? I like chocolatey, but things dont install semi-regularly.

<comment><USER51> I prefer it over Chocolately, however Scoop is mainly aimed at developer tools on the command line. Scoop is more a replacement for Cygwin.

Disclaimer: I'm a Scoop contributor.

</comment></comment></comment><comment><USER52> this is the exact opposite of WINE, implements linux sys calls in windows

</comment><comment><USER53> Midipix is due soon and provides a system call interface for Windows and a Linux libc.[http://midipix.org/](http://midipix.org/)

</comment><comment><USER54> Does this support running X over SSH? The biggest drawback for me with Windows boxes was always a lack of X support for applications I want to run on remote servers.

<comment><USER55> Yes. From the stock bash prompt, run "startxwin". With the resulting xterm, you can launch any X apps within Cygwin, or you can SSH in (with appropriate flags and xauth config, etc.) and blow back X apps from the remote Unix box. It's really nice.

</comment></comment><comment><USER56> interestingly I wasn't able to run vi, but could run vim. I reported to the github issue tracker.

This seems very neat. Definitely much less overhead than VirtualBox. Plus can write to the same filesystem as windows without windows admin privileges (which can be done with cygwin, but not with virtualbox). Once it supports x86-64 binaries and threading and users, this could be very useful.

</comment><comment><USER57> So this is the opposite of Wine for Windows?

</comment><comment><USER58> Cool. CoLinux does something similar

<comment><USER59> I thought it's been dead for ages

<comment><USER60> This is one of the things that's always driven me nuts on Linux, and also one of the things I really like. Some projects that are interesting like this seem to disappear for a while, but often the concept will be resurrected under a new project. CoLinux is one of them, UserFS (now FUSE) is another one that went away for a couple kernel versions and is now back. I'm still waiting for an SSI (single system image) to make a comeback though (Mosix, OpenMosix, OpenSSI, but none of them work with newer kernel versions).

</comment></comment></comment><comment><USER61> That's like Wine in reverse?

</comment><comment><USER62> very nice project! I hope it takes off running applications on cygwin can be a pain</comment>


Password strength analysis based on countries - <AUTHOR> http://fsecurify.com/password-analysis-based-on-countries/ <comment><USER2> > We see that Russia has lower percentages when the password lengths are less > than 10 and the percentage increases as we go to higher length passwords. > This could mean that people are more aware of good password practices.

Russians commonly make passwords from Russian dictionary words by pressing the respective Russian letters on their keyboards but without actually switching to Russian language. Also for this reason it seems Russians are not using top 50 most common passwords, while in reality they surely do, it's just 50 most common _Russian_ ones.

As for China, was the breached service not blocked by firewall and commonly used by ordinary Chinese? Are you sure you're not analyzing just Hong Kong instead of all the China?

Raw stats like that are misleading. One has to consider how these countries' languages, cultures and political peculiarities affect usage of Internet services.

</comment><comment><USER3> >I used a public database that was breached and had IPs of users and used those IPs to get their locations.

I wonder if this analysis is based on a data set with leaked clear text passwords or cracked hashes.

Given that never all hashes are cracked but only the _crackable_ (whatever that means) that would heavily bias the analysis.

<comment><AUTHOR> The dataset consisted of clear text passwords. No hashes.

<comment><USER4> The point was that these password were cracked at some point, and those hard to crack were less likely to appear in this database and that skews the analysis.

<comment><USER5> Not if they all was stored in cleartext from the beginning - which, unfortunately, a lot are.

</comment></comment></comment></comment><comment><USER6> Countries that speak English and use English keyboards are going to show up as weaker in this kind of analysis, because the "top 50 passwords" heavily features the likes of "football" and "qwerty". I'm not sure what "top 100 password patterns" could mean.

These users (USA, then to a lesser extent India and Pakistan) really do choose objectively weaker passwords, because those passwords will be tried first by most automated password crackers. But it's not correct to conclude from that that the users have worse security practices. A better test for that would be to check against the most common passwords within each nation's corpus.

<comment><USER7> While the "top N" password lists are likely english centric, the other parts of the analysis aren't.

Things like "length of password" or "percentage of users using their name/email in their password" is not something that is language dependent.

That said, the wording of some of the passages appears to be one of "India is better than China at passwords." As the author appears to be Indian ("1.5 lac") there could be a hint of nationalism in this.

<comment><USER8> Length of password is partially dependent on language (e.g German words tend to be longer on average).

Also, many languages have their own diacritic characters (å, ä, ö, etc.), which, when used in password, will be counted as "special characters" (because they do not match standard [a-zA-Z0-9] regexp).

So yes, password safety is at least partially influenced by user's language.

</comment></comment></comment><comment><USER9> Page is empty for me. When I checked an archive site, it appeared to redirect to a probable malware site. [http://archive.is/cYDEp](http://archive.is/cYDEp)

<comment><AUTHOR> Please use this link. There is nothing malware related anywhere.

[https://web.archive.org/web/20170514081120/http://fsecurify....](https://web.archive.org/web/20170514081120/http://fsecurify.com/password- analysis-based-on-countries/)

<comment><USER10> Don't do this. Costs them money and being a CDN is not their business plan.

There are "legit" free CDNs if you can't handle the traffic yourself.

Also note Google will penalize you hard if you keep going offline every time you are linked to.

<comment><USER11> > The Internet Archive is a 501(c)(3) non-profit library. Founded in 1996, our > mission is to provide Universal Access to All Knowledge.

[https://archive.org/about/](https://archive.org/about/)

If a book store was sold out of a popular book would you discourage people from looking for it at the library? For all we know this information has been destroyed and the internet archive is the only place it exists now.

<comment><USER10> I would discourage the book publisher from only printing a shirt run then sending would-be buyers to the library asking them to make photocopies for everyone for free.

This person was directing overload traffic via archive.org as a CDN.

My point is, there are places doing that as an offering.

For example, CoralCDN at [http://www.coralcdn.org](http://www.coralcdn.org) is a peer-to-peer (P2P) based content delivery network which is totally free.

To use it you just have to append .nyud.net to the hostname of any URL, and your request for that URL is handled by CoralCDN.

Don't leech archive.org, let them spend their money on collecting and storing all knowledge, not as a hosting overflow provider.

</comment></comment></comment></comment></comment><comment><USER12> Offtopic, but that website header sure is distracting, on my laptop it uses 266 out of the 633 vertical pixels space I have for the page.

[http://imgur.com/SRkTL5w](http://imgur.com/SRkTL5w)

<comment><USER13> I have this bookmarklet I use all the time

        javascript:(function()%7B(function%20()%20%7Bvar%20i%2C%20elements%20%3D%20document.querySelectorAll('body%20*')%3Bfor%20(i%20%3D%200%3B%20i%20%3C%20elements.length%3B%20i%2B%2B)%20%7Bif%20(getComputedStyle(elements%5Bi%5D).position%20%3D%3D%3D%20'fixed')%20%7Belements%5Bi%5D.parentNode.removeChild(elements%5Bi%5D)%3B%7D%7D%7D)()%7D)()

<comment><USER14> Very nice</comment></comment></comment>