skysight-inc/HackerNews huggingface dataset:
> You did not describe your approach to a problem yet. How would you implement an optimising BNF-based eDSL without macros?

Let's get more concrete. What does the business requirement look like? Do you mean "a language that happens to be expressed in BNF", or are you asking for a DSL for expressing languages which itself looks like BNF?
I believe the "/or" was added after it was submitted the OSI and FSF, because they felt that it could be misinterpreted without. However it appears that OpenBSD didn't change their version (probably because they don't believe it's ambiguous).
Is there anything that makes this sort of practice unlawful?
That's probably true for most periods in history, but we're still within a much-receded housing economy. When I bought my house, my rent was a couple hundred bucks more and with insurance + taxes I ended up paying ~ $30 more a month for more than double the space and, of course, actual assets.

There are places where this doesn't make sense, and there are times where it absolutely doesn't make sense, but present day is a lot different. My anecdote of paying less (or slightly more) in mortgage + associated versus rent is not all that uncommon these days.

The real hidden cost, if you ask me, is the way it changes your sense of mobility.
6 must know tips to protect your privacy
I know this isn't true everywhere, but the last time I did a similar calculation, based on the historic rate of rents increase in my area, buying the house, then just walking away at the end of 30 years was cheaper than rent.
I've had a LinkedIn account for over 11 years now. Pretty much the only thing that it has done for me is caused a few hundred salespeople to look up my contact information and try to sell me something.
If i understand you right, you want to do this:

- Checkout master.
- Start an interactive rebase of master onto the last
commit before the series of commits you wish to remove.
- Mark all the commits you don't care about as "skip".
- Let the rebase run and resolve conflicts on the way,
the same as you'd do with your current work flow.
The Future of Messaging Apps – China as Reference?
The money is certainly important.
But buying is better than renting in many ways.
Want to rip out your kitchen and have a new one?
Want to pave part of the garden?
Want to move a wall?
Want to paint it all, or fit blinds?

If you own it you can do all that. If you rent you have to ask permission which you might not get. Plus why spend money on somewhere you don't own?
Unpatched OS X, iOS flaws allow password, token theft from keychain, apps
Hype sells. A secretive back room internet where nefarious types hang out en-mass evading law enforcement is more marketable than reality.

As someone who's done a fair bit of 'dark web' browsing, still the most frightening things I've seen have been on 4chan.

And of course the govt would love for you to think that the dark web is something only for criminals.
It is not quite as easy or quite as reliable as it with merges, but generally "branches" come in as recognizable chunks of commits, and you can either revert them with a range, or interactively rebase them out of existence, depending on your goals. It's generally not very difficult, but in some cases it may be.

I'd also suggest that you want to make sure you consider the full totality of costs, because it's very humanly easy to see this one feature that you recall using a lot, when in fact you can easily recall it precisely because it is a rare event (and thus worthy of memory), whereas the costs of a complicated branching structure are continuous and ongoing.

I'm not saying that linear is therefore guaranteed to win for you, just pointing out the cognitive danger of seeing the big, rare expensive costs and missing the continual drip of small ones.

That said, I'm not necessarily 100% linear myself, but I do sometimes feel like git made branches easy and some people overreacted. If you've got a branch that lived for at least, say, a week, and had significant independent work within it, then by all means merge it and keep a merge commit. But this workflow creates branches upon branches upon branches, and then keeps them around forever in the history. I'm not convinced that last bit is necessarily a good thing... I create a ton of branches, sure, but I only keep big ones that actually mean something, not every little bug branch with one commit of one line. There is a happy medium available here, too.
FCC: Telephone companies can block robocalls and spam texts for you
Zero Trust approach to network security
some long-term job listings come from:
> the larger companies are for roles where there is constant churn (or growth) and they need to keep the pipeline of active candidates warm
> As mentioned already, spammy recruiters looking to collect cv's

Also:
> Companies are in-undated with applications and really can't separate the wheat from the chaff. They have thousands of resumes for one or two job openings because its so easy now to apply online and click submit. Perversely the harder they make
it to apply online, causes those most in need of a job to jump through hoops to fill out a complete application

Tried hiring help on a local jobs board I was swamped and astounded with volume and eagerness of the responses. Ended up going with someone who was recommended by a friend as I didn't have the resources to process and filter the applications
I'm not sure they can test for alcohol since it is federally legal (I know that most places would test for on the job incidents however. I'm meaning it in a "drug test" style screening). Aside from that, I'm not sure how long you can find traces of it in your system. I wouldn't guess it to be longer than 48 hours.

