skysight-inc/HackerNews huggingface dataset:
My biggest problem with "A successful Git branching model" is that it scares people into thinking they have to design and commit to a workflow before they can develop software.

Having a defined workflow is not a bad thing. And it certainly wasn't the intention of the author for anybody to stagnate. Unfortunately, it's very natural for technical people to overthink and over-engineer process.

In my mind, when an organization is new to source control or is haphazardly using it, it's best to simply start using the tool. Each product is different, each organization is different, and each developer is different. You should mature into an organized development model based on what you know about your own situation.

If you develop on the develop branch and release on the master branch, but don't communicate that clearly to the new guy, I guarantee he's going to start working on master right out of the gate. The same goes for every model where there's a lack of communication around procedures and no workflow controls.

Git saw a rise in popularity because it was easy where every other solution was difficult. If you're having issues with code review, patches, release versioning, or whatever - address that particular problem. If the problems are multiplying to the point where it's significant, it's time to think through a process. Spending your time and energy ferreting out a process based on the fear of what might one day happen will result in a significant amount more time spent doing that then addressing the would-be problem in the first place.
I'm convinced outlook bar none is the worlds worst IMAP Client. (though I'm certain if Novell GroupWise supports IMAP, its somehow worse)
Wow what an absolute nightmare to wrap my head around. Reminds me of J2EE days of abstract patterns everywhere just because we can. Talk about simplicity.

Here is the same app in 130 lines:

https://github.com/techlayer/espresso.js/blob/master/example...
Ask HN: Software Devs – How do you manage your savings?
I've recently graduated out of college and have been working in the industry for a year and half. While I might've spent a portion of my salary earned so far, I'm starting to think about what I should do with the money that's left back. As of now, I haven't given any thought to it and its just sitting there in my Savings account earning a 0.5% interest.

I would like to know how you've invested your savings to do better than 0.5%. Any resources of pointers to learn about investing is also highly appreciated!
I was actually more surprised someone still used POP3 for direct client access - not a bad thing really - I just thought the world had migrated to IMAP.
Well the suburbs were made out of ticky tacky and they all looked just the same. Their adoption was also driven by racism.

As long as people are interested in eating, drinking, partying, culture, socializing and having casual sex - cities as most desirable places to live are inevitable.

The gentrification could be viewed as a very subtle form of segregation - that you could just price out people you don't want to mix with from the places you deem desirable.
I have no experience in developing in ERP systems. I do have experience on being at the end of a very poorly working one.

These systems seem (from my outside view) to have a tendency to become giant monoliths. So when developing you must fight against increasing monolithic complexity. Using something like ActorDB can be somewhat of a beneficial constraint. It forces you to maintain a clean design.

I would force sales, marketing, shipping, product planning (taking from wikipedia here..), to be their own separate actors with their own schemas. Then if possible shard within those types. So if something is customer service, have an actor per customer and have all his data there. If you're developing multiple products, every product has an actor.
Now that you need to bring your own phone to most carriers, there is no reason not to stick with Nexus/pure Android. The updates work there for the most part.
I'm usually a silent reader of HN, but I can't help myself.

I definitely disagree with pretty much everything. The merits of merge commits have already been proven, and using rebases is basically rewriting history. If you want all work done precisely as happened in real life you should always use merge commits. Saved my ass a bunch of times.

Also, when something breaks after a merge, it's super easy to undo and to deal with - "Yo Don, your merge of feature X just broke feature Y. Run some tests".

I just recently moved to a new job where they love the "everything is on master" approach and that is absolutely terrible IMO. Everything is constantly broken, and developers always end up breaking builds and stepping on each others' toes. CI doesn't help in this case either because you always need to wait for some dev to fix the build. Wouldn't it be better to just undo a merge of some feature (i.e. reject the merge) and then let the dev fix that on her own time? Working just on master is just the wrong way of doing anything on a team with more than 2 people.
I think it's a mixed bag, to be truthful, and it's a circumstance that's very well described by "pick your poison."

