Kleiner bets the farm - firm is going green and leaving Internet deals to the competition. - <AUTHOR> http://money.cnn.com/2008/07/08/technology/Kleiner_bets_the_farm_Lashinsky.fortune/index.htm

<comment><USER2> This is Al Gore's fault.

</comment><comment><AUTHOR> Other than betting on cap & trade gov subsidies, I wonder how they plan to exit these positions...

<comment><USER3> I think that Doerr may be betting that if he throws enough money at enough different startups, _one_ of them is likely to come up with something that is economically competitive with fossil fuels, and can replace it over the long term. The worldwide oil market is in the trillions; it's not like there's a lack of money to be had.

It's basically a high-stakes gamble with other people's money. If he wins, he goes down in history as the man (well, the guy behind the man) who saved the planet and ushered in the solar era. If he loses, his reputation is toast, as his clients' money.

I'd give you about 10:1 odds that he loses, but considering the payoffs to himself, Kleiner, his clients, and mankind as a whole, I'm glad he's taking that bet.

<comment><AUTHOR> I agree with you but I think your odds are way too generous :). Vinod Khosla is another high profile VC that has taken some heavy positions in clean tech as well but he has kept his ear to the ground and has invested in quite a few of internet/tech startups as well.

Problem with clean tech is that most of it is capital intensive and many times you have no idea if something will work until you spend $10M on it. You just can't fail fast. After you do your R&D, few years will pass. Then, if you have something, you will have to raise another huge round so you can build it out. That's very cap intensive and again, takes long time.

Most funds operate on a 7yr timeline. With cleantech, you'll be lucky if you make an exit after 10 years. And still, the biggest issue, as I pointed initially, is the lack of exit points. IPOs are very hard these days and who knows what the future will look like.</comment></comment></comment>


Watch out Chartbeat! Google Analytics is going real time - <AUTHOR> http://cutroni.com/blog/2011/09/29/google-analytics-real-time-real-time-data-for-real-time-decisions/

<comment><USER2> This is a huge improvement for Google Analytics. I always needed to have multiple tracking scripts installed on my website because google didn't display the data in real-time. I'm excited to test it out.

<comment><AUTHOR> Looks really good. But why did it take so long?</comment></comment>


The perfect way to slice a pizza  - <AUTHOR> http://www.newscientist.com/article/mg20427381.500-the-perfect-way-to-slice-a-pizza.html?full=true&print=true

<comment><USER2> The best way to slice a pizza is half for me, and rest of you can fight over the other half.

</comment><comment><USER3> I was really hoping this involved a laser cutting machine.</comment>


Ask HN: For someone who was under a rock, what should they do to gain knowledge? - <AUTHOR> I think this could provide people who feel like they don't under how the world works, or have been too much busy with themselves a different outlook into things. Also, it may get some great responses. <comment><USER2> I want to answer your question but "gain knowledge" is too broad and I don't know how to respond. Consider making the question more specific. What kind of knowledge? What would they use the knowledge for?

</comment><comment><USER3> \- Provoke conversations with people about topics they find interesting. Ask them about the parts you don't understand. Then go off and do research on the internet / at the library about the topic. Then, if possible, talk with that person again now that you have a good understanding of the topic. They may be able to tell you things that aren't written down.

\- Do things. One of the best ways to learn is by doing. If you want to learn about programming, write programs. If you want to learn about thermodynamics, build a small Stirling engine. If you want to learn about politics, join a political party (or form your own).

\- Find people who want to learn the same thing you do, and learn together. I think that probably the primary advantage that universities offer over just learning things from books is that they gather together a bunch of people who are all interested in learning the same things.

But how should you choose what to learn about? What knowledge is important and worth having, and what knowledge could you do without? Some ideas:

\- Learn about what interests you.

\- Consider practical applications. Learn about things that seem useful.

\- Learn a little bit about everything. Even if you don't know much about physics, you should still know enough to expect that your uncle Frank's perpetual motion machine isn't going to work.

\- But also develop a very deep knowledge about a few areas. Ideally these should be both useful, and interesting to you.

\- Try and get a good idea about what the future will look like as early in your quest for knowledge as possible. This will probably involve learning some history and some science. Unless you're some kind of superhuman, you should be envisioning a probability distribution over possible futures, not predicting a single future that is "definitely going to happen". In doing this, be as honest with yourself as possible about the assumptions you are making, and how likely they are to be correct. You should also update this probability distribution whenever you come across a new piece of pertinent information, especially if it contradicts your assumptions.

\- Then try and learn things that seem likely to be useful across many possible futures.

Final advice:

\- Remember that getting knowledge isn't the ultimate goal in life. You should get out and have some fun once in a while. Social skills are more important than book learning.

\- This comment was written by a random person on the internet. Take it with a grain of salt.

<comment><USER4> > If you want to learn about thermodynamics, build a small Stirling engine Do > people really do that? I am a chemical engineer but I have never heard > anyone do that, though it sounds fun.

</comment></comment><comment><USER5> Find something that fascinates you and research it. It's an amazing time for learning now, with introductory through to really deep knowledge and supportive communities available throughout the internet. Youtube itself is a goldmine, with some extremely well produced content exploring different topics. Then of course there are books and documentaries, forums and papers. Topics could include:

\- History

\- Science, Tech & Futurism

\- Motorcycle, Automobiles & Engineering

\- Art & Art History

\- Philosophy

\- Religion

\- Geopolitics

\- Economics