EDIT: parentheses content.
That's OK, you know just as much about the 60s as those who lived them. You had to read about them. They had to too because they don't remember them. :-D
How to hack into an email account, just by knowing your victim's mobile number
On the plus side, once you've found somewhere you like you can stay there as long as you want. If you rent it's up to the owner how long you can live there
This is not true.

I've been part of the hiring process repeatedly throughout my career, and while it's nice to find a candidate's LinkedIn profile, it's far from necessary.

In terms of hiring front end engineers, I want to see a portfolio. For back end engineers, I want to see source code - preferably on Github. But LinkedIn? That's a nice-to-have, nothing more.
Hey Google, what's trending? Oh, just the death of journalism
Roadmap: After 7 years exos capable for space launch? Did I hear that correctly?
Best answer I ever heard was "because it's sticky".
The professor disagrees with you:

"When water freezes into ordinary ice, which is the kind that makes the ice cubes that float in our highballs, this happens at what we would call zero degrees centigrade, at atmospheric pressure. When water freezes into ice it creates a very open structure. That form of ice comprises arrays of six membered rings that are stacked on top of one another to make channels and most of that ice is actually empty space."
Yes you have; Goldman Sachs, the big bank bailout, subprime mortgages, etc. Bitcoin's story is peanuts compared to the financial crash in 2008.
Anyone else fed up of articles using "considered harmful" in the title? Especially when it's just that the author doesn't like that thing.
US Personnel Agency Isn't Sure How to Tell Millions of People They Got Hacked
Not true in the slightest. It can be helpful (recruiters seem to peruse LinkedIn for a living) but I've never had one and I'm doing fine so far.
As a fresh grad interviewing for (real, non-internship) jobs for the first time, I'm really surprised at how long the hiring process is. The article mentions 23 days average. I'm currently interviewing for a BigCo where I already had done an internship, so they knew me. After I contacted my former supervisor, it took him 2 weeks of wrestling bureaucracy to open a position, then HR insists on collecting CVs for 4 weeks, after which I got a phone screen. HR lady told me she would be phone screening for 2 weeks before passing on the CVs to the hiring manager who would contact people for in person interviews.

I'm finally scheduled for an interview next week. But really, 60 days before even interviewing a candidate they already have experience with? I'm surprised they even manage to hire people before they are extended another offer. But then again, this is not programming.
> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this...

It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless.

In general, I'm starting to dislike "XXX considered harmful" articles. It seems to me like you can spout any opinion under a title of that format and generate lingering doubt, even if the article itself doesn't hold water. Not to generalize, of course--not all "XXX considered harmful" articles are harmful. They generally make at least some good points. I just think the title format feels kind of clickbaity at this point.

That said, kudos to the author for suggesting an alternative rather than just enumerating the shortcomings of GitFlow.
These calculations are interesting, but there are many more factors involved. For example, I am roughly 50 years old, have chronic health problems, and live in an area where both the median and average housing unit prices are around a million dollars. Even with very low interest rates or even cash up front the costs of renting over even better than expected lifespans are very competitive.
IIRC all US government contractors have to be tested on hire.
Most of the large temp firms also do drug testing in the US (in my experience at least.) Never tested for booze, though everywhere I've worked on site has made it clear that you will be drug tested and breathalyzed in case of an on-the-job accident.

As i've moved up in job quality it has gone from "we will test you aggressively to see if you do drugs" to "why would we care about this?"

Practically it is very stupid because the heroin/meth/cocaine type drugs become undetectable within days while pot takes weeks.

It's a dumb US thing, basically.
I wonder how well the secondary market could be used to gauge the long term appeal. Would people sell it because they stop using it or it is like those skinny jeans you keep because one day you will use it again?

I will say that it was neat and then lost interest, but later once I had some "fitbit friends" the gamification went up a major notch as has the stickiness.

But within a few years either FitBit bands will turn into watches or users will replace their FitBit with a watch. So from the FIT perspective it hardly seems like a stable investment especially at the current market cap.
>"The world belongs to people who code. Those who don't understand will be left behind".

What a bizarre claim to make. Building houses is a necessary occupation in all societies. Are those of us who are ignorant or simply unwilling to learn the myriad skills needed herein 'being left behind'?
Seems like the kind of story you see just before a call to expand the H1-B program. I've worked with many fine H1-Bs but its purpose is to fill a need you can't fill locally, not to get someone to take a job that is underpriced.
Yeah imagine how many tents you can fit on a truck that size! 100s maybe a thousand. Let alone can a truck get into the disaster zone?
I second the feeling of GitFlow being over-engineering: http://blog.talles.me/that-git-flow.html
I've always heard them called sensory deprivation chambers.
I wasn't find the article now, but wasn't wired a huge part of creating this myth?
Even just an annotation "This post represents multiple open positions" might be good. It also directly sends a message you want to send ("we're growing and hiring lots!"), instead of implicitly by number of listings, which might be missed by a candidate doing searches.
That’s obvious to me. GitHub is a web application, catering to web users. Web users, that is, who also are git users – i.e. most likely programmers. Obviously they are going to write (and be involved in) web related projects on GitHub.
OK given that this is true which it may well be but is a matter of current research neanderthals ceased at some stage to be a separate group from homo spapians. The time was well before the Scandinavians appeared.
> I thought it was a weird, over-engineered solution to a non-existent problem.

