Languages for online betting: an investigation of Go, Erlang, and Elixir - <AUTHOR> https://www.erlang-solutions.com/blog/programming-languages-for-online-betting-an-investigation-of-go-erlang-and-elixir.html <comment><USER2> "Erlang Solutions" says Erlang is the bee's knees...

I really like when someone that doesn't have a horse in the race reviews some language (better if it has been used in anger). You gotta value the perspective of a pragmatic engineer that has misapplied a tool.

There's a lot to learn about where a language is best used, but when someone pay is somewhat tied to a language I don't trust the analysis as much.

<comment><USER3> The 1st thing I thought when I so the article. A "Solutions" company advertising their product?

Use the tools that get your job done and stop bragging about it.

</comment></comment><comment><USER4> I'm currently writing a GUI for industrial automation, where we have to talk to a number of machine control threads and image processing threads (all through a procedural interface that connects to other processes).

I'm writing in C and decided to stay in a single OS thread and to instead write my own simplistic user thread scheduler. User thread ("green threads") work by simply switching call stacks and saving registers. In my case this is as simple as making a few Windows API calls like CreateFiber() or SwitchToFiber().

It's one of the best things I've ever done. Maybe 1 day of work to get the threads rolling, no bugs, and still in a familiar C environment. No bindings required to interface with the libraries that I _need_ to interface with (like Qt) and perfect deterministic control over what happens (just not the other processes of course).

I think I can understand people are not using C doing web stuff (lots of strings) but for what I do I'm convinced it's the easiest, fastest to develop, most performant, most robust thing you can do.

<comment><USER5> How can you be convinced if you're only running the control in an experiment?

<comment><USER4> It's not an experiment.

<comment><USER6> I don't believe that lucidguppy was saying that your system was an experiment. Instead, it would be interesting to try implementing your system in a second language so you could compare and contrast the differences. (Of course, in the real-world one often doesn't have the luxury of doing this.)

<comment><USER4> Ok, so my conviction comes from the fact that the code is super straight- forward and I don't have to deal with the complexities of a managed language's run-time system (like tuning the garbage collector or scheduler, using synchronisation primitives, depending on the ecosystem/using terrible bindings, etc).

All investment is just a page of code using the Windows Fiber API, and the scheduler ist just 10 lines of code doing round-robin scheduling. Which is totally fine right now, and there's the added benefit of being in total control and being able to make adjustments if they are needed in the future.

Since the scheduling is non-preemptive, threads are not allowed to block. But only a synchronous, blocking coding style is maintainable, so threads use wrapper functions to execute slow operations. The wrapper functions have a synchronous interface, but internally they call asynchronous functions, and unless the request can be served immediately, they call the scheduler. The wrapper functions make another 50 lines (so far) of really simple bullet-proof maintainable code.

It's really like Javascript technically (non-preemptive scheduling), but you don't have to do callback chaining. You just write your code in an ordinary synchronous blocking style. Think about that. You write thread-heavy interactive C code that is much more maintainable than Javascript code. And of course, much more maintainable than clumsy OS threads - no management, no synchronisation primitives and no excessive copying between threads. On top of that, the scheduling is deterministic. All with 100 lines of straightforward infrastructure code.

The only boilerplate in the project comes from using Qt/Qml.

(If you're on POSIX and can't use the Windows Fiber API, you can depend on the deprecated makecontext/getcontext/setcontext API, or write a little inline assembly. It's not a big deal either way, since it's really just a few lines of code that are neatly separated from the rest of the system).

<comment><USER7> Would be nice to see a blog post expanding on this a little more with more examples and some basic diagrams.

</comment></comment></comment></comment></comment></comment><comment><USER8> The article briefly mentions the similarity of online betting to stock markets, when it is about the requirements for stability and real time processing without long GC delays.

This makes me wonder why Erlang/ Elixir are used so little in the financial industry? I have been working for a couple of financial firms and even a HFT company but I have never seen Erlang being used, despite its apparent advantages.

Does anybody know why this is? Or is Erlang actually being used a lot in finance and have I just been working in the wrong places?

<comment><USER9> A betting exchange is a stock exchange. Same thing.

Let's say that there is a football game Liverpool vs Manchester.

One client puts £5 that liverpool will win. The exchange takes the money and adds it to the order book.

Another client puts £5 that manchester will win. The exchange takes the money. It's matched with the opposite order and frozen. The money will be redistributed to the winner at the end of the game, minus a fee.

It's exactly like buying and selling in a normal exchange. You can do real time trading during the game and arbitrage between exchanges.

Disclaimer: I worked in betting before I moved to finance.

Erlang is super weird and hard to recruit for. When used right, it's not faster or more productive than C++ or Java. I wouldn't advise anyone to use Erlang for anything.

<comment><USER10> _> I wouldn't advise anyone to use Erlang for anything._

Try concurrency on multiple cores in C++ or Java, and let us know how you get on.

I'm quite happy and doing well with my 'super weird' secret weapons, thank you!

<comment><USER11> By making use of tasking libraries that took ideas from Erlang, and async/await patterns

</comment></comment></comment></comment><comment><USER12> That was poorly written. And amazingly, the author neglected to shed light as to why Erlang has a more a 'complete' story in regards to distributed f/t systems ("reliability", "concurrency").

Erlang has OTP, Go does not. Erlang is FP, Go is not. These are the critical differences.

Silver lining (in context of OTP) for Go is that the du jour 'cloud' based architectures will provide the OTP like capabilities ("elastic", "fail-over", etc.) for deployed (micro-)services. It seems that in the (future) long-term, Go is better positioned than Erlang for cloud based systems.

</comment><comment><USER13> Would be curious to see Pony added to the mix. It has the best of both worlds for my tastes, from Go: statically typed and native code, and Erlang: actor model, GCd at the actor level. Plus more features that neither has like capabilities.

<comment><USER14> Pony isn't even version 1 yet iirc and instable API.

I mean would you like to bet on that stack on top of your betting platform? >___>

Pony promise great things and the language have a proof and all that but it still needs to be battle tested and get to some sort of stability.