Now if you are like most people, this will kill a few hours but you wont quite "get into" the topic. Or you may feel excited about a topic for a few weeks/months and then loose interest. However, eventually you may find something that really interests you and take it further, until it becomes a hobby or a career. And if you don't, well you'll still more knowledgable than when you started.

</comment><comment><USER6> What kind of rock are we talking about?</comment>


270 million Android users in China - <AUTHOR> http://www.net4tech.net/2013/11/270-million-android-users-in-china.html <comment><USER2> NSA gold mine.</comment>


How to make your first steps in Open Source contributing - <AUTHOR> https://blog.checkio.org/how-to-make-your-first-steps-in-open-source-contributing-2afc1f45eb45 <comment><USER2> [http://www.firsttimersonly.com/](http://www.firsttimersonly.com/) by Scott Hanselman + Kent Dodds is an iteration on Scott's [http://up-for- grabs.net/](http://up-for-grabs.net/)

Scott also did a walkthrough several years ago: [http://www.hanselman.com/blog/GetInvolvedInOpenSourceTodayHo...](http://www.hanselman.com/blog/GetInvolvedInOpenSourceTodayHowToContributeAPatchToAGitHubHostedOpenSourceProjectLikeCode52.aspx)

[https://www.hanselman.com/blog/BringKindnessBackToOpenSource...](https://www.hanselman.com/blog/BringKindnessBackToOpenSource.aspx) is targeted more at maintainers.

There are a great number of additional resources and discussion on those blog posts.

If video is your jam, check out Scott's presentation "Getting Started in Open Source": [https://youtu.be/nmiftiGktsU](https://youtu.be/nmiftiGktsU)

</comment><comment><USER3> OT: The icons and banners that constantly hover around the text make it really hard to concentrate on it. Thank god for Firefox' reader mode.

<comment><USER4> Yeah, this is just unreadably ugly.

</comment></comment><comment><USER5> Semi-related: I wrote this post [0] to try and motivate people to contribute.

[0] [https://dev.to/yelluw/things-you-can-do-to-contribute-to- ope...](https://dev.to/yelluw/things-you-can-do-to-contribute-to-open-source)

</comment><comment><USER6> Exactly what I needed, thanks Katerina Sand</comment>


Cdnjs – the missing cdn for JavaScript and css - x-sam http://cdnjs.com/

<comment><AUTHOR> so... what's new here?

Posted 3 years ago: [https://news.ycombinator.com/item?id=2828516](https://news.ycombinator.com/item?id=2828516)

and posted 2 years ago: [https://news.ycombinator.com/item?id=4412044](https://news.ycombinator.com/item?id=4412044)

<comment> x-sam sorry, search didn't work for me and hacker news didn't redirect to the existing link</comment></comment>


It's time for a native EventEmitter - <AUTHOR> http://ricardo.cc/2012/08/09/Its-time-for-a-native-EventEmitter.html

<comment><USER2> Ooh, yes please, and can we also please have every browser provide slightly different behavior, preferably through prefixed APIs? That way, we can have a dozen _new_ libraries that smooth over the differences until Ecma has a chance to standardize it in 2015 or so! What fun!

</comment><comment><USER3> Great, let's write one EventEmitter and make everyone else use that. What?

The problem is different - there is no single package manager in the browser world that has taken off.

BTW. In the browser the native and well documented way of dealing with callbacks is by using the EventTarget API:

[http://www.w3.org/TR/DOM-Level-2-Events/events#Events- EventT...](http://www.w3.org/TR/DOM-Level-2-Events/events#Events-EventTarget)

<comment><USER4> > BTW. In the browser the native and well documented way of dealing with > callbacks is by using the EventTarget API

Closure Library uses EventTarget for their event handling system[1], thus making it work exactly the same for browser events and custom events. YUI 3 takes similar approach, but instead they use their own API, however also based on DOM events model.

[1] [https://closure- library.googlecode.com/svn/docs/class_goog_e...](https://closure- library.googlecode.com/svn/docs/class_goog_events_EventTarget.html)

<comment><AUTHOR> You mean they implement their own event emitter following the EventTarget spec :)

<comment><USER4> I meant to write EventTarget _API._ Yep.

However, the implication is that it's based on the DOM event model. So, for example, you have three stage processing: 1) capture phase, 2) target phase, and 3) bubble phase. YUI 3 has its own API, but they still follow that model. This is a bit stronger contract than just your generic 'EventEmitter,' which only implies a simple observer model.

</comment></comment></comment></comment><comment><USER5> As an occasional Javascripter, I've gone looking for this several times, and each time been bemused to discover it isn't there (probably just as an instantiatable EventTarget).

Better package management might help, but some things are fundamental enough that they belong in the core library. I'm pretty certain this is one of them.

</comment><comment><USER6> Yes, I've thought this for quite some time.

Heh, I just wrote a "me too" post. :J</comment>


Testing Out This Thing - <AUTHOR> https://climatebase.org/ <comment><AUTHOR> test te</comment>


Git koans - <AUTHOR> http://stevelosh.com/blog/2013/04/git-koans/ <comment><USER2> Git commands are not consistent. This is a result of it growing organically, and having a maintainer who strongly values backwards compatibility. But you know, having used git for years that doesn't bother me. Let me explain.

Git is conceptually straightforward[1]. It is difficult if not impossible to discern those concepts from its baroque CLI. So learning git from its built-in help and/or man pages is suboptimal if not a complete waste of time. Either read the Pro Git book[2] or pop the hood[3]. Then the inconsistent CLI is no longer a big deal. If it were, someone would have come up with a new porcelain (high-level CLI) that would have taken hold by now. And no one really has. There is Easy Git[4] but I don't know anyone who uses it.

And really, I see git as not much different than Unix in this regard. Unix commands vary widely in their usage. Does knowing awk help with sed? cpio and tar? wget vs curl? Eventually you understand concepts such as pipes, regular expressions, file descriptors, etc and you become familiar with the commands where you are able to apply these concepts, at which point does strict interface consistency between them matter? I dunno, but I started with both git and hg around the same time and ended up happier with git. Mercurial had the "better" CLI, but I found git was better at doing what I wanted. Before that I used clearcase, which has a very consistent CLI and yet I was constantly cursing at it.

Or maybe I just have stockholm syndrome and I'd feel differently if I'd ever used plan 9. :)

1\. [http://tom.preston-werner.com/2009/05/19/the-git- parable.htm...](http://tom.preston-werner.com/2009/05/19/the-git-parable.html)

2\. <http://git-scm.com/book>

3\. <http://newartisans.com/2008/04/git-from-the-bottom-up/>

4\. <http://people.gnome.org/~newren/eg/>

</comment><comment><USER3> Context

\---

Master Git and a novice API developer stood together in a crowded office.

"I am trying to merge two massive XML files," explained the API developer, "and I am getting many tedious conflicts. You must have a strategy for making the lines match up in a human-readable manner. What is my best option?"

"Patience," said Master Git, turning away from the monitor.

"But I have been manually resolving for hours!" protested the API developer. "My mergetool ought to be able to imply context and match lines properly!"

Master Git sighed and left the room without a word. Hours later, he returned to find the office empty and silent. Only the API developer remained, his head bowed in defeat before the monitor.

"git merge --strategy-option=patience," whispered Master Git.

Upon hearing the same word in explicit context, the novice was enlightened.

<comment><USER4> Create a pull request to <https://bitbucket.org/sjl/stevelosh>

</comment></comment><comment><USER5> Sometimes I feel like Git is an elaborate troll by Torvalds. Doing my taxes is more intuitive.

<comment><USER6> Wanna trade? I'll do your git if you do my taxes?

<comment><USER7> I think you're on to something, there. If only I could manage my taxes with git...

</comment></comment></comment><comment><USER8> The 'Only the Gods' one seems weird to me; maybe I just don't understand Git well enough, but it seems like that one's just a case of failing to understand what a branch _is_.

A particular commit isn't made 'on' a branch, so to speak; it's just a SHA hash that has a particular SHA as a parent. And then a branch is a pointer to a particular SHA. So there's no way to know which branch a commit originated 'on', merely which branches happen to contain a commit at present (because their current commit has the desired commit in its history).

So, if you merge two branches together, of course you can not tell which branch a given commit originated on just by looking at history. That information was never in the history in the first place.

I could see it being useful to track this in the merge somehow, though.

<comment><USER9> What you described is how _git_ thinks of branches.

Most developers think of branches as something they commit to. Therefore they are surprised when later they can't tell which branch they committed to.

This could trivially be fixed with porcelain that puts the name of the branch the commit was made to at the end of the commit message.

The issue of branches not really being branches is not unique to git; most VCs I've ever used have had significant differences between what you would think of as a branch and actual branches (SVN doesn't even have branches, except as a convention).

<comment><USER10> Git is predicated on the notion that it's actually quite simple and elegant how Git works, and programmers are clever enough to understand how their software works, so not much porcelain is necessary. There's a refreshing honesty to that.

<comment><USER9> That's not my understanding of it's history; it was originally planned to have, potentially, multiple porcelains, but that idea died of a couple years back.

<comment><USER11> I believe that is the root problem of git. Originally, the assumption was: porcelains will provide a nice UI, so core git can leak implementation details. However, it turns out the implementation details are so simple and intuitive for many developers that core git is now the dominant UI.

For example, the multiple use cases of 'checkout' or 'reset' are quite intuitive, if you have the implementation in mind.

</comment></comment></comment></comment></comment><comment><USER12> Short of me downing distressing amounts of coffee, could someone explain these please for those of us still trying to grok git?

<comment><USER13> I'm not sure what Silence is about. My git-config-fu fails me.

One Thing Well demonstrates how one command (git checkout), while it does do 'one thing well' (changing your working directory to match something in the index), can handle a wide variety of seemingly unrelated use cases.

Only the Gods demonstrates how history can mean different things: commit parentage, which is usually immutable, and branch history, which is ephemeral.

The Hobgoblin probably refers to the Emerson quote "A foolish consistency is the hobgoblin of little minds."

The Long and the Short of It is about how git accepts `git --help command`, `git command --help`, and `git command -h` but `git -h command` returns an argument error.

A theme here is that git does not try to anticipate your workflow. Its commands and options are named based on what they do, rather than how you should probably use them. This makes git a very powerful tool, but with an interface that is often counter-intuitive.

<comment><USER14> Each git command is a designed tool itself. Others expect it to be 'git' to be the wholly designed tool as one unit, but it's a toolbox.

</comment></comment></comment><comment><USER15> A lot of these are just plain wrong though or have a good reason and it makes me sad because I know Steve Losh uses a lot of Mercurial which I think has a much worse UI.

1\. Silence: you can't alias built-in commands — for good reason. You don't change the defaults of commands, that's just going to cause problems with scripts. Why is it ignored silently? For starters because new git versions can add a command that would conflict with your config that came from an older version. You can trivially see that an alias is ignored by just adding ``--help`` to the command and it won't show you the alias.

2\. One Thing Well: I fail to see the problem with that? All of these do the same thing. They check out a revision. With the exception of branch creation which is actually not a feature of `git checkout` but `git branch`. There is just a convenience operation on `git checkout` that also changes branches. The better question is why branches in mercurial are called bookmarks :P

3\. Only the Gods: thankfully you don't know which branch something came from. Mercurial fucked me over more than once where I accidentally pulled a patch that came from a named branch that was conflicting with one I already had (you would not believe how many people name their branches "bugfix"). Mercurial's named branches are among the stupidest idea in software maintenance.

4\. The Hobgoblin: these are all different commands. "How can I view a list of all tags": that's not what all tags is, that is "what's the list of tags I know locally". In mercurial you can't even figure that out properly because depending on the branch you're on you get different defined tags since tags are stored in the tree. Git's tag system is much superior to that.

"How can I view a list of all branches": that's a question you will never ask because it's the wrong question. A branch could show up multiple times. The correct question to ask is "How can I view a list of all local branches?" `git branch`, the second question is "how can I view a list of all remote branches?" And for that the answer is `git branch -r` or `git branch --remote` which makes a lot of sense in my mind.

"And how can I view the current branch": Same way you show all branches, just `git branch`. Shows you your current branch as well as all other branches and neatly colorizes it. `git rev-parse` is a command you really never have to use unless you script something.

Yeah, some could probably more consistent. The odd one out are `git submodule` and `git remote` which are sub commands instead of using parameters to remove/modify them. That being said, you rarely need to use those.

In direct comparison with hg, git's UI and functionality is a present from god. I'm pretty sure hg only has a better UI reputation because git's UI used to be pretty bad. Now however? Pretty sure it wins over hg hands down.

<comment><USER16> 1\. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? That's better than telling you "hey this isn't going to do what you think any more"? Do you have `try: foo except: pass` in your Python code too? Come on. There's no reason git shouldn't at _least_ warn you on stderr here.

2\. `git checkout -- somefile.py` does not have anything to do with checking out a revision. It changes a file's contents, but doesn't change the parent of your working tree at all. Unlike `git checkout -b` which is inconsistent for convenience like you mentioned, the "make file x look like it was in rev y" function here is unique to git checkout as far as I can tell. Then again this _is_ git, so there's probably at least four other ways to do this with cryptic plumbing commands.

3\. I like Mercurial's named branches because I don't need to create a branch for every single commit. But even if you don't like them, the "record which branch X was made on" and "use that recorded information to group branches and such in the UI" are two different things. The second requires the first, but git _could_ record which branch was checked out when each commit was made as some metadata in the commit, instead of dropping it on the floor. It would be a godsend when trying to figure out what actually happened during a merge.

4\. `git branch` doesn't show you the current branch. It shows you all the local branches, with colors and padding spaces and asterisks and crap. What if you want the current branch in your prompt? Or just want to grab it in a script? Your choices are "pipe to grep and sed" or "use this ugly-ass rev- parse thing" instead of "git branch --current".

Git's UI is still abysmal. Mercurial preserves more data (branches), gives you the same power as Git and has a UI where "--help x", "-h x", "help x", "x -h", and "x --help" all do the same thing (pop quiz: how many different things does git do for those? hint: it's more than two).

<comment><USER15> > 1\. If a new version of git adds a command that shadows one of your aliases, > you'd really prefer "git foo" to silently run the new command?

Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea.

> `git checkout -- somefile.py` does not have anything to do with checking out > a revision.

Of course not. `git checkout` checks out things. You can check out a lot of things. Just because it works differently in hg does not mean it's wrong in git. git checkout does what it says on the tin: it checks out a branch or paths to the working tree.

> I like Mercurial's named branches because I don't need to create a branch > for every single commit.

I think the concept of named branches in mercurial are hugely flawed and were the final nail in the coffin of why I migrated over to git. And I never looked back.

> What if you want the current branch in your prompt?

Then you use the underlying low-level commands or even better, you cat `.git/HEAD` which will be even faster. Not sure why for your prompt to look nice you need to have non-cryptic commands. Exactly for things like prompts there is the plumbing.

> gives you the same power as Git and has a UI where "--help x", "-h x", "help > x", "x -h", and "x --help" all do the same thing

How is this different from mercurial? If anything mercurial has even more ways to show help: `man hg` which shows the manpage for _all the builtin commands_. `hg help` which shows a short version or `hg -v help` which shows a long version (which is not the man page). git only has two help pages: man pages for long and short text for short.

> gives you the same power as Git

I have yet to see this.

<comment><USER17> _> Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea._

You should understand what you are responding to before typing your answer.

Say today I create an alias "boom = <whatever>" and next week git introduces a boom command.

Now my alias is ignored, my scripts are broken and I might destroy my working copy or kill my cat by using it without knowing it now means something else.

Git gives some very stupid hints "branhc is not a git command, did you mean branch?" it should also warn me when I defined an invalid alias.

Maybe that alias was valid two versions ago or I just don't know that command exists, since there are eleventy thousand of them.

<comment><USER15> > Now my alias is ignored, my scripts are broken and I might destroy my > working copy or kill my cat by using it without knowing it now means > something else.

Your scripts should not rely on aliases you have in your config. Scripts are intended to be used by different people.

<comment><USER17> I decide who is intended to use my scripts, thank you. I have many scripts where I am the only user.

Also, the issue of having an alias changing behavior without warning on my command line still exists.

</comment></comment></comment></comment></comment></comment><comment><USER18> One Thing Well: The command of all these seemingly different action is the same, because all of these seemingly different actions are actually the same.

The Long and the Short of It: -h is not a valid argument. Passing -h therefore results in providing usage information.

</comment><comment><USER19> Has anyone made an alternative interface for git that tidies this up without drastically changing how you use git? Or would this condemn someone's sanity to the graveyard?

<comment><USER20> Mercurial is essentially git with a clean interface and drastically fewer workflows. If it weren't for github's existence I'd recommend hg to anyone.

That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway.

<comment><USER15> > That said hg is the better choice for big software shops IMO, because of the > lower training cost and because they probably won't use github anyway.

Considering more people know git I would assume the training cost for hg is higher.

<comment><USER9> More people _use_ git; I'm becoming increasingly convinced that few of them actually know git.

<comment><USER15> > More people use git; I'm becoming increasingly convinced that few of them > actually know git.

And yet I have noticed that people find merging and branching much easier than in mercurial. Few people understand the implications of named branches in hg.

<comment><USER9> Yeah, named branches in hg are just weird.

<comment><USER21> Not as weird as hijacking the term "branch" to mean a symlink to a ref that is not part of the history. Then again why make it easier by naming it to something more intuitive, like say, "bookmark".

<comment><USER11> Because a bookmark is usually immutable. If I bookmark "<http://news.ycombinator.com> has "Hacker News" it will be same URL forever.

In contrast, git branches symlink to a different ref, whenever you commit to it.

A git tag could be called bookmark intuitively.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> I don't use a complicated .gitconfig (just user.name and user.email), so this is all new to me.

Something that leaps out to me as horribly wrong is that aliasing a builtin doesn't cause the config file to be "invalid". Doing anything else is just doing spooky things that are explained only several hundred lines into the man page by a single sentence.

Maybe better would be to choke on config lines that alias a builtin, and to print error messages before or after the output of each git command while the offending line(s) are present.

Further,

      git config alias.pull "pull --ff-only"

should definitely be an error. Instead, git gladly makes the (no-op) confusing edit to your config file.

</comment><comment><USER23> 'git' alone tells me to 'git help <command>' for help, which I've done dutifully ever since. That is, until I too was enlightened a few minutes ago with 'git <command> -h'.

Thanks, Master Git!

</comment><comment><USER24> Even if this was meant as an critique to Git, I (some kind of a Git- evangelist) enjoyed it a lot. I even learned something new!

The critique is quite well established. One needs to understand these quirks to be an enlightened Git user.

However we make up with them, as the overall gain from Git's approach to version control is so big.

Some things could be improved though, like introduce something like "git branch --current" to avoid the Hobgoblin...

</comment><comment><USER25> I don't understood the suicidal git thing...

Also of course I had to test the help commands!

git branch --help opens man

git branch -h throws those short commandline help summaries.

Interestingly, -h does not mention -h itself or --help, so the only way to know that --help exists, is someone else telling you, you will never find on your own.

<comment><USER26> -h is not a valid option. You could put --floogahbar in there and it'll give you the help by way of response.

<comment><USER27> Actually, "-h" is not a valid option on "git", but it is on "git branch" (somewhat confusingly). Try "git branch -j" to see what happens when you pass a bad option. In particular, try that when your cwd isn't a git repository.

</comment></comment></comment><comment><USER28> The best part of this article IMO is the scrolling header on the left hand. Nice touch.

<comment><USER29> Really annoying on an iPad while zooming in on the text.

</comment></comment><comment><USER30> I'm a relatively new git user. I'm rebasing a log when other developers commit unrelated changes. What is the problem with git rebase?

<comment><USER11> I believe lots of people do not understand that you should treat remote branches differently than local branches. More precisely, you treat remote/global history differently than local history.

Using rebase to clean you local history is ok. Maybe even recommended or mandatory depending on the project. Changing history, which is already in other people's repos, will lead confusion and should really be avoided.</comment></comment>


The BBC is getting back into the computer business - <AUTHOR> http://qz.com/446839/the-bbc-is-getting-back-into-the-computer-business/

<comment><USER2> I was wondering about the cost or pricing, but the answer is they won't say yet. [http://www.bbc.co.uk/news/technology-33427816](http://www.bbc.co.uk/news/technology-33427816)

> The BBC won't give exact figures on the costs - it says they're commercially > sensitive - but says the vast majority is being covered by the partners in > the project.

</comment><comment><USER3> [https://news.ycombinator.com/item?id=9844380](https://news.ycombinator.com/item?id=9844380)</comment>


Interview With Steve Ballmer: Products, Competition, The Road Ahead - <AUTHOR> http://www.techcrunch.com/2009/09/24/microsoft-ballmer-interview-exclusive-techcrunch-bing-mobile-azur/

<comment><USER2> It's always a thrill to listen to Steve Ballmer talk about the company roadmap and it's hard to imagine that anyone could do a better job in that role. The company faces the law of large numbers and an uphill battle against perception (at least on the consumer client side) but the innovation and execution strategy for incumbent slots and catch-up slots is dialed in (as it seems to always have been).

<comment><USER3> sarcasm?

<comment><USER4> I have several friends who work for MS, and from what I see MS's worst enemy is its own handling of the very concept of competition.

Take the iPhone for example - a product that completely trounced Windows Mobile in every way (and continues to do so), despite MS's years of effort in the field.

Response? It's now politically incorrect on MS campus to openly admit to carrying an iPhone. Instead of embracing the competition and figuring out why they're better, MS is too busy burying its head in the sand.

Similarly, I've heard of stories of HR contacting employees for organizing after-hours Wii parties with coworkers. Apparently even _using and enjoying_ your competitors' products is disallowed.

No wonder MS is in the rut they're in. They spent years practically pretending the competition didn't exist, and now they're surprised that they've been left in the dust.

I do sense the winds of change at MS lately though - there is certainly more willingness to admit that the competition is more successful (though still generally non-kosher to admit that they rock). There are certainly real engineering efforts to play catch-up.

But Ballmer is not the right guy to lead this charge - he's the guy who openly admitted that his kids aren't allowed to use iPods or Google. A guy with an ego this large should not be allowed to run a company that is financially and developmentally stagnant amidst a sea of strong competitors.

<comment><USER5> In the video Google is called "the incumbent." Balmer seems like the CEO of yesteryear, when even having competition was a failure.</comment></comment></comment></comment>


America's Other Drug Problem: Copious Prescriptions for Hospitalized Elderly - <AUTHOR> http://khn.org/news/americas-other-drug-problem-copious-prescriptions-for-hospitalized-elderly/ <comment><AUTHOR> _74-year-old Lola Cal... had a long history of health problems, including high blood pressure and respiratory disease. She was in the hospital with pneumonia and had difficulty breathing. Her medical records showed she was on 36 medications._

This would seem easily solvable by software, but electronic medical record systems are too often islands -- without bridges connecting them. So each new specialist she sees doesn't know about all of her prescriptions.</comment>


California judge says driving while using GPS does not violate hands-free law - <AUTHOR> https://casetext.com/case/the-people-v-spriggs

<comment><AUTHOR> Click the flags on the left to jump to the relevant parts of the opinion.</comment>


Ask HN: Should big tech companies be considered monopolies? - <AUTHOR> Facebook, Google, and Apple have immense power.
Together, they're essential to modern life. You really can't live without them.
If Google decides to shut down your gmail account, your life is impacted in a big way.
Apple's app store is responsible for the well being of 10s if not 100s of thousands of businesses.
Facebook controls the majority's perception of the media such that it may have changed the election with fake news stories.
These companies have more power than Bell, Standard Oil, and certainly more than Microsoft had. It's increasingly becoming apparent that they can negatively impact the lives of millions.
What can we do about it? <comment><USER2> At least they're pretty much equivalent in sizes and competing with each other. Imagine if Facebook, Google, Amazon and Apple merge into one big corp. That would be monopoly. There would be no competition at all. But that won't happen, because the government would intervene. So our current situation is somewhat OK.

</comment><comment><USER3> Google has a monopoly on search, Facebook has a monopoly on social media, Microsoft has a monopoly on OS (this is contentious generally but Linux isn't a realistic choice for most people and Apple only releases their OS on special hardware that is way out of the price range for most people). Very few large tech companies seem to have lots of competition over their core business and honestly if it was that competative in the end you probably wouldn't be seeing as much VC money as you have.

</comment><comment><USER4> Yes, they are monopolies. I call them technopolies (see Urban Dictionary definition, the Neil Postman definition is wrong).

They should have already been regulated as monopolies.

But the long term solution is decentralization technologies that will put them out of business. See [https://reddit.com/r/rad_decentralization](https://reddit.com/r/rad_decentralization)

</comment><comment><USER5> Google I understand, but how exactly can you not live without Apple products?

<comment><USER6> Think of all the hundreds of thousands of developers who have put hours and hours into creating livings out of selling items on the app store. You'd be taking away a large amount of peoples living.

<comment><USER7> Are there really hundreds of thousands of developers who make a living out of an app store?

<comment><USER8> Considering that there are ~2 million apps* in both the Play and App stores I would say yes. Also considering for many people in the US their phone is their primary means of accessing the internet it's extremely likely that hundreds of thousands of people (not just devs, business people, designers and community teams as well) rely on the app they work on being in one or both of those stores.

* according to the first result in Google.

</comment></comment></comment></comment><comment><USER9> Don't use their services, be like Richard Stallman</comment>


The Blog Post for People Who Actually Want to Do Shit - <AUTHOR> https://mattkremer.com/the-blog-post-for-people-who-actually-want-to-do-sht/

<comment><USER2> The blog post for "presents no text without javascript enabled."</comment>


Looking at naked pictures makes you smarter - <AUTHOR> http://ca.askmen.com/entertainment/austin_600/696_naked-women.html

<comment><USER2> Waiting for the "I must be a genius" jokes....

</comment><comment><USER3> In that case animals should be smarter than humans!

</comment><comment><USER4> My thought is that perhaps looking at nudes isn't necessarily helpful to the brain function due to sexual titillation but perhaps due to putting the mind more in touch with reality. (Not sure I'm up to explaining what I mean if that doesn't make sense on the face of it.)

(Also: Sorry to the critics, but I've upvoted this. I see no reason why this has to be a mind-in-the-gutter topic.)

</comment><comment><USER5> Ridiculous, inappropriate.

<comment><AUTHOR> Why is it inappropriate?

We're wired to be attracted to certain attributes for certain evolutionary purposes...

<comment><USER5> It is not about how we are wired by evolution. It is about whether or not, according to the guidelines <http://ycombinator.com/newsguidelines.html> this is an acceptable article. I say that it is not. The article is fluff, does not reference any actual scientific research. It says only "Scientists have discovered . . ."

I have flagged this article.

<comment><AUTHOR> The guidelines are suggestions. Not hard rules. But it's your prerogative.</comment></comment></comment></comment>


KDE Plasma 5.16 Released - <AUTHOR> https://dot.kde.org/2019/06/11/plasma-516-kde-now-available <comment><USER2> Nice new features. Using the beta since some days now, I personally enjoy the new notification system a lot.

</comment><comment><USER3> A completely new notification system, enhanced privacy and improved design.

Just reviewed it: [https://www.revyuh.com/2019/06/kde-plasma-5-16-lands- complet...](https://www.revyuh.com/2019/06/kde-plasma-5-16-lands-completely- new-notification-system/)</comment>


Microsoft rules out Yahoo acquisition (again) - <AUTHOR> http://www.theage.com.au/news/technology/biztech/microsoft-ceo-rules-out-yahoo-acquisition/2008/11/07/1225561122459.html <comment><USER2> I think this is a mistake for Microsoft. I think they should have offered $18/share and seen Yahoo's response. At this point, with a down economy and no Google revenues to prop them up, Yahoo might simply spend them selves into bankruptcy before they can turn it around.

And, of course, $18/share is about half of what Microsoft offered less than a year ago. Was Yahoo not a good company to acquire 6 months ago? Saying that you won't buy Yahoo for half the price is admitting that your previous plans were simply wrong.

Has Microsoft decided that Yahoo bankrupt is as good as Yahoo bought? Does Microsoft think they'll be able to buy them even cheaper if they rebuff and wait?

<comment><USER3> I'm not so sure it was a mistake. If you want to put on a tinfoil hat for a minute we could speculate that Microsoft wasn't genuinely interested the first time. That botched acquisition was a media circus and effectively destroyed Yahoo. Since then, consumer and shareholder confidence in both the business and leadership has completely eroded to the point where Yahoo is simply unable to compete effectively. Perhaps that was Microsoft's intent all along. It certainly costs a lot less money than having to win with superior product development.

Even without conspiracy theories and speculation it is impossible to deny that Yahoo is a much different company than it was just six months ago. Top talent has been jumping ship. There have been layoffs. Marketshare and mindshare have been on the decline. Those are all of Yahoo's most valuable assets.

Not only is there now less value in any partnership or acquisition but public perception of such a deal will be much less positive than it would have been before. In fact, it could be seen as very negative. There were already a few naysayers asking why Microsoft would want the Yahoo monkey on its back. Since then, the situation has become much worse. It can no longer be perceived as two worthy competitors to Google forming an alliance to create something great. Now, it's more like Yahoo is having a going out of business sale. The point was to display strength and now it appears weak.

Microsoft may still acquire Yahoo, but the point I'm trying to make is that it's a different type of deal now and one that would be made for different reasons. I think they're going to weigh their options and not do anything too hasty. It's not like they have to jump on this right away. I don't think anyone else is going to be in a big hurry to buy Yahoo. Even at $18 a share it's a very expensive deal that not many companies can afford.

In the end I think Microsoft probably will end up buying them, but I wouldn't be surprised if it's several months from now. I think the first deal was more about marketshare and public perception than it was about technology. Now that that's no longer a viable strategy they're probably going to want to take a serious look at what they'd be getting for their money. Besides, Microsoft's shareholders need to be convinced it's for the right reasons so it's not such a bad thing if they let things quiet down a bit and then snatch up Yahoo for even less money next year. By then it will appear much more like they're taking advantage of a great deal than betting the farm trying to beat Google.

</comment></comment><comment><USER4> "The user interface on search hasn't changed for six years. You still get the same dull, boring ten blue links for God's sake. Can't we do any better than that?"

No, this is the perfect UI for search. What results are found could be better sometimes, but how they're presented is pretty close to optimal, IMO.

</comment><comment><USER5> smart move by ballmer. he either lets YHOO drop to $8 and then makes an offer for $13 (after making yang do massive layoffs), or he just lets yahoo shrink into irrelevance and then positions msn to (try) to take marketshare. either way ballmer wins.

with the google deal dead and no obvious offer from ballmer, jerry is dead in the water</comment>


Open Source Webhook Server - <AUTHOR> https://github.com/adnanh/webhook <comment><USER2> I have been using this webhook server in prod for a few years and its been easy to setup/maintain ... you just define github.com repo to publish `git push` or whatever then this webhook server listens to every git push my team makes to launch a code recompile/redeploy ... foolproof and solid ... I highly recommend

</comment><comment> m-p-3 Interesting, could be useful to interface some of my stuff with IFTTT or Integromat.

<comment><USER3> That's basically what I did. I had a few things running in IFTTT and Microsoft flow, but both have pretty big limitations.

Moved everything across to webhook, which is running powershell scripts in the backend.

Makes it a lot easier for testing that things are working properly too.

</comment></comment><comment><USER4> CGI will never die!</comment>


China Telecom diverted internet traffic in U.S. and Canada, report finds - <AUTHOR> https://www.theglobeandmail.com/politics/article-china-telecom-hijacked-internet-traffic-in-us-and-canada-report/ <comment><USER2> Schneier's post on it.

[https://www.schneier.com/blog/archives/2018/10/chinas_hackin...](https://www.schneier.com/blog/archives/2018/10/chinas_hacking_.html)

</comment><comment><USER3> I used to work at Nortel Networks along with 130,000 other people. Nortel went bankrupt and now everyone who used to work there is fighting for their pensions. Apparently a major contributor to their downfall was all of the IP being stolen and sensitive information about deals going down otherwise exfiltrated by Huawei[1]

People need to get serious about protecting the privacy of their communications and data. Nobody cares until it is too late. Seems like this kind of event might be the incentive people need to make the extra effort to use products that encrypt their data in rest and in motion.

1: [https://www.afr.com/technology/web/security/how-chinese- hack...](https://www.afr.com/technology/web/security/how-chinese-hacking- felled-telecommunication-giant-nortel-20140526-iux6a)

</comment><comment><USER4> The BGP protocol (decentralized without proof or verification), the DNS system (centralized AND decentralized without proof or verification), and SSL (decentralized without proof or verification) are all relics of the past - design choices that didn't predict this future.

BGP, SSL, and DNS, create an atmosphere ripe for hijack, MITM and other nefarious activity, and it happens ALL THE TIME.

In other words, the very system "designed to provide trust" actually is also designed to allow rogue actors to utilize that same trust.

It's insecure AF.

<comment><USER5> Certificates in the Web PKI ("SSL Certificates") are logged to the Certificate Transparency system.

Clients can choose to insist upon seeing proof that the certificates they're shown were logged (SCTs), Google's Chrome browser does this today.

Name owners can choose to check which certificates were logged for their names, either by operating their own log monitor or by having somebody else do it for them (Facebook will do this for free, but you're welcome to pay somebody if you don't like Facebook, or as I said, you can do it all yourself since the logs are public).

In practice even though the existing system is far from perfect we see relatively few problems, and fewer still actual attacks rather than screw-ups.

<comment><USER6> certificate transparency only does anything for participating CAs, there are dozens/hundreds of CAs that do not participate in certificate transparency, including several either controlled by the Chinese government, or at less than arms length from its influence.

They can freely sign anything that isn't either certificate pinned, or has a CAA record. And both those things are client dependent, pretty much any ssl client besides chrome or firefox will not have the capability to do either.

</comment></comment></comment><comment><USER7> Dupe:

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

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

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

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

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

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

<comment><USER8> Only one of those (the first link) would have had enough votes to reach the front page. In sequential order, those links presently have (118, 2, 5, 7, 3, 2 [dead]) upvotes.

This submission was the first I've seen of the story.

<comment><USER9> Right, on HN an article only counts as a dupe if the story has previously had significant attention. [https://news.ycombinator.com/item?id=18307524](https://news.ycombinator.com/item?id=18307524) did, so this submission does count as a dupe.

</comment></comment></comment><comment><USER10> This report is pretty sketchy. The example is traffic from Canada to South Korea was 'diverted' through China. But there's no undersea cables direct from Canada to South Korea, traffic will go through the United States, and then it must go through at least one of Japan, China, Singapore on the way to South Korea. China Telecom runs a global network, and offers transit, so it's likely that someone on the way was intentionally interconnected with China Telecom and expected some packets to transit its network.

Many companies with diverse home countries run global networks, but it's only an issue when it's a Chinese company?

<comment><USER11> If you read the article closely, it says that traffic was diverted via its PoP on the west coast (presumably in the US). The article isn't saying that there is a cable going out from Canada.

<comment><USER10> The traffic is going from canada to south korea; of course it's going to go through a PoP on the west coast. Of course China Telecom is going to have PoPs on the west coast, as they provide global transit.

If the route is [whatever us transit] -> china telecom -> [whatever connectivity in south korea], the US transit provider is generally going to send the traffic to china telecom on the US side of the undersea cable, then it can use china telecom's provisioned bit of bandwidth.

Here's the quote from the article:

> One such example the authors give is the diverting of routes between Canada > and South Korean government sites. For six months beginning in February, > 2016, internet traffic was diverted by China Telecom and routed through its > PoP in Toronto, then forwarded to its PoP on the West Coast, then on to > China and finally to South Korea. The shortest route for this traffic would > normally have been Toronto to the United States to South Korea, the authors > says.

But there's no cable from US to South Korea listed on the submarine cable map [https://www.submarinecablemap.com/](https://www.submarinecablemap.com/)

And they didn't show any work -- it's not unreasonable to me to go through China instead of Japan, especially since BGP is generally picking routes based on the least number of ASNs in between, rather than shortest distance or anything. Probably China Telecom had a peering or transit arrangement with the destination network (or one of their transit providers), and the other available routes would have had to switch networks one extra time -- or maybe it was even, and the China Telecom session was up longer.

</comment></comment></comment><comment><USER12> dupe

<comment><USER13> If you're going to report as dupe, please provide the link to the previous appearance

<comment><USER14> [https://news.ycombinator.com/item?id=18329518](https://news.ycombinator.com/item?id=18329518)

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

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

<comment><USER15> Looks like all the previous linked threads received fewer votes than this one and no more than two comments. No reason to close this as a dupe, then.

<comment><USER16> Another dupe with lots of comments [https://news.ycombinator.com/item?id=18307524](https://news.ycombinator.com/item?id=18307524)

With so many dupe on a paper which in my personal opinion is poorly written, it looks more like a xenophobia or propaganda attack.

</comment></comment></comment></comment></comment><comment><USER17> So is this anything the US hasn't already done to others or is this actually a scandal?

<comment><USER18> This is whataboutism in an attempt to distract from moral turpitude of Chinese actions with "what about the US?"

It is bad either way.

<comment><USER19> This is the same tired argument that's dragged out anytime people raise concerns about using Chinese hardware.

>I don't care if the Chinese government has my data, I'm not a Chinese citizen

>The US spies as well

>The US did something wrong in the last 100 years, therefore you shouldn't complain that China did it last week

<comment><USER17> No, the question is this:

The US is doing certain things that seem outrageous.

The US is supposedly an ally of my country.

China is not explicitly an ally (just a trade partner).

So if the US spies on us, that's scandalous but it significantly lowers the bar for what I expect our non-allies to do to us.

It's not whataboutism, it's a precedent by which all future actions are measured. I'm not discounting the news story, I'm asking whether this is just a news story that will be forgotten about in a few weeks or so, or whether this is a total shift in expectations like when we found out what the US was doing to its own allies.</comment></comment></comment></comment>