To be fair, its a cookie-cutter approach that resonates with people unfamiliar with git but not ready/willing to invest the time to understand it deeply. That is understandable; a lot of people come from other systems and just need to get going right away and gits poor reputation for command-line consistency etc. is well-earned.

(To be clear, I am not a fan of git flow.)

If anyone is interested in truly understanding git, start here: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
This seems like a massive step backwards. And it's not for the benefit of the user (the programmer, she needs to do more work). It's for the benefit of the RethinkDB programmer (query planners are hard work!). Add an index in SQL? Existing queries work and can make use of it. Add an index in RethinkDB? Now go rewrite all your code if you want to take advantage of it. That's an improvement? (And do you think the average javascript programmer will do a better job at it than 30 years of database research?)

If you're trying to spin shit into gold, maybe you should try a rethink preprocessor. Just write normal SQL in your code and the pre-processor verifies the tables and columns, checks for indices, and writes the best "explicit" query for you.
I dunno. I kind of agree with IMAX here. IMAX doesn't mean "really big movie screen", it means "particular brand of really big movie screen with particular quality controls over image projection".

And I do think that's a potential valid source of confusion with consumers, who could potentially think SteamVR lives up to the same image projection standards.

It's not as clear cut to me as Ars is making it out to be.
Again: how is the server deciding when to block content? If that's done by IP, then by changing your IP you can view the articles again.
I've been working on a similar project for a couple of years now (http://jamieiles.github.io/oldland-cpu/) and these are very rewarding projects - there's a great mix of hardware and software so there's always something interesting to work on.

One of the most valuable lessons that I've learnt from this is to treat the FPGA as a validation target, and the FPGA tools purely as a way to produce that image - they're entirely unfriendly to develop in. If you use verilog then verilator gives lightening fast simulations and you can use it to verify the hardware against.
Business-oriented publications and companies that are hiring always seem to carefully avoid the easy way to fix long hiring times: Increase wages.
I don't agree with it. There are many other projects that many web developers use. For instance: editors, databases, linux utility tools and so.
IMAX Corporation tells Ars Tecnica not to use the word ‘IMAX’
Hiring velocity is one area where small companies can use their agility to advantage when competing against larger companies for talent. As a hiring manager, I always endeavor to make this process as streamlined as possible.

A couple of anecdotes:

I was able to hire an outstanding candidate simply because I got them through the process and extended them an offer. Our competition was a reasonably high-profile company in the area. In the end he joined us because after more than a week, the other company was unable to execute their paperwork to get an offer generated.

More recently, I saw a very big name West Coast company (think Google/Facebook/Uber) lose out on a great person because they had a third party do a reference check. In the time it took for that check to happen, the job seeker had lots of time to re-consider the offer and instead ended up working for a smaller company on the East Coast which kept in touch and was able to move blindingly fast.
If this synced with the system reminders I'd be sold.
The claim seems to be that some aspects all possible jobs (even building houses) will require at least understanding the premise and possibilities of programming.

There will be more and more jobs that require the basic skills of coding and less and less jobs that require the basic skills of house building. That is what is meant by "left behind". Obviously the best house builders will always have jobs, but the mediocre ones who once were good enough to get basic jobs on most building sites will be in less and less demand.
Hazard pointers are by no means fast, but a single hazard pointer being set per operation on a shared data structure barely registers compared to the cost of the rest of a nontrivial concurrent access most of the time. Scoped threads don't require bumping a reference count on access, either. Concurrent immutable access in Rust requires literally no overhead at all. In the long run, throughput might drop if you have to take a lock on the entire data structure to perform something like a resizing operation, of course, but for many applications this can be completely avoided (and for those that can't, Java isn't much better).

I generally agree with you on GC but, assuming you haven't, I think you would benefit from actually trying to write some of these algorithms in a manually memory managed system. It's really not as hard as you consistently make it out to be in a language like Rust with very precise control over lifetime (which can be exploited just as well for the hazard pointer itself as it can for anything else).
Exactly. I love this process, and endeavour to drop all dev/develop branches from the repos I'm working in. Sensational headline aside, I've seen a lot less untangling when feature-branching off of master and a judicious use of tags.