My primary OS is also Arch Linux, and while it's certainly stable, it's not without its warts. Failure to update regularly on a rolling release distro can have absolutely disastrous consequences (though you only have yourself to blame), and a healthy dose of caution is strongly recommended whenever a major update to important software is in the pipeline (think KDE4 to KDE5 transition). I think this sort of bug (Outlook) illustrates the importance of having an abundance of caution with new software where the failure modes may not be well understood by merit of its relative youth. But with rapid releases, I think the problem is a bit more focused on the end user: Someone who is unable or unwilling to take the risk of updates causing material harm to their workflow or consuming time they can't afford in order to fix potential problems should look for more conservative release cycles. I don't think it's really a matter of "good" versus "bad" tools; that may be part of it, but I can't help myself from thinking it's a matter of misplaced expectations.

That is, it's easy to fall into the mindset of erroneously believing that faster, more rapid updates is always better without fully appreciating their impact. (I've done this more times than I'm willing to admit.)

I do think, and maybe I'm wrong (which I usually am), that those of us who tend toward using rolling release distros have a bit of a bias and a rose tint to our glasses. We almost innately know what the risks are, and I think we take that for granted by assuming most others will freely accept such risks and appreciate the occupational hazards that go hand in hand with change. Not everyone has the same degree of patience, nor the same goals or motives. I think our optimism for and evangelizing of software that pushes rapid releases (like Arch, as an example) can help create an aura that lulls those we influence into expectations that don't mesh well with their use case, their personality, or their constraints. Is that a bad thing? I don't think so (evangelizing is important), because I do agree with you: Updates can be good. I just think we're all too happy to espouse advantages while sometimes glossing over potential drawbacks (guilty again as charged!). :)

Anyway, I should apologize: I didn't mean to wax philosophical. It's late in my timezone, and I saw another Arch user who provoked me into a short essay. I agree with you and username223, but I don't have any real answer. I do think that sometimes we ought to be more cautious with our advice and perhaps weigh context more heavily than our excitement allows. (I made the mistake once of suggesting Arch to someone who really ought to use something with sturdier training wheels. My only saving grace is that he never got around to installing it.)
In contrast to sentiment of many replies here, I have really enjoyed my PhD (admittedly I have not yet submitted - I plan to in the summer). I worked for a year prior to starting, and while that was fun, it felt very limited by comparison. Being around smart people who are interested in a variety of topics, and have the freedom to pursue them, makes for an amazing environment. I've learned a huge amount, and I think the tradeoff of low pay for a few years was easily worth it.
The Continuing Silence of Bourbaki (1997)
Exactly. Server-side rendering is incredibly fast with modern browsers which makes a bunch of SPA sites completely infuriating. There are a few things that make sense like little button actions using AJAX but most of the page should just stay as a normal HTTP HTML request.
You lose a whole lot of development history information. You have no chance of finding out why these five lines of code came to be when all your commits touch hundreds or thousands of lines. Maybe the intent of the code should've been in a comment, but if there are none, it's nice to have commit messages as a backup.

Also, bisecting (and then finding the actual fault in the code) gets harder the larger the commits are.
I find all of these posts on "the right way to use git" pretty tiresome.

At the end of the day it's really not that complicated and you will probably have more luck by keeping it that way. Bringing in a complex workflow that isn't rooted in the flow of work in your organisation makes no sense.

Stick to master being the newest code, fixes done in a branch, review and rebase ontop of master, features the same just hang around in a branch for longer - still rebase ontop of master. Maintain branches for releases and cherry-pick from master onto them.

If your workflow takes a blog post to describe it's just too damn complicated.
What makes some people happy, healthy and successful – and others not?
Also, most games have unbelievable bugs that currently get caught and mitigated by drivers. So whenever a new game is released (or updated) a new driver has to be released.
> there are ways to do research nowadays that don't require the effective vows of poverty and servitude associated with graduate school.