[https://www.ponylang.org/discover/#what-is- pony](https://www.ponylang.org/discover/#what-is-pony) (under why not pony section, API unstable)

The degree of tech hype and adoption of bleeding edge is crazy. The thought of programmers just betting on these thing without thoughts on the schmuck who would inherit these technical debt still boggle my mind.

<comment><USER15> That just means most of the software is not that critical or people are more careless i do not know.

</comment></comment></comment><comment><USER16> As someone who works in this industry, the biggest issues are (besides like stuff like match-fixing and illegal internal trading/leaks):

1\. Highly domain-specific legacy pricing model running on... Excel spreadsheets. These present huge performance bottle-necks and aren't easy to migrate.

2\. Reliance on 3rd Party data. Did a scout just send incorrect data? Did their device disconnect? Did they rollback the wrong information? Is the source lagging behind the TV/online feed? GGs. Suspend the game and refund bets.

The tooling really isn't that important. Scalable software can be written in any software, and while some languages do make things simpler, often you can just also find a suitable paradigm (or middleware) that can provide similar advantages. Having said that, we do make extensive use of RabbitMQ (which is written in Erlang) in our environment. I suppose this is also just an example of my previous point though...

<comment><USER9> 1\. I don't know what you are talking about. The major betting exchanges all support real time trading, they have market makers and are arbitraged against one another.

The only issue is with low popularity events. Noone cares about them, there is low liquidity and volume, it's hard to price them.

<comment><USER17> I think ilitirit is talking about bookmakers, not exchanges.

<comment><USER16> There are companies that do a combination of things: Real-time trading (manual, semi, auto), pricing (model-driven, or sourced), risk-management, etc. They can either provide their own prices using models, or apply prices from partners. The business is usually separated into discrete units which feed into each other, and outward to partners/customers.

Yes, exchanges support real-time trading, but not every company has _all_ their models running in modern paradigms. It's not uncommon to find companies that run multiple VMs for the sole purpose of... running Excel calculations. Yes, this is exactly what it sounds like. A server that has a several, multi- meg Excel files in memory with external APIs that plug values into cells and read outputs. As I said, within the grand scheme of things, for sports who still run on legacy models, this is a major bottleneck. Remember, many of these companies were started in the 90s, and that's when these models were created. The people who created them are usually swallowed up by the financial industry and now come with a hefty price tag. So the question for the business is "Do we spend millions recreating these proven models and run the risk of them failing? Or do we simply just add another VM?"

At my company things have slowly started changing, but the new models (written in F#) still need a lot of work.

<comment><USER9> The bookmakers are far behind in technology but it's not critical to their business. They only price once a day and have large spread (fat margins).

I agree that the finance industry is competing for talents of quants and developers. Anyone who works in betting will find out that finance has better work conditions and better pays.

</comment></comment></comment></comment></comment><comment><USER18> I spent a few years working at the UK's largest betting exchange, I could tell you what language we used for bet matching and so on but you wouldn't believe me...

<comment><USER19> I remember when Betfair seemed to be a bunch of shonky crap stitched together. I can easily imagine a load of Perl scripts before they invested in Oracle in a big way.

<comment><USER18> _before they invested in Oracle in a big way_

Yep, got it: it was all done in PL/SQL. Clicks on the website went through a simple Java layer and called stored procs. At the time we were doing more transactions/sec than all the European stock exchanges combined, and often the Japanese too. It makes me chuckle when people say to me now "but SQL databases don't scale" when they are running 1/10th of the workload we were running 10 yeara ago...

No idea what they're using now, mind, I left after the IPO but before the merger.

</comment></comment></comment><comment><USER20> I am really interested in some numbers to show how much the Go's GC harms program performance. I wonder if this is really an issue for an online service, given the stop-the-world phases are usually <1ms. Does anyone have some material on that?

<comment><USER21> Sasa Juric, and the folks at pusher wrote a couple of blog posts on this: [http://theerlangelist.com/article/reducing_maximum_latency](http://theerlangelist.com/article/reducing_maximum_latency)

</comment></comment><comment><USER19> What a terrible article. It's spam designed to get hits for bookmaker CTOs scouting around.

No benchmarks, no numbers, no real detail, just empty praise for Erlang from a company called "Erlang Solutions".

</comment><comment><USER22> What a garbage article, Go is faster that Erlang and not by a small margin, same for the GC. Erlang has definitely its place in some scenarios but the article reflects it poorly by trying too hard to dismiss Go.

<comment><AUTHOR> Go maybe faster than Erlang in raw throughput but Erlang can compete with Go in Latency (mainly predictable latency). As you said it all depends on the scenario. The article is mainly in the scenario of betting infrastructure where I think erlang is better due to OTP (saying this as a person who works on building trading systems and daily user of both).

<comment><USER22> One example:

"When you pit Go's requests per seconds against the likes of Ruby on Rails or Django, Go returns some impressive benchmarks performing 3x better. Go can scale to hundreds of thousands with relative ease, in much the same way that Erlang and Elixir scale to millions."

He's talking about raw performance where Go is much faster than Erlang and still talking about different order of magnitude to diminish Go.</comment></comment></comment>


Learning Vim in 2014 - <AUTHOR> http://benmccormick.org/learning-vim-in-2014/ <comment><USER2> I actually went from vim to spacemacs recently, and found it rather nice. I am one of those people who learned to edit with vim, but never like actually making vim my own. No extra stuff, just simple editing.

Then I tried spacemacs, and was sold immediately. I got all of the good things I never took the time to configure in vim for free (or at least at the cost of 600ms longe startup time). I have gone from an IDE lover, to a loon living in spacemacs. As their tagline says: "The best editor is neither Emacs nor Vim, it's Emacs and Vim!"

<comment><USER3> For me it was the opposite. I went from spacemacs to neovim and used the experience with layers and well structured config to make my neovim experience superb.

The only time I still use spacemacs if I "feel like it" or need one of the exclusive plugins like a good clojure repl. But compared to vim, I found spacemacs rather heavy. Like IntelliJ vs Sublime.</comment></comment>


Show HN: Complete Educational Background for 116th United States Congress - <AUTHOR> https://www.kaggle.com/philmohun/complete-education-details-116th-us-congress <comment><AUTHOR> I recently heard the phrase "America is run by lawyers, China is ruled by computer scientists."

I was curious about this, so I made a dataset to understand U.S. Legislative Education. This dataset contains complete education details for members of the 116th United States Congress, including universities, degrees, and political affiliations. I hope that this dataset is helpful for anyone who may wish to further investigate the correlation of education and academic credentials with policy decisions made by members of our government.

This dataset can be used to answer questions like:

\- Is political affiliation correlated with education?

\- What is the most common degree type for U.S. Senators?

\- What percentage of U.S. Congressmen dropped out of college?

\- Which college has the most representation in the House of Representatives?

\- What percentage of Congressmen are scientists?

With some creative co-mingling, this dataset can be used to supplement research questions like:

\- Are policy decisions correlated with education?

\- Are there relationships associated with college affiliations and voting in Congress?

\- Can we find a relationship between hot button topics and education?

\- How is public sentiment influenced by education level?</comment>


Senators pledge to defeat Silicon Valley on sex-trafficking bill - <AUTHOR> http://www.politico.com/story/2017/09/19/sex-trafficking-bill-senate-242887 <comment><USER2> There is an interesting documentary on Netflix about this legal fight with Backpage, "I Am Jane Doe"

It's incredibly misleading (as tends to be the case with proposed bills) to market the bill as a "sex-trafficking bill," since it's aiming to make websites responsible for the content that's posted by users.

It would literally destroy the internet as we know it. Imagine the liability on websites like Reddit and even HN which rely purely on user-posted content.

</comment><comment><USER3> Ahh, so this is how democracy dies, then.

Vibrant and bright individuals create platforms that millions of other brilliant individuals use.

An extremely small percentage of other individuals use these platforms to facilitate terrible crimes.

Politicians and their supporters decide to penalize everyone by censoring the platforms.

Thus, the normal users suffer, and the criminals switch to another platform.</comment>


Scientists extract images directly from brain - <AUTHOR> http://www.pinktentacle.com/2008/12/scientists-extract-images-directly-from-brain/ <comment><USER2> They took the images from the brain, but they might not have gotten it from the mind - it may have come for circuitry associated with the eyes, rather that the circuity associated with thinking.

I would like to see if they could read images if a person just thought about them, rather than actually saw them.

<comment><USER3> Exactly. The visual system produces a very stable activation pattern, relative to other senses and multidimensional objects. The noise inherent in those other systems is probably the best protection of our inner privacy. There simply isn't a code to be read because there's little systematicity from one moment, or person, to the next. The visual system is as good as it gets and even then only when you're looking at a prescribed object.

In other words, ignore the PR about downloading thoughts and dreams. We can decode some stuff from fMRI activity patterns but we're soon swamped by noise, even when using machine learning techniques. The data just isn't there. It's like trying to predict the weather two weeks from now. The system is inherently noisy.

<comment><USER3> For instance, here's a seminal paper predicting which category (faces, place, object) was going to be recalled from studied pictures and a second or two before it was actually recalled:

[http://www.sciencemag.org/cgi/reprint/310/5756/1963.pdf?maxt...](http://www.sciencemag.org/cgi/reprint/310/5756/1963.pdf?maxtoshow=&HITS=10&hits=10&RESULTFORMAT=&fulltext=Polyn&searchid=1&FIRSTINDEX=0&resourcetype=HWCIT)

Still, that's a big difference from predicting (or mindreading) the particular item.

And here's a good review of that and similar work:

<http://polyn.com/struct/NormEtal06_TICS.pdf>

<comment><USER4> Do you have any publications of your research online?

<comment><USER3> Been meaning to put a home page together.

Here are two empirical reports: <http://www.jneurosci.org/cgi/content/full/26/18/4917> <http://www.jneurosci.org/cgi/content/full/27/14/3790>

And here's a review: <http://www.psych.upenn.edu/stslab/assets/pdf/TS_CONB05.pdf>

Happy to answer questions at grob AT mass inst tech

</comment></comment></comment></comment></comment><comment><USER5> To get past the creepiness aspect, let's say that you can only view what someone else is seeing. That's still pretty useful.

Imagine that you make this high enough resolution that it's like watching TV, and then small enough that it'll fit in a helmet.

Then, you could record what someone is seeing and hearing, without having a cameraman around. It would be a cool way to, for example, watch a football play from the eyes of the quarterback. It might be a very interesting way to make movies.

<comment><USER6> If you're using a helmet, might as well use a camera instead...

Would be far cheaper, and could always use eye-tracking to move the camera (or even just zoom and pan to give the effect of looking)

<comment><USER7> You wouldn't get any of the effects of blurred vision, crossed eyes, or some such. Also, eyes are far better cameras than anything you'd fit on a helmet.

<comment><USER8> In some ways. If you recorded just what the rods and cones detected, you'd actually get a really small, really high-resolution area in the center (the fovea) with the rest at extremely much lower resolution. So if you recorded what the quarterback saw, but without the post-processing done by the brain to cache some of the things recently glanced at, it might be pretty hard to watch.

</comment></comment></comment></comment><comment><USER9> Alas the account is suspended.

Basically, they had this experiment where they showed the subjects 400 12x12 (I think) pixel images of letters and measured various things in their brain.

They used (most likely) neural nets and machine learning to draw conclusions about what was going on, and then they showed the subjects a series of NEW images that were not in the training set, measured the brain activity, and they were able to display a graphic that had white, grey and black pixels that closely resembled the white on black lettering that they had trained it on.

They were _not_ exact pictures, but kind of like fuzzy images that you could see the whiter areas were were the letters were, and the darker areas in the images were aslo where the background was.

Interesting stuff, but I think a far cry from the reading people's dreams they believe is possible in the future.

<comment><USER10> _Interesting stuff, but I think a far cry from the reading people's dreams they believe is possible in the future._

Why? They've established the basic principle. All it needs now is refinement. Have you ever seen a picture of the first transistor?

<comment><USER11> _They've established the basic principle. All it needs now is refinement._

This "basic principle" is no different when they do other MRIs that can detect patterns in brain activity (specific to one individual). The computers aren't doing any interpretation of brain activity here, just recognizing what it has been preprogrammed to to recognize.

What you're proposing is that we build a recognition database of every single brain pattern and its correlating image. Damn, what kind of computer does that remind you of? Oh yea - the human brain!

Not only that, but each individual has unique brain patterns, so this "computer" would have to be able to interpret a wide variety of signals. We're so far off from understanding the brain that this isn't happening, ever.

<comment><USER12> You lead the topic to a very big question. If you think here computer is not doing any interpretation, what you actually say is computer learning methods don't mean computer can think. In this article, scientists do make computer do some "interpretation" because the training data and test data are different. (NEW images and reconstruct).

People here have much more to do to fulfill the goal of "reconstructing high resolution, color image", but the problem is not computers do think or not.

</comment></comment></comment></comment><comment><USER13> In the long term, this has great potential for improving communication - imagine being able to visualize something and show it to other people instantly, rather than having to try to draw it or put it into words.

For example, it could greatly speed up teaching if both the student and teacher were equipped with an advanced version of this device, since the teacher could immediately see and easily correct any mistaken visualizations the student had.

It could be the human-to-human equivalent of going from 56k to broadband.

</comment><comment><AUTHOR> [http://www.cell.com/neuron/abstract/S0896-6273%2808%2900958-...](http://www.cell.com/neuron/abstract/S0896-6273%2808%2900958-6) is the abstract. Some anonymous soul will probably Scribd the paper at some point in the future also.

<comment><USER14> Its on Scribd

[http://www.scribd.com/doc/8857889/Visual-Image- Reconstructio...](http://www.scribd.com/doc/8857889/Visual-Image- Reconstruction-from-Human-Brain-Activity-using-a-Combination-of-Multiscale- Local-Image-Decoders)

</comment></comment><comment><USER10> This might be the most exciting science news I've ever read. The implications are breathtaking.

<comment><USER15> I can think of a lot of negative implications if this technology progresses the way they think it will. Can you imagine how excited governments will be about being able to "read the terrorists' minds" with this new toy?

Are there any good implications? The "get images directly from the artists brain" doesn't sound too exciting to me, compared to the potential for 1984 style chicanery.

</comment></comment><comment><USER16> I don't think it is reading pictures from the brain at all. The way I understand it, it can only recognised pictures the computer has learned before.

As an analogy, imagine your eye lid twitches every time somebody mentions George Bush. The computer would then learn that when your eye lid twitches, you are thinking about George Bush. Not very exciting imo.

I think there was an experiment with a cat where they actually generated an image from what fell on the cat's retina. THAT was scary to me.

<comment><USER11> _I think there was an experiment with a cat where they actually generated an image from what fell on the cat's retina._

The only study I've ever seen on this has been based on simply grabbing the image off the reflection of the eye. I can't imagine this actually involved hooking up a cat's visual cortex to some sort of interface, the sheer processing power required for that sort of visual information processing is unfathomable.

If not, link me!

<comment><USER2> They did do that, it was in Scientific American in an article about the eyes. They they did not take it from the visual cortex though, but rather from neurons coming from the retina.

The retina has various layers and they took a look at what each layer does.

<comment><USER17> They put smashed bananas into the cats' brains to record the signals.

(It's less ridiculous than it sounds: Bananas contain a certain enzyme that helps to capture the neurons signals. The porridge they put around the sensors in the cats' brains contained many more things besides the bananas. My fiancee was studying that stuff in university.)

</comment></comment></comment></comment><comment><USER18> Supposedly you can hear what people are thinking by sampling the nervous signals sent to the larynx.

[http://www.thinkartificial.org/machine-interfaces/audeo- neck...](http://www.thinkartificial.org/machine-interfaces/audeo-neckband- neural-interface/)

<comment><USER19> This is quite different than the OP's image reconstruction, and it isn't really what one is thinking (i.e. in your head). You need to consciously send motor commands to your vocal chord for the system to pick up your "thoughts." Essentially, you complete the entire speech process (from thoughts to motor signals), but the device completes the final step, rather than your vocal box.

</comment></comment><comment><USER20> _"This technology can also be applied to senses other than vision..."_

Sweet, it could be used to make music without having to learn an instrument.

</comment><comment><USER21> I wish I lived a couple thousand years from now.

I think mankind is really going to be able to do some great things once we understand the brain fully.

</comment><comment><USER22> Damn - This Account Has Exceeded Its CPU Quota

Can anyone summarize or is it basically what it sounds like? How accurate is it?

<comment><USER10> Here's the article:

Scientists extract images directly from brain

<image> "Researchers from Japan's ATR Computational Neuroscience Laboratories have developed new brain analysis technology that can reconstruct the images inside a person's mind and display them on a computer monitor, it was announced on December 11. According to the researchers, further development of the technology may soon make it possible to view other people's dreams while they sleep.

The scientists were able to reconstruct various images viewed by a person by analyzing changes in their cerebral blood flow. Using a functional magnetic resonance imaging (fMRI) machine, the researchers first mapped the blood flow changes that occurred in the cerebral visual cortex as subjects viewed various images held in front of their eyes. Subjects were shown 400 random 10 x 10 pixel black-and-white images for a period of 12 seconds each. While the fMRI machine monitored the changes in brain activity, a computer crunched the data and learned to associate the various changes in brain activity with the different image designs.

Then, when the test subjects were shown a completely new set of images, such as the letters N-E-U-R-O-N, the system was able to reconstruct and display what the test subjects were viewing based solely on their brain activity.

For now, the system is only able to reproduce simple black-and-white images. But Dr. Kang Cheng, a researcher from the RIKEN Brain Science Institute, suggests that improving the measurement accuracy will make it possible to reproduce images in color.

"These results are a breakthrough in terms of understanding brain activity," says Dr. Cheng. "In as little as 10 years, advances in this field of research may make it possible to read a person's thoughts with some degree of accuracy."

The researchers suggest a future version of this technology could be applied in the fields of art and design — particularly if it becomes possible to quickly and accurately access images existing inside an artist's head. The technology might also lead to new treatments for conditions such as psychiatric disorders involving hallucinations, by providing doctors a direct window into the mind of the patient.

ATR chief researcher Yukiyasu Kamitani says, "This technology can also be applied to senses other than vision. In the future, it may also become possible to read feelings and complicated emotional states."

The research results appear in the December 11 issue of US science journal Neuron."

</comment></comment><comment><USER23> Protoss voice:

"psi limit exceeded, require more cpu quota"

<comment><USER24> Or a summery of your life from your eyes,leaving out the bad parts of course - <http://www.imdb.com/title/tt0364343/plotsummary>

</comment></comment><comment><USER25> If my wife ever acquires this technology I am screwed.

</comment><comment><USER26> brilliant and they used a very old mac for it!

</comment><comment><USER27> a-ha discovered this technology years ago to make their video "take on me"

</comment><comment><USER28> shouldn't be long now until we can put imagery directly into the brain

</comment><comment><USER29> has to be the scariest thing i've read all year

<comment><USER30> When this kind of technology replaces keyboards, mice, and touch screens, do you think that mainstream audiences might begin to appreciate the value in knowing exactly what the software on your personal devices does, and which master that software serves?

I would never put so much as my private SSH keys on a closed source machine that pulls updates in the background or a device on which a third party is root (iPhone, G1). I certainly can't imagine plugging my brain into any such creature.

<comment><USER31> Ever since I read the story of writing a backdoor in the unix login prompt, then writing that change into the compiler so the login prompt code looks clean, then writing that change into the running compiler, so the compiler code looks clean, but the running compiler will backdoor itself or the login prompt, I've had the feeling that the best bet is not to trust as far as possible and not to worry as far as possible.

Smart people will always be able to outsmart me, stupid people with power or desirables will always be able to coerce me into lowering my standards.

<comment><USER32> The story you're referring to is Ken Thompson's _Reflections on Trusting Trust_ :

<http://cm.bell-labs.com/who/ken/trust.html>

</comment></comment></comment></comment><comment><USER33> This is both awesome and creepy. That makes it aweseepy or creepsome.</comment>


Ask HN: Is there any reason I'm unable to submit stories? - <AUTHOR>

When I tried to make a link submission (first in 21 days), I received the following message:

    Stop spamming us. You're wasting your time.
 Any ideas? <comment><USER2> You're probably trying to submit a url from a banned domain.

<comment><AUTHOR> I think this makes sense, since I was able to submit something else a second ago. We'll see if it persists, I suppose.

Thanks.

</comment></comment><comment><USER3> Same here, however, I can post comments but not stories. Not sure if they flagged us as spammer.</comment>


Sergey Brin's Younger Brother Co-Founds A Startup Of His Own - <AUTHOR> http://techcrunch.com/2013/07/30/sergey-brins-younger-brother-co-founds-a-startup-of-his-own/

<comment><USER2> Way to go brother! Keep up the great work. ~S

</comment><comment><USER3> Congrats Sam :)</comment>


Etsy CEO steps down, 8% of workforce to be cut - <AUTHOR> http://www.businessinsider.com/etsy-ceo-stepping-down-earnings-layoffs-2017-5 <comment><USER2> I've tried searching on Etsy for specific handmade items that is well known to be sold on etsy, but trying to search for anything on the site is ridiculous. Most of the reason for this, I'm guessing, has to do with Etsy sellers not using the right keywords or tags. IDK, but it needs to be fixed. I think they should try a Model like Not on the High Street where there are standards, guidelines and assistance.

Also, it is clear that a lot of the listings on Etsy are cheap factory products from Asia rather than handmade. People purchase cheap goods on Alibaba and Ali Express to sell as handmade.Why pay a premium for cheap factory goods when the same items can be bought way cheaper at the nearest WalMart? They need to get it together.</comment>


Apple's content blocking is chemo for the cancer of adtech - <AUTHOR> https://blogs.law.harvard.edu/doc/2015/08/26/apples-content-blocking-is-chemo-for-the-cancer-of-adtech/ <comment><USER2> My theory is this is Apple's attempt to push people working in adtech towards Apple's Google-Analytics analogues.

It is getting a bit ridiculous how bluntly Google (the incumbent), Apple (whoa we track mobiles really well) and Facebook (wahey, we track _real_ people, come over here) are all trying to push adtech people onto their platforms. They are now truly going for the Enterprise market, and are looking to lock them in.

<comment><USER3> Do Facebook and Apple really have an analytics platform anywhere as good as Google analytics? If one of them acquires kissmetrics or mixpanel of something I'd believe you but having used facebook's business interface first hand it's only good at analytics "on facebook" it tells you very little about your actual site even if you have their pixels on every page. With Google I can see my marketing funnel from on every platform.

<comment><USER2> I totally agree, but having a bad platform hasn't stopped people trying to sell theirs to enterprise, afaik.

</comment></comment></comment><comment><USER4> Can you block Apples iAd, too?

This looks like what Apple did with payments on IOS - only Apple's payment system is allowed, and Apple takes a 30% cut.

<comment><USER5> We are talking here about Safari content blocking. iAd ads are not displayed in Safari, they are for native applications and you can display ads from whatever publisher you want in your native app.

</comment></comment><comment><USER6> Is this really the right reference to go for? Chemo is universally hated, makes you look like not yourself, makes you throw up and feel sick all the time, steals all your energy, and, importantly, often does not work.

<comment><USER7> While I agree with you, chemotherapy is the layperson's only term for most cancer treatment. And make no mistake, advertising _is_ a cancer that needs to be judiciously dealt with.

But this particular meme is derived from the bad old days of /b/ when most threads were spammed with stuff like

>XYZ IS THE CANCER KILLING /b/

>XYZ IS THE CANCER KILLING /b/

>XYZ IS THE CANCER KILLING /b/

>XYZ IS THE CANCER KILLING /b/

>XYZ IS THE CANCER KILLING /b/

>XYZ IS THE CANCER KILLING /b/

>XYZ IS THE CANCER KILLING /b/

</comment></comment><comment><USER8> I'm happy with advertising. It pays for all the free stuff. Apple wants to kill all the free content so you only have the choice of paying Apple to do anything.

Companies built around an advertising model should detect and reject Apple browsers.

Individuals who value getting free stuff on the web should switch to non Apple browsers to show support for advertising.

<comment><USER9> _I 'm happy with advertising. It pays for all the free stuff._

But not magically with free money that just appears when a company decides to buy an advert. Adverts are paid for by businesses that consequently charge a little more for their goods and services, a cost passed directly to you and me. We don't get free services, we get services that we pay for indirectly through other things. Free is a myth.

<comment><USER8> Yes it's an ecosystem I want to be healthy.

Many, many software engineers have jobs and many startups exist because there is an advertising ecosystem.

The advertising ecosystem is an inherent part of the capitalist economy. In whose interest is it to kill that?

Apple should stop advertising if it hates advertising so much.

<comment><USER10> > _The advertising ecosystem is an inherent part of the capitalist economy._

I doubt that; it distorts competition by making false / aggrandizing claims about products and their prices and capitalist markets would work much better with transparency instead of the smokescreens of advertising (i.e. more comparison shopping).

> _In whose interest is it to kill that?_

Consumers and small businesses would profit greatly if advertising played a smaller role (big businesses spend a lot of money in advertising to sell inferior products, small companies find it difficult to compete even with better or cheaper offers).

Also, page load times and traffic plans, obviously.

<comment><USER11> Small companies sell better and cheaper products than big businesses, but somehow people have never heard about them, and that's because of "advertising". Sure, buddy. You keep telling yourself that.

</comment></comment></comment></comment></comment><comment><USER12> Personally I don't care about tracking if it means advertisers show me adverts I might want to click on (and thus the ecosystem I use can be funded). But I do care about adverts that aren't targeted to my needs and wants. I'd block those if I could, and leave the targeted ads alone.

</comment><comment><USER13> Is this really different from what AdBlock already does on every platform? It looks like the key feature is that the adblocker app doesn't have to have access to your browsing data. But people will still have to install it, just like they already have to install existing adblockers.

</comment><comment><USER14>
       How likely is it that these apps will be built? 100%. One of those is
       Crystal, by Dean Murphy. His pitches: ... Pages render more than 3.9x
       faster on average.

How is that measured?

Do ads delay the rendering of the important, non-ad content by nearly 4x? Or does that content render before ads, and the ads take a long time to render?

Put another way: am I going to see the content I care about 3.9x faster?

<comment><USER15> Given that ads on mobile typically block you from seeing the content until you've clicked through the ad, then I think it's safe to say that removing the ad lets you see the content faster.

<comment><USER14>
       Given that ads on mobile typically block you from seeing
       the content until you've clicked through the ad

In my experience, ads on mobile that don't block you from seeing content are more common than those that do.

I wonder if anyone has any hard data on this.

</comment></comment></comment><comment><USER16> It will be interesting to see how this plays out. Apple is (indirectly) going after any ad that they themselves don't power with iAd. Is that even considered "fair", in a legal sense? Seems pretty anti-competitive.

<comment><USER17> It's a different domain. Content blocking only applies to Safari. iAd ads only appear in third party apps if the developer chooses to use them. They could also use a different ads provider. That's not affected by content blocking because it's not a web page inside Safari.

<comment><USER18> we don't know their plans for the future. as long as it is a webview, they own it.

<comment><USER17> The future doesn't apply today. Today, webviews don't implement content blocking. GGP appeared to assume webviews did implement that.

</comment></comment></comment></comment><comment><USER19> This isn't the end of tracking, just the platform owners angling in on the market and setting up toll booths for advertisers. It does have the advantage of potentially less tracking overall, but personal data is still valuable and Apple just wants a piece of the pie on something they perceive they own. Tracking will be allowed as long as it doesn't significantly impact the user's experience or over-burden the data usage.

<comment><USER15> This is not true. Apple most emphatically does _not_ want a slice of the pie that is personal data. They've made it clear time and time again that they do not want your personal data, they do not monetize it, they do not collect anything more than aggregate statistics necessary to improve their own products[1], and Tim Cook has made it very clear that Apple's executive leadership values privacy very highly.

Unlike a lot of other companies ( _cough_ Google _cough_ ), Apple makes money by selling hardware and software. They do not make it by monetizing your data. And they view this as a competitive advantage.

[1] For example, you can bet they collect aggregate statistics on Spotlight searches that search the web, but they get rid of any personally-identifying information, so they can't tell anything about any given user (i.e. no tracking).

<comment><USER20> _> They've made it clear time and time again that they do not want your personal data_

Until they do. Which may or may not happen, but remains an extant problem regardless. Relying on the beneficence of a corporate entity is never a wise decision.

<comment><USER15> This is a preposterous statement. This is not about relying on their beneficence. This is about relying on the core values of the company, the things that the company views as a competitive advantage, the things that the company believes is one of the reasons why they've achieved unprecedented success and made boatloads of money. So you're actually relying on capitalism.

The argument for why other companies (like Google) do want your personal data is the exact same one for why Apple doesn't. Because that's how they make money. You might as well claim that Google may one day decide to just throw out all the personal data they have on everyone and become a charitable organization that gives away its software out of the goodness of its heart.

There is literally no reason to think Apple will change course about this, besides complete ignorance about how Apple works and what the core values that Apple believes in are.

<comment><USER19> >This is about relying on the core values of the company

I think you place too much emphasis on companies having moral values. Companies don't have values other than profits. The people in charge may have them, but they are relentlessly driven to produce value for the shareholders, which is not necessarily an evil thing. It's not the purview of a company to have moral values.

Apple have made themselves by becoming a platform rather than being strictly a hardware company. Their hardware can be regarded as tools or tokens necessary to access Apple's services, rather than products in and of themselves.

<comment><USER15> Not all companies are driven to maximize short-term profits. Or more generally, there exist companies which believe shareholder value is about more than short-term profits. Apple has demonstrated itself to be one of those companies. As a particularly public example of this[1], at the company's annual shareholder meeting in 2014, the National Center for Public Policy Research (a conservative think-tank, climate-change denial group, and investor in Apple) asked Tim Cook and the board to pledge that Apple wouldn't pursue any more environmental initiatives unless it improved the bottom line. Tim Cook's response:

> _We do things because they are right and just and that is who we are. That's > who we are as a company. I don't…when I think about human rights, I don't > think about an ROI. When I think about making our products accessible for > the people that can't see or to help a kid with autism, I don't think about > a bloody ROI, and by the same token, I don't think about helping our > environment from an ROI point of view._

And then he told them to sell their shares:

> _If you only want me to make things, make decisions that have a clear ROI, > then you should get out of the stock._

[1] [http://mashable.com/2014/02/28/apple-ceo-tim-cook-climate- ch...](http://mashable.com/2014/02/28/apple-ceo-tim-cook-climate-change/)</comment></comment></comment></comment></comment></comment>


TMobile Calling Outage - <AUTHOR> https://techcrunch.com/2020/06/15/t-mobile-calling-outage/ <comment><USER2> > One wire report says Level 3, a major fiber network backbone that cell > networks rely on for routing calls and message, is experiencing an outage, > which may point to why other companies are also struggling.

How common is it for major telcom companies to rely on third parties like this for routing calls?

<comment><USER3> I'd argue at that point that "the major telecom company" isn't so major and the "third party" is the more "major" company. :P

</comment></comment><comment><USER4> Cookie wall. No thanks.</comment>


Ask HN: Template contract between two co-founders? - <AUTHOR>

Hello everybody. A friend of mine and myself are thinking of starting up a little side project.
If this turns out to be successful, we'd like to have a contract in place that assures stuff like we get 50-50, important decisions must be taken by both of us etc. in general have an initial contract set up between the two of us.
Has anyone had experience with this and can you give some advice? Are there some online templates/samples of contracts like this?
Thanks! <comment><USER2> Make sure you also have a chat with your friend about the difficult stuff: what happens if one of you doesn't pull their weight; when is it OK to accept the business isn't working; at what price will you sell your stake; and so on. If you have this worked out in advance, there's less of a chance of destroying your friendship.</comment>


Stanford PhD Dissertation Browser - <AUTHOR> http://nlp.stanford.edu/projects/dissertations/

<comment><USER2> Thanks for the feedback, folks. I'm actually a bit surprised this hit hacker news without any of us authors posting it, but heck, I'll jump in.

Think of this as an experiment in exploring a document collection at a higher level than search. Specifically, what you're seeing is Stanford's dissertations through the lens of a text model that tries to distill high- level patterns in the data. It doesn't always succeed, but it often hits the mark. There are plenty of ways that the visualization and the underlying text model could be improved.

For the curious, I'll tell you a bit more on how the numbers are computed: we build a unigram language model of the contents of every Stanford department based on their dissertations. Then, we posit that every dissertation comes from a mixture of those department models (using a supervised topic model, Labeled LDA). This lets us infer, for every dissertation, a weighted mixture of departments that best characterizes that abstract. So, say, dissertation X is 60% computer science, 20% physics, and so on. These scores are aggregated to compute the average similarities between departments, and are sliced to give the view over time.

So what you're looking at is, essentially, a visualization of word overlap between departments measured by letting the dissertations in one department borrow from words from another department. Which departments borrow the most words from which others?

When you zoom in two-levels (click on a department twice), individual dissertations are plotted on a line between each dissertation's home department and it's next highest scoring department. So the relative position of two dissertations near each other is not meaningful unless they are on the same radial line. Dissertations from other departments that have a high score for the central, focused department, are also shown.

For instance, take a look at Computer Science in 2005. You'll see three dissertations along the radial line to Linguistics - those are the three students that graduated from the Stanford NLP group that year. There are plenty of other places you find similar things that work, and also places where things don't work as nicely as you'd expect.

The visualization Jason built was really interesting from the text modeling perspective, because it let us experiment with many model variations (lda, tf- idf, etc etc) to see how well each matched our intuitions. This model, though still wanting, was by far the best. Good enough, even, for us to put online for the world to play with, and for hacker news to pick apart ;)

<comment><USER3> why'd you take the data down? I was writing a scraper in order to make your underlying data into happy open and accessible data: <http://scraperwiki.com/scrapers/stanford-dissertations/edit/>

<comment><USER4> I can't speak for Dan, but it's probably best if you don't do this! I think most of the data itself is UMI data from ProQuest, which seems to be licensed pretty strictly.

<comment><USER3> boo proprietary data!

</comment></comment></comment></comment><comment><USER5> Neat? Yes.

Usable? No.

I'm not sure if theres some piece of information thats trying to be portrayed here (other than quantity of dissertations per major) but as a browser, it's pretty useless. It employs mystery meat nav heavily, mostly because you have to hover over a dissertation to view any info about it. Imagine finding a paper you liked, and then going back 15 minutes later to try and find it.

If there is some data thats trying to be shown its not clear to me what it is. Some of the inner circles are in columns which seem to indicate correlation, but I cant figure out if thats accurate or not. For instance, if I click on philosphy, I see a dot in the direction of Food Research, and when I hover over that dot I see a thesis about "Practical reasoning and the varieties of agency".

What is trying to be portrayed here?

<comment><USER6> Yep, this is a really bad way to present the information. Having a collapsible columnar list for each department would be orders of magnitude more useful. Plus it would be in HTML, and you could use ctrl/cmd+f to search for dissertations by keyword.

Perfect example of _bad_ data viz.

<comment><USER7> Yes and no. I found quite useful and visual the way to show the relationship between topics. For example, you can see the close relationship between biology and psychology. I'm not sure a large table could the job.

<comment><USER5> I see almost no correlation between bio and psych. In fact, I only see 2 articles that link those 2 topics at all.

</comment></comment></comment></comment><comment><USER8> Oh, for a second there I thought Stanford made all their dissertations available online. On second thought why doesn't universities do this and instead try to sell access? I've heard of people who put in a $20 bill in the copy of their dissertations in the university library and finding it intact years later.

<comment><USER9> At least for C.S. I would guess that most people will happily send you a PDF copy of their theses (if they're not available from their websites already). Just send them a friendly email.

<comment><USER8> You're right but contacting everyone like that is not very practical, in most cases you're nor event aware that a dissertation for the topic you're interested exists.

IDEA BOLT: What if one creates a central website that offers free storage and search capabilities and ask people to upload their dissertations and theses?

What do you think about that idea?

<comment><USER10> <http://arXiv.org>

<comment><USER8> Yep, but arXiv's content is very limited, e.g. very little EE research and economics, and nonexistent social sciences.

<comment><USER10> I don't know where to find the stats, but the number of categories has expanded greatly. I assume that trend will continue.

The hard part is convincing people to upload their work. Even in physics the use of the arXiv is not uniform. In some areas, almost every published and unpublished paper is posted, while in other areas of physics hardly any papers are. For example, compare the category Quantum Physics with Space Physics.

</comment></comment></comment></comment></comment></comment><comment><USER11> I did my PhD in Computer and Systems Engineering (in the EE department of my school), an my thesis involved use of Computer Vision and AI in the analysis of microscope images of human cells, so I did a lot of work with MD's and Biologists. I thought it would be interesting to see which theses overlapped cell biology and Electrical Engineering.

The browser showed two overlaps: "Low-Power dynamic amplifiers for pipelined A/D conversion" and "Precision clock synthesis using direct modulation of front end multiplexers/demultiplexers in high speed serial link transceivers"

The first of these mentioned "cell phones" in the abstract. There was no evidence of any cell biology link in the second.

The visualization may be interesting, but I'm not so confident in the quality of the data.

</comment><comment><USER12> Interesting setup, but it seems pretty wildly incorrect at times.

For instance: Comp Sci -> Ethics: "Designing interactions that combine pen, paper, and computer". Comp Sci -> Radiology: "Securing untrustworthy software using information flow control" Comp Sci 98 -> Physiology: "Consistent overhead byte stuffing"

Could be a heck of a lot better. Especially given the long almost-locked-up pauses, and the inability to keep a block of text up when you move the mouse away. All the little things add up, making me doubt the creator used it themselves at all, aside from making sure it functioned.

</comment><comment><USER13> I'm a little annoyed that they used the phrase "topic distance" but it looks like they're using something which is in some cases very asymmetric (the 'distance' between CS and EE is not the same as between EE and CS). As a visualization, it's not meaningful because they don't explain what it means for two topics to be 'close'.

I'm guessing they're using something like a KL divergence between the distributions over words (smoothed?) given each topic, but that could be way off.

</comment><comment><USER6> It it possible to obtain the data for this somehow? I'd interested in making a different, more straightforward columnar text-only view.

</comment><comment><USER14> In flash? C'mon!</comment>


Don't use Git rebase - <AUTHOR> https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1 <comment><USER3> `git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review.

I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setting yourself up for failure in the `git bisect` case: when you step back to find the source of an bug you're tracking down, the worst possible case is that you find it's introduced by a merge and not present in either of the parents. That's much more likely if your merge commits contain fix-ups of their own, which in turn is much more likely if you've got overlapping branches. If you rebase-and-merge then the merge won't have any extra changes, and if you rebase-and-fast-forward then you won't have any merge commits at all.

<comment><USER4> But that's exactly why I prefer merges - seeing that the problem wasn't in any individual branch, but resulted from the combination of changes in both is the most honest result that I would've wanted to see. Why do you label this as a 'failure'?

<comment><USER5> It sounds like rebasing this way ensures branches will not overlap at merge time. This presumably pushes the "combination of changes" into the rebased- before-merging branch, which (if nothing else) makes sure that one committer owns the bug, not two.

<comment><USER6> In case of merge that would be merge commit author.

</comment></comment></comment></comment><comment><USER7> There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.

<comment><USER8> Or well, simply use both. Feature branch, use merge - the feature is an important artefact, and there it is important for the history to show it.

Bug Fix branch, working on a shared branch, use rebase. The branching in those case is a side effect the exact time two colleague committed on the same branch. There is no information you gather from that, it is just a technical blip in the history.

Not quite sure the obsession people have in using only 50% of the tool they have because the other 50% could be misused.

Similarly, digging for a bug in several hundred commits is going to be shit. Hindsight is very deceptive with bug hunting - they always hide in plain sight, if you know where it is, it is easy to imagine "oh, I would have seen it immediately with a merge". Maybe, probably not.

You see that of that kind of overreaction in Management. There is a bug in production, we must introduce more testing, or more testing phase, or change the way we design the around that single experience. But sometimes, bugs just happen.

<comment><USER9> Rebases and merges don't work well together. By default, git rebase will get rid of merge commits. While there is an option to preserve merges (-p), it can lead to some strange behaviour while doing an interactive rebase - see BUGS section in git-rebase man page for more details.

I'd also argue that merge and rebase represent fundamental differences in what commits mean. The former being commits are history, and the latter being commits are features.

<comment><USER10> I'm a pretty basic got user, just wanted to say this was a really useful distinction for me to read.

</comment></comment></comment></comment><comment><USER11> What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing.

Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity to revisit conclusions from debugging or experiments.

You can also use merge commits to describe sub-units of work in your feature branch. Just rename your branch to some subtask and merge that into your feature branch.

edit: towards the middle of the article, the author also opines "What motivates people to rebase branches? ... I've come to the conclusion that it's about vanity. Rebasing is a purely aesthetic operation. The apparently clean history appeals to us as developers, but it can't be justified, from a technical nor functional standpoint."

<comment><USER12> There's no such thing as "real" history - you don't commit every line of code you add or remove, or even every character. Rather, you choose some points in time to commit.

For me, those are often arbitrary - I can't get something to work at a certain point, so I make a WIP commit with the buggy work at that point, and will come back to it the next day.

Before I merge my branch back into master, though, I want my commit history to be useful. "This is the point where I went home or was disturbed that day" is not useful to future developers. "This is the work I did on this individual feature and everything that's needed to run it and to have the tests succeed is in this commit, and this was the reasoning behind what I did", however, is.

In other words, I rebase to divide my codebase into non-arbitrary units of code, not based on chronology, but on what is useful together.

<comment><USER13> Well, assuming that you are adding features in parallel you have an history. You have a branch with feature A and are about to build feature B, which is now based on A, someone else is building feature C which is also based on A. Building B and C might require different or equal changes to A.

There's no guarantee that any of these features will be built in order since they might have different priorities, difficulties or level of acceptance so it's hard to tell which one must or will be done in what order. Rebasing pretty much settles that while merging is much more sane to that workflow. It's harder to keep it functional yes, but it's enabling parallel development. Using rebasing and/or merge isn't a source control problem but a feature management problem.

<comment><USER12> Yeah I think my point was more that a blanket ban on rebasing is too rigorous. I agree that once you want to integrate B and C (or both into A), a merge is usually the best way to do it - and I think that's what TFA was actually referring to.

It fails to consider the case, however, of rewriting B's history internally, not as a way of integrating with A or C, but as a way of making its commits clear. Afterwards, you'd still do a merge of A into B and then merging B back once you see that's successful.

</comment></comment></comment></comment><comment><USER14> I like rebase. Because to me, git is more about communicating changes to other people than finding bugs. Just like testing is as much communicating intent to other developers as preventing new bugs.

So we rebase, and we merge with merge commits. This way, the developer are forced to resolve conflicts one by one on their own branch, instead of sorting out a huge pile in one go on a shared branch.

What I like about git, though, is that you can choose different approaches. Discuss in your team what you find important and use git to support that. If finding bugs with bisect is your main thing, use git in a way that makes that as easy as possible. If your have other needs, you'll have to find other ways of using the tool.

Learning and understanding the tool to use it in the best way to satisfy your needs.

</comment><comment><USER15> This seems like a knee jerk reaction because a co-worker's sloppy rebase caused you to waste a day.

This highlights a bigger issue, many people don't learn their tools well enough.

I've been teaching my fellow senior engineers how to use git the last six months because they've only been using git GUIs until then. They're terrified of merge conflicts and they often make mistakes fixing them.

I'd rather educate people and let them make their own decisions once they can understand and justify the tradeoffs.

<comment><USER16> My thoughts precisely. I mostly use rebase, except when I know multiple commits in my feature branch will cause merge conflict with master - in that case, I save myself the trouble, do a merge and be done with resolving all conflicts in one go.

My ideology is - prefer rebase first, resort to merge if it will let you do the gnarly merge fast. Of course this is because of the development environment I work in where we just don't use bisect and the workflow is different. I also keep in mind that if I work on a different repository with differing testing/development processes this ideology will change.

The first few days I work on any new project(due to a job/project transition), I figure out how I can iterate as fast as I can and see what my time saving points are. How to best use the git I know, on the current repo, is also a minor part of this poking process.

</comment></comment><comment><USER17> Doesn't squash and rebase eliminate this problem? It removes all those possibly broken intermediate commits once it's in master.

I'll add that another annoying thing about rebasing is that if you make multiple changes to the same piece of code that conflict with changes on master, when you rebase, you have to resolve each change independently instead of only the last snapshot. However, if the changes are in different places, I like the incremental conflict resolution process of rebasing instead of the one-shot merge commit.

<comment><USER18> You can have git remember the previous conflict resolutions and automatically apply them the next time you rebase the same code by setting git config --global rerere.enabled true

It's a builtin feature, see the documentation [https://git-scm.com/docs/git- rerere](https://git-scm.com/docs/git-rerere) and a description here: [https://git-scm.com/blog/2010/03/08/rerere.html](https://git- scm.com/blog/2010/03/08/rerere.html)

Very handy if you use rebase with multiple commits to the same code.

</comment></comment><comment><USER19> There is a third option nobody seems to talk about `git merge --squash` (a squashed commit bundles commits into one commit). Which produces like `rebase` a linear commit history, but preserves the single commits.

<comment><USER20> I would think squash a poor default policy; it destroys information in the granularity of commit, and in the commit messages.

<comment><USER21> Nothing is lost if there's no information there in the first place.

<comment><USER20> I agree; if your commits are poorly planned and poorly commented, then I don't see any particular reason to avoid squashing them.

But if your commits are poorly planned and commented, I would recommend trying to improve them, rather than reveling in the fact. ;)

</comment></comment></comment></comment><comment><USER22> In addition to squashing commits, you can merge with `--no-ff` to create s merge commit and semi-linear history showing when new code arrived.

<comment><USER23> This should be getting more attention. From the perspective of the master branch, it has the benefits of squashed merges without losing your commit history.

I'll often have a patch that has a few things going on:

1\. Refactor code in one file

2\. Fix a bug in another module uncovered by the newly refactored code (maybe a code path that hasn't been hit until now)

3\. Some quick fixes made while I was looking at that code

...if I made a mistake in step 1, it's likely that step 2, step 3, or both would be useful to keep. If it's squashed and merged, it may be difficult to undo just step 1. And it's good communication to keep each as their own commit because each is its own atomic change.

And I can always squash things myself as I feel the need.

</comment></comment><comment><USER24> At least part of the arguments against rebase are arguments _for_ feature branches. Keep master forever and rebase your feature/bug branches, I would rather say. E.g bitbucket has features for this too - prohibit force push on master/release branches, allow on dev branches.

</comment><comment><USER25> _There are many magnificent tools that can analyse and visualise complex Git history, both GUI- and CLI-based._

Just tell me one. All git tools I know do such a terrible job at this.

<comment><USER20> Any examples of what you find terrible?

Ever tried magit? I don't know if you'd find it terrible, I find it not so bad.

</comment></comment><comment><USER26> I'm really surprised no one (article included) has brought up the "Golden Rule of Rebase" ([https://www.google.com/search?q=golden+rule+of+rebase](https://www.google.com/search?q=golden+rule+of+rebase)), which boils down to "never rebase a shared branch". Git is an extremely powerful tool for collaboration, and it's frustrating when I see that undermined.

<comment><USER27> The rule makes a lot of sense but most of the articles I found completely ignore if this includes systems like GitHub or Bitbucket. Technically you can create a Pull Request based on the branch yet no-one is actually "using" it. Would you say the rule also applies to such a branch?

<comment><USER26> I would. A common thing I like to do is start working on top of work that's in a Pull Request. For example, maybe a coworker is adding an API that I want to use. So long as I'm confident the API won't have drastic changes, and there's just smaller polish or testing to be added, I can branch off of their branch and start working without delay. This also gives me a window to live on top of the changes and give feedback from usage even faster (maybe even before it officially lands).

</comment></comment></comment><comment><USER28> I tend to use rebase solely for the purposes of creating tidy commits before I merge my changes into a staging branch.

For example when I'm working on a feature I tend to do n things at once, but I then want to create logical commits which separate the work into logical unit which could be reverted etc. as necessary. If in this process I notice that I've forgotten something (or for that matter, realise later than I've introduced a bug / broken tests) I'll tend to create a patch commit for that logical unit and then `git rebase -i HEAD~n` and then fixup that patch into the original commit.

Also, whenever I'm done for the day instead of stashing I: `git commit -am "wip"; git push; git reset HEAD~1 --soft` (i.e. push my changes up to Origin to avoid any localized mishaps with my PC resulting in a loss of work). I then force push to my feature branch.

I know that both of these "change history", but as long as they're isolated to my own feature branches I see no reason to avoid doing so...

</comment><comment><USER29> > Consider the case where a dependency that is still in use on feature has > been removed on master. When featureis being rebased onto master, the first > re-applied commit will break your build, but as long as there are no merge > conflicts, the rebase process will continue uninterrupted. The error from > the first commit will remain present in all subsequent commits, resulting in > a chain of broken commits.

Easy, just fixup the commit that (re)introduced the dependency.

> You pretend that the commits were written today, when they were in fact > written yesterday,

The author and committer dates will differ accordingly.

</comment><comment><USER30> Rebase is incredibly useful for me because I commit on every save and squash my commits before submitting for PRs (if working on a team). I commit on every save for three reasons:

1\. I can easily undo small mistakes this way,

2\. It makes it easy for me to pick up what I've done the last time I worked with that codebase, and

3\. It makes it easier for me to tell a comprehensive story when I'm ready to submit my PR.

That said, I do see the authors point about rebasing onto a branch with dependencies.

<comment><USER31> "rebase" (like many terms in git) has multiple implications. It sounds like you're advocating for squashing your commits / cleaning up your history, which I don't think anyone argues against. The linked post argues against re- parenting those changes.

</comment></comment><comment><USER32> > Graphs of non-linear history, "train tracks", can be intimidating. They > certainly felt that way to me to begin with, but there's no reason to be > scared of them. There are many magnificent tools that can analyse and > visualise complex Git history, both GUI- and CLI-based.

It's a pity the author doesn't mention some of those magnificent tools. Some tools I know/use:

      CLI: tig
      GUI: gitg, qgit (Linux)

Any others?

<comment><USER33> For Mac users, there's [http://gitup.co/](http://gitup.co/) (I'm not affiliated and it's FOSS).

GitUp is beautiful, incredibly fast and you operate directly on the (well laid-out) graph for almost everything, so you're always acutely aware of the commit history.

(I mostly use Windows + Linux at the moment and this is probably the piece of software I miss the most, even though I prefer shell for absolutely everything else)

<comment><USER34> +1 for GitUp. Only annoyance is that it can be slow when staging/unstaging lots of files.

</comment></comment></comment><comment><USER35> this is a narrow view based on someones versioning habits , the point of rebase can also be a solid linear history that allows multiple teams to fork and pull request features between forks. If developer chooses to play merging inside his own repo, fine but as soon as you have large teams working on their own you will end up in merging hell between developers and teams.

say team a does 58 commits per day has 75 team-members and team b has 126 members that are doing 187 commits per day and there's team c, d , e .... n giving non conflicting input to your codebase.

the flow in this case would be to always rebase developer specific features on non-conflicting codebase before you are allowed to pullrequest your changes to central repo. Rebasing to master or to any feature branch developer needs to work will allow them to see any conflicting changes they have made directly in their repo (rebase conflicts and a way to solve those as they know what conflicts, they have introduced the conflicts) instead of merging it together and finding out that the repo they need to PR this stuff will utterly fail cause they are lagged behind or several developers have changed the same files.

in this case rebase flow brings the shit to developer to handle and gives them knowledge that it will break. This mainly happens cause they are not having the latest version of code whereas merge strategy will merge in the conflict and send it to others to discover that thy can't merge any more cause of other developers conflicts.

Merge strategy is not suitable in case where code is edited rapidly daily and some features take , weeks, years, are to be included. Whereas rebase strategy ensures that every developer will always send you changes that are not conflicting with up to date version of whatever is versioned.

</comment><comment><USER36> I vehemently disagree. A counter-argument to his `git bisect` problem is whenever I do `git bisect` and I end up on the merge commit being the culprit. At that point I want to cry, because merge commits tend to be ungrokkable — there is so much noise in them.

Also, don't even get me started on `git revert`ing merge commits... Down that road lies sadness and disillusion.

<comment><USER37> Indeed. Seems like a better solution to his problem is to run unit tests after a merge before pushing it upstream. Then no more non compiling commits.

</comment></comment><comment><USER38> If you want every commit to compile then have your CI system check this; no need to blame a useful tool.

</comment><comment><USER39> I tend to think the problem identified by the author is more of a fundamental problem with long-lived development branches that diverge with master - <USER2> will change under you and it's not always easy to notice.

It's also kind of a problem if underlying parts of the system that you depend on either are churning that much without that being communicated or if they have poorly-defined interfaces and are prone to accidentally breaking things that users depend on.

It's not entirely clear, but there may be some testing gaps too if bugs weren't found.

Maybe merge-based workflow helps a bit but it seems like the pain would still be there regardless.

<comment><USER40> Author of the article here. You are absolutely right, and many of the other comments here suggest that people are struggling with problems that stem from the fact that their branches are long-lived.

I would encourage everyone to consider adopting trunk based development ([https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)). I expect this to solve many of the problems people have. Using short-lived feature branches that are merged every day, merges are trivial, and history easy to read. A rebase-based workflow wouldn't be that harmful if you use short-lived branches either, although the argument for preserving history still stands.

</comment></comment><comment><USER41> I liked the style of writing, but the lack of knowledge of the author made me create this account and adding my first hn comment.

Thanks to all others who explained technically what upset me so much.

</comment><comment><USER42> Odd, I would rebase develop onto my feature, resolve conflicts which is easier as I'm dealing with my changes, then merge to eg develop. When time comes for integration I'd probably squash commit changes to the integration branch just to keep that a bit easier to track/undo, but preserve full history in my feature and develop branches do can revert specific commits etc. As always useful comments are a must so I disable automated merge commits.

</comment><comment><USER43> When using `git bisect` to find a bug, `git bisect good` and `git bisect bad` are not the only options available, there's also `git bisect skip`. You should only mark as bad commits that specifically manifest the bug you're looking for and not, say, build errors or other unrelated bugs. It _is_ true however that the type of build breakage potentially brought in by using git rebase will require you to do more bisect steps.

<comment><USER44> > It is true however that the type of build breakage potentially brought in by > using git rebase will require you to do more bisect steps.

Or leave you with an inconclusive result if the guilty commit also happens to be one of the _skipped_ commits

</comment></comment><comment><USER45> I use rebase because I often have long-running feature branches (maybe for a couple of weeks) and I want to keep up with changes on master. When I was new to git, I used to merge master into feature branches to achieve the same effect, but my pull requests were littered with commits already made to master.

Is there a better way to keep feature branches updated with changes on master?</comment>


How to End Poverty in 15 Years [video] - <AUTHOR> https://www.youtube.com/watch?v=PVjZjPbHrFE <comment><USER2> Big fan of Rosling. It's interesting seeing Malawi about 20 years after I was there. It hasn't changed much unlike places like China and Thailand which have been transformed. I've got a theory that info tech like internet and smartphones will lead to Africa growing like Asia.</comment>


What makes Functional and OO programming equal - <AUTHOR> http://codinghelmet.com/articles/what-makes-functional-and-object-oriented-programming-equal <comment><USER2> This reminds me of chain (dot syntax composition with objects) vs. actual function composition & currying:

[https://medium.com/making-internets/why-using-chain-is-a- mis...](https://medium.com/making-internets/why-using-chain-is-a- mistake-9bc1f80d51ba)

</comment><comment><USER3> Nonsense on stilts. What matters is the __"Why"s __; not the "How"s. Any other discussion is just implementation crap.

OO is imperative; functional (caveat impure pollution) is declarative.

The goal of declarative coding is to tell the machine what you want, rather than how to do it. The state of any program is inherently time-dependent; transferring responsibility over state from the programmer to the software gives the system the hard guarantees it needs to reason _mathematically_ about a program and thus make its own decisions on how best to perform it: deferring a task here, parallelizing an operation there, reliably converting nondeterministic input into predictable output without fear of locking or races or different answers every time, and so on.

Not a different way of doing; a different way of _thinking_. Both human _and_ machine.

In contrast, the imperative system _cannot_ reason reliably about state over time as it lacks the complete control needed to enforce such guarantees. Any internal/external actor might affect that state in any way at any time; the system has no way of knowing for sure. Stuck with the Hobson's choice of being reliably dumb or unreliably wrong, it can only do exactly what you tell it to do in the exact order you tell it; it cannot do anything more. Lacking the deeper insights that a declarative system possesses, the imperative machine simply isn't competent to make any higher-level decisions for itself.

Much like a lot of today's programmers, really: wetware Turing Machine implementations of Plato's cave. Why expand their understanding outwards when they can so easily drag everything down to fit neatly inside their existing level of ignorance, squished to uselessness by a mindless fixation on the micromanaging mechanical minutiae of it all?

And still we wonder why so many systems nowadays are absolute garbage. But hey, you just keep on banging those rocks together, guys…

.

Obligatory:

[https://en.wikipedia.org/wiki/Referential_transparency](https://en.wikipedia.org/wiki/Referential_transparency)

[http://calteches.library.caltech.edu/51/2/CargoCult.htm](http://calteches.library.caltech.edu/51/2/CargoCult.htm)

<comment><USER4> I wonder why Edsger Dijkstra didn't agree with you, or, rather, with what you insist.

Fact is, it's all ultimately about getting a machine to do the operations needed. What varies is how much effort you have to waste, on top of actually telling the machine what it should be doing, and how much wasted activity the machine has to do because you couldn't direct it more precisely.

Every program, in any language, strikes a balance. Some languages force the balance toward one side, others the opposite. Better languages minimize the total.

Functional languages, as Dijkstra complained, tend to force wasting time by copying unnecessarily. Mutating languages make program transformations by the compiler -- optimizations -- harder, but most potential optimizations are to make the machine do more mutating and less copying.

The machines keep getting faster (less so, lately), but the problems grow to match. At all times, over 70 years, the mutating languages have got more useful computation out of the machines where it mattered most.

When the machines get too complicated to understand, the balance might change. Nobody knows when that might happen, if it ever does before the whole topic becomes moot.

In the meantime, programmers sort themselves out neatly between those who prefer to waste machine cycles for what amounts to esthetics, and those who find ways not to, without actually suffering for their choice. That is where we have been for decades, and may still be when civilization collapses.

<comment><USER3> "Functional languages, as Dijkstra complained, tend to force wasting time by copying unnecessarily."

Citation required for your suspect AF appeal to authority/deathbed conversion story. 'Cos even dead and rotted, the corpse of EWD doesn't give a flying shit how fast your program is if you cannot __prove __it right first. The man spent his whole career trying to hammer the rigor of science and mathematics onto the mess that was, and still is, computer programming.

Here's some of EWD's actual words:

[https://www.cs.utexas.edu/users/EWD/transcriptions/OtherDocs...](https://www.cs.utexas.edu/users/EWD/transcriptions/OtherDocs/Haskell.html)

[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html)

Not exactly the reckless racer boy, he. Perhaps you were thinking of Dennis Ritchie?

.

"When the machines get too complicated to understand, the balance might change. Nobody knows when that might happen, if it ever does"

Um, that balance already tipped on its side a half-century ago, skippy. Try to keep up.

[https://en.wikipedia.org/wiki/Fred_Brooks](https://en.wikipedia.org/wiki/Fred_Brooks)

<comment><USER4> Gee, you sound bitter.

There was a reason I mentioned Dijkstra, but it wasn't an argument, so "appeal to authority" doesn't apply. Common mistake, though.

Dijkstra is relevant specifically because he advocated a mathematical approach.

If you're actually curious, you can read up on the famous feud with Backus, where Backus was promoting functional programming, and Dijkstra wouldn't give him the time of day. It's pretty amusing, at this remove.

My guess is you're bitter because nobody controls important equipment with FP languages; or publicly regrets it when they did. I might be bitter too. But I'm not.</comment></comment></comment></comment>


Show HN: Digital Signatures on the Blockchain – With Smart Contracts - <AUTHOR> http://dashboard.attores.com/?utm_source=hacker_news <comment><AUTHOR> A. Digital Signing 2.0: Our uncluttered interface lets you easily sign documents and secure them with blockchain technology

B. Smart Contract and Blockchain Secure: By using secure smart contracts, we enable real time auditability & cryptographic proof of transmission & acceptance. (Absolutely easy to verify the authenticity + keep the private record.)

C. Digitize your Documents: Say goodbye to the days of printing, signing, scanning and emailing!</comment>