While it's dated at this point, I've always felt that the Github flow [1] works best (for the projects I'm involved with anyway).

[1] http://scottchacon.com/2011/08/31/github-flow.html
Imgur in the terminal
I've heard this can give you interesting waking nightmares and is a form of torture. Are you certain you want to try it?
His point is that this cookie-cutter approach is more complex to the development model he presents (and is in fact pretty common among open source software). You don't need to understand Git deeply to realize that master is stable and merges in finished and cleaned up features.
> it means really big movie screen

It used to mean that, not any more. IMAX screens are allowed to be much, much smaller than before.
Developer here. Asked to take a test, to work as an Austin-based employee of a Chicago company, owned by a Texas company, that owned (among other things) a warehouse that shipped guns purchased through their brick & mortar stores.
Definitely true, but it's not just recruitment firms that leave dummy jobs up. Startups do this all the time, especially for competitive roles like software engineer and UX designer. It allows internal recruiters and hiring managers to perpetually keep an eye out for good talent. It also makes the companies look like they are doing well and growing.
The tools don't get you the job
And when the factory employing most of the people in the town closes down, you're stuck with a virtually worthless property forever. Buying may have real downsides when you need to work for a living...
Also this is a problem with Git not GitFlow. In Mercurial, for example, every commit is attached to a branch so it's very easy to follow where the changes happened.
Keep JavaScript Small [video]
Any 10gb Ethernets? SAS controllers? Latest server chipsets? Support of NUMA architectures?
the article mentions 27 days as the average time from job candidate to actual employee. This seems like a very reasonable amount of time for anything that is not traditionally high turnover like retail, certain service industries etc.

I like to give at least 3 weeks notice simply because it usually takes that long to transfer all my projects and responsibilities. That only leaves 6 days for the active screening and interviewing process.

The article seems to be covering very general employment and job statistics so most likely the 27 day average vacancy is quite high for service and retail positions and fairly low for tech positions.
You tend to see drug tests a lot in retail, fast food, and many other low-wage low-skill jobs. I truthfully have no idea how effective that is in weeding out people who would be generally unreliable, but that's often the justification given by managers.

I'm sure there are some ultraconservative companies that drug test everyone — including developers and senior managers — but those are few and far between in comparison.
I have often pondered the question of how much we'd know about biology today if biologists had the same tools we did. Can you imagine the progress we could make if we could freeze a cell, set watchpoints on any molecules we wanted, step forward and backward at any time increment we chose, run arbitrary queries, make arbitrary changes to the running cell in an arbitrary tree of possibilities, and do this on any cell we liked? A competent biochemist team could probably discover more in a week, and with greater confidence, then the they would in their entire lives the conventional way.
Maybe in US it is cheap to rent, but at least in Poland, if you can get a mortgage, your mortgage monthly payment is often much lower than the rent payment for the same property. Renting here is only good if you don't plan to stay for long or if you actually can't get a good mortgage, because your income is low. The more you earn, typically the better interest rate you can get with mortgage (mine is currently 1.8% total), and with decreasing rate you're paying less and less with every year, contrary to more and more when renting.
They made me do it when I worked at an investment bank.
Show HN: MapChat – A simple location based chat in 300 lines of code
Most of europe?

Don't get me wrong there still is institutionalized hatred here but at a scale 2-3 order of magnitude under the US.
The only thing GitFlow had going for it is that it has a clearly written article about it with pictures that explain how it works. That's it; the freedom of git and being able to define what works for you is too much for people and they think they need to turn development back into Subversion-style or desktop-release style.
Again - then why not just explicitly ban it altogether? Why say it's allowed under certain parameters and then ban users anyway when they meet those parameters exactly as required? They obviously have a list of products/transactions deemed too high-risk by their contract, they need to state what they are explicitly if they want to stop the PR bleeding.

I've been doing this for four years and we've never had a single dispute, but that's really neither here nor there.
A reason that we are switching from full git flow to a reduced model (basically one master branch + feature branches, occasional hotfix branches) is that git flow isn't compatible with continuous integration and continuous delivery.

The idea of CI is that you integrate all commits, so you must integrate the develop branch - build the software, run the tests, deploy it to a production-like environment, test it there too.

So naturally, most testing happens in that environment; and then you make a production release starting from the master branch, and then install that -- and it's not the same binary that you tested before.

Sure, you could have two test/staging environments, but I don't think I could get anybody to test their features in both environments. That's just not practical.
They mention the fact that Beats uses generic $1.80 off the shelf speakers within despite claiming things like "Fine-tuned acoustics for clarity, breadth and balance".