What would be some of these ways in your opinion?
Well people work concurrently, and IMO the repository should show that, too.
The best argument is this: We've done it. We did it on hardware which was cutting-edge in the 1960s. It worked acceptably then.

This stuff is literally a half-century old now. IBM did it with CP/CMS back in the mid-1960s on the original System/360 hardware. Thumbnail sketch: CP (Control Program) is now called VM (Virtual Machine). It is a hypervisor. CMS is the Conversational Monitor System, once the Cambridge Monitor System. It's about as complex as slime mold and/or MS-DOS: Single address space, no hardware protection. CP allowed people to run multiple instances of CP and CMS as guests. CMS provided a command line and an API, CP provided separate address spaces and multiplexed the hardware.

As for "write everything in OCaml", we did that with Lisp and Smalltalk back in the 1970s and 1980s. Hell, we're writing IBM PC emulators in Javascript that run acceptably fast most of the time, and that's heavyweight full hardware emulation, which is a lot more complex than a unikernel would (or should) be.
It could presumably accomplish great tasks more efficiently without the waste of individual human beings skimming kickbacks from the interstellar spaceship budget or arguing about what color the ships should be painted, but building them is still going to require a massive industrial effort that will have a significant effect on ecosystems, no getting around that.
Basically don't have long lived branches.

Everyone should know that by now, doesn't matter what development model or process you are using, if you've gone off on a branch for too long you will have problems.
... also their naming schemes are really annoying. There are almost identical chips sold as a "Pentium", "Celeron", "Xeon", "Core"... with random features turned on (or disabled). Now we get " Atom X".

I can totally understand how it serves Intel to squeeze the most out of corporate buyers, and also it allows one to get a bargain from time to time... But I think in general it's just confusing and annoying.
From my experiences with youth mental hospitals in the Netherlands, they are dominated by the same "just medicate it away" line of reasoning. Therapy exists but is not taken very seriously, and the most important thing of all - listening to somebody's story - is ignored completely.

It's very rare to find anybody in these mental hospitals who isn't on medication, even those who are there through no fault or issue of their own (eg. because of problems with their parents). The only reason I didn't end up taking medication there, was because I categorically refused it.
There is total separation between the myspace list and the rest of the program. The only thing the simulation can do is query hit or miss. Through these hits and misses it figures out what are the words inside the myspace list. The situation is exactly the same when the list is full of md5 hashes, except we hash the candidate password now before we check for a hit or miss.

"what is the input and output of this at a conceptual level?"
Our input is the dataset we want to crack, and our output is the passwords that were successfully cracked.
In a more conventional scenario, we would have a list of hashses that need to be cracked. So the steps are

1. pick parents at random

2. crossover and maybe mutate

3. hash the child

4. see if the hashed child exists as a password in our list of hashses we want to crack

5. if it does, add the child to the end of the container and pop the oldest organism from the front.

6. goto start
Need Help Presenting to the Boss?
Mac Setup Guide for OCD
> Is laughably incorrect

It depends on your workflow. It's correct in context. Don't rebase. You see the commit that caused the breakage if you have a testsuite-on-commit workflow.
> Internet access (and not just HTTP) in Finland (?) is free.

Internet access in Finland is not free. However, everybody in Finland is entitled to Internet service, i.e. each area has a designated universal service provider who is responsible for providing a minimum of 1 Mbps service to everyone in the area.

So, if you want Internet service in Finland, you can always get it. It does not mean it's free, just that it's always available.

Prices for wired service are reasonable, between 30 and 50 euros (average prices for 1M and 100M respectively). Wireless service is cheap and coverage is very good with close to universal coverage. 50M uncapped and unlimited LTE is 15 to 20 euros per month. Prepaid LTE is 20 euros for 10G or 20 euros for unlimited and uncapped service at a low speed for six months.
No Risk No Reward
Having a feature implementation splitted in a sequence of commits helps a lot the review process.

This often involves the use of interactive rebase to cleanup the history before presenting the branch for the review.
I think it depends on how you define 'consistent'. A schedule where I go to sleep at the same time every day doesn't work for me and never has - it's precisely that which turns me into a walking zombie, as I've been for most of my time in high school.

Instead, I generally just go to sleep when I'm tired and wake up naturally when I'm done sleeping. This automatically falls into a pattern where my bedtime shifts forward by 1-2 hours a day, in a cycle. Whenever I can follow that pattern, I sleep and perform extremely well.

Different people still do appear to have different optimal sleeping patterns.
The work of several people who are active at the same time cannot be linear by definition.
> git bisect pointing to the merge commit as culprit is exactly what should happen

in theory, maybe. in practice, this simply does not help if you are looking at massive merge commits. sometimes, the merge goes wrong even with no conflicts, and then you can debug that massive merge with little clue where to start.

compare that to rebasing, where you have a hopefully small commit that breaks. you indeed loose the information whether the rebase broke it or the initial version was broken as well, but I don't see the practical difference, it needs to be fixed either way.
It has nothing to do with the free market. The reason people don't trust utopians is they tend to leave big piles of bodies in their wake.
Scientists Studied How Our Brains Would React to Teleportation
Make is actually really simple the problem is people approach it like an imperative programming language.
But you will have to either merge or rebase if someone else pushed into master while you were working. The difference is, rebase keeps the history honest about the fact that you were working concurrently, while rebase tries to construct an alternate, false version of these events.
I now realise my words are ambiguous.

I don't fear being robbed in Denmark, whether carrying cash or not. After all, I carry a €500 smartphone everywhere.

The smartphone apps are protected by a PIN, and contactless cards are limited to low values which the bank will refund.
Google Docs Now Lets You Type with Your Voice
Because the notion that commit broke that code is false, and out of that false information you will be able to get a lot of other false ideas about how the code was developed, which will lead to your fix not being entirely correct.
I was using OCZ Vertex 2 SSD in the past, when (possibly due to a firmware bug) it just wouldn't appear on the SATA bus anymore and had an error LED lit up.
I RMA-d the drive, and they said they have to reflash the firmware, but doing so would also loose all data because it would erase the AES key. (I never configured any encryption on the drive, but apparently it does use it by default).

Needless to say I didn't buy OCZ again, but I'm not sure if this is a general problem with SSDs or just Sandforce controllers.
Sony and Virtual Reality Steal the Show at MWC
My immediate reaction as a Scot was "What are brochs doing in Oman?"

https://en.wikipedia.org/wiki/Broch

NB Brochs aren't as old and are a lot bigger. However, the visual similarities are quite striking.

Edit: Obviously this similarity is coincidental - there aren't that many different ways of building a simple tower out of stone.
Very interesting analysis. It would be pretty fun to play (or create) a game that does have more realistic urban planning aspects to it. Perhaps if a really fun, successful game were created in that way, a lot more people would realize how destructive zoning laws have been.
This "Something more simple/Cactus Model" is exactly what we're doing very successfully since years with SVN. We're focusing on release branches. Very rarely doing feature branches, because branch merging with SVN is PITA and something you want to avoid.
once more, gitlab does it right and offers a "rebase" button on merge requests along with a "fast-forward merges only" option for repositories.

See http://doc.gitlab.com/ee/workflow/rebase_before_merge.html
The point is to train you to be a scholar, someone who can do original research in the field, as is expected of university professors. To that end, a PhD program includes coursework advanced enough to bring you up to the current state of the research in the subject, and a period of research apprenticeship with your advisor, where you begin to contribute to the field yourself. That's valuable enough to devote four years to if scholar is the job you want. I wouldn't recommend it for any other purpose. Way too much pain.
Give your audience SPACE
Serious question: have you considered publishing it anonymously?

If you've run into issues with that idea (like being concerned about unintentionally revealing hints about your identity, or how/where to publish it, etc.), I'd happily try and help out - my e-mail is admin@cryto.net.
Gitflow is exactly this, only they add an extra branch which tracks all of the releases. And, for some weird reason, call it 'master'.
Indeed, from my observations people using rebase are usually working solo or in very small teams, or just like spending insane amounts of time fixing their broken code.
> don't mean to be on the offensive

You might want to try a bit harder.

Mental illness is not the result of dabbling in tarot or crystals. The causalilty probably runs the other way. There's not much correlation between tarot and mental illness.
Why would there be a factory for 7Hz tones?
> I think it is quite telling that the Linux kernel developers themselves prefer a simple, linear history in the end

What do you mean? This is what the current git history of the linux kernel looks like:

* 12b9fa6 Merge branch 'for-linus' of git://git.kernel.org/pu
|\
| * 5129fa4 do_last(): ELOOP failure exit should be done after
| * a7f7754 should_follow_link(): validate ->d_seq after having
| * d456564 namei: ->d_inode of a pinned dentry is stable only
| * c80567c do_last(): don't let a bogus return value from ->op
| * 0fcbf99 fs: return -EOPNOTSUPP if clone is not supported
| * b6853f7 hpfs: don't truncate the file when delete fails
* | 340b3a5 Merge tag 'armsoc-fixes' of git://git.kernel.org/
|\ \
| * \ d877a21 Merge tag 'renesas-soc-fixes-for-v4.5' of git:/
| |\ \
| | * | 901c5ff ARM: shmobile: Remove shmobile_boot_arg
| | * | 4e960f5 ARM: shmobile: Move shmobile_smp_{mpidr, fn, ar
| | * | b1568d8 ARM: shmobile: r8a7779: Remove remainings of re
| | * | d2613f5 ARM: shmobile: Move shmobile_scu_base from .tex
| * | | 7931845 MAINTAINERS: Extend info, add wiki and ml for m
| * | | 9fa6c2b Merge tag 'omap-for-v4.5/fixes-rc5' of git://
| |\ \ \
| | * | | 3f315c5 ARM: OMAP2+: Fix onenand initialization to av
| | * | | e327b3f Revert "regulator: tps65217: remove tps65217.
| * | | | a9e5547 MAINTAINERS: alpine: add a new maintainer and
| * | | | 5e45a25 ARM: at91/dt: fix typo in sama5d2 pinmux desc
| * | | | b223c9f Merge tag 'imx-fixes-4.5' of git://git.kern
| |\ \ \ \
| | * | | | f5d0ca2 ARM: dts: imx6: remove bogus interrupt-pare
| | | |/ /
| | |/| |
| * | | | e3acd74 Merge tag 'omap-for-v4.5/fixes-rc3-v2' of g
| |\ \ \ \
| | | |/ /
| | |/| |
| | * | | cf26f11 ARM: OMAP2+: Fix omap_device for module reloa
| | * | | 08c78e9 ARM: OMAP2+: Improve omap_device error for dr
| | * | | bf26927 ARM: DTS: am57xx-beagle-x15: Select SYS_CLK2
| | * | | a5b8751 ARM: dts: am335x/am57xx: replace gpio-key,wak
| | * | | 5f35dc4 ARM: OMAP2+: Set system_rev from ATAGS for n9
| * | | | 74a46ec Merge tag 'mvebu-fixes-4.5-2' of git://git.
| |\ \ \ \
| | * | | | 44361a2 ARM: dts: orion5x: fix the missing mtd flas
| | * | | | 9d021c9 ARM: dts: kirkwood: use unique machine name
* | | | | | 691429e Merge branch 'akpm' (patches from Andrew)
|\ \ \ \ \ \
| * | | | | | 7f6d5b5 dax: move writeback calls into the filesy

Merge commits galore.