warbiscuit

As a semi-concrete example, say you have a VCS checkout with 40 edited chunks across 15 files. You want to commit 20 of 40 chunks (spread across 6 of 15 of the files). When you're halfway done, you notice a typo needs correcting in chunk 16, and fix it. You then proceed to commit your selection.

From the command prompt, invoking thg and doing that took me about 18 seconds.

I'm reasonably good on the command line, but I certainly don't see how to beat that time using just the cli. I think saying it's "easy for an advanced user" is a little loaded, but I'm still interested to know how to do that task faster. And if such a cli process could only be done with git, I'd consider switching.

> Doing a simple commit with git is just git commit. What am I missing here? ...

> ... These aren't more complex on the command line, they're just done differently.

The process I outlined was a series of steps which were all part of what I'd consider an average commit (not necessarily "simple"). Invoking `thg ci` I could cherry pick lines, edit files as I'm reviewing the diffs, shelve away others, all within seconds, without shifting context. There isn't a single "flag" to read about which makes typing all those commands out necessarily faster.

Simple commits, I will frequently just do `hg ci` and be done. But if I'm doing a bunch of manipulation, I have click the hunks I want, commit, merge and push, all in much fewer seconds than it would be possible to type the equivalent set of commands.

I consider the overall job "tell the computer what I want, as efficiently as possible". For some specific tasks, a mouse just is a better method than a keyboard. I think it's good for complex multi-purpose tools to offer multiple UIs, allowing the user to get work done using the most efficient method tailored to their specific task at hand.

That said, I think having them based on the CLI, and using it to trigger a gui, is a far superior meta flow than having a gui trigger a cli just never seems to work out.

I think different tasks are (more) suitable to different interfaces.

CLIs are great when the space of actions you could perform is large (to nigh uncountable), but the range of subjects is small (the file paths, etc are known). Since you know the subjects, a programming language like `sh` is the most concise way to express a complex action.

GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...).

Many complex tools like VCSes contain both kinds of situations. I think sometimes a CLI is more appropriate, and sometimes a GUI is, depending on the context. IMO a fully mature VCS should make it as easy to invoke a gui for complex tasks as it is to do them from the command line.

I'd disagree with a number of assumptions in that statement.

For one, TortoiseHg isn't windows only. It's a python+qt based application that works uniformly pretty much everywhere.

That fact that you made that assumption makes me thing you may not have explored many alternatives. I'd recommend trying out some other VCSes, just to get a broader picture of how they function. I think doing that helps to get a grip on what your specific needs actually are, as well as a better understanding of the tradeoffs for whatever tool you pick. None of them I've seen are 100% superior.

Secondly, I love tortoisehg specifically because of the command line. Doing a simple commit with mercurial just takes `hg ci`. Doing a commit using the gui just takes `thg ci`. The latter one pops up a gui for me to stage the commit, and then I'm back in the console again.

IMO it's the best of both worlds -- I don't have to get knocked out of the commandline until I need to, and I can trigger whatever gui action explicitly, as part of my existing workflow.

There are some things which I think are just fundamentally better with a gui -- whether it's a curses-style "TUI", or proper graphics. Under tortoisehg, if I'm cherry picking for a commit, I can double click to open up a file in meld to make last-minute edits, shelve bits away for later, all kinds of one-off actions which are much more complex from the command line. Not to mention performing complex searches on VCS history.

It's a lack of an equivalently powerful cli-controlled gui for git which has kept me using hg as my primary vcs.

Honestly, I'm in the exact opposite camp - I'm glad mercurial is still alive and kicking, since I've found my experience with it (and tortoisehg) to be superior in a number of ways. Fewer cross platform issues, a much cleaner commandline interface, can hop over to a much more powerful gui if needed -- I generally use it even when I'm interacting with a git repo.

That said, I'm far from an expert in git. What do you see as it's advantages? (outside of the larger mindshare, obviously :)

One phrase I really liked was "success is preparedness plus opportunity". In that case, the equation would be...

prepareness = idea * execution * product * team * money

opportunity = connections * random-chance

success = preparedness * opportunity

Yeah. I've just taken to ignoring those responses.

As far as I'm concerned, jQuery & lodash are part of the "standard library". Certainly there are cases where one or the other isn't needed for a particularly application. But if you're doing anything with the DOM, or doing anything more complex than simple if/then callbacks, you're either using them or you're reimplementing them bit by bit.

Certainly jquery has some... warts... but I haven't seen any project emerge that's succeeded at being a cleaned up replacement. And jquery 3.0 looks like it's trying to forge ahead in that direction itself.

(Still hate jquery's inconsistent ajax callback signatures. sigh.)

Aside from all the other technical bits, one killer feature for my company is TortoiseHG (http://tortoisehg.bitbucket.org/). Unlike a number of the other Tortoise-* projects (which don't seem related actually), TortoiseHG is a really great cross-platform gui, written in python & qt -- runs just about everywhere, and makes working with mercurial uniformly easy.

The fact that instead of "hg ci" I can type "thg ci" and get a commit window with cherry-picking and meld integration right off the bat is really powerful. I've not seen any good git guis that come close to it's featureset.

I think this is a youtube upload of one of the animations from http://www.hpdz.net/ -- there's a ton others on there too.

They go into the techniques a bit on the site under the "technical" section.

Not to mention "what's the best <X> library" can frequently be answered in an objective fashion, if the answers give a breakdown of why.

Things like "lib A requires excessive boilerplate compared to lib B, see example", or "lib A can't be installed under the following platforms", etc. What should be voted down on those types of questions isn't the question, but poor answers.

It's really frustrating, because getting the opinion of experts who have tried a bunch of alternatives, and know the pros and cons that matter, is exactly why I go to SO frequently.

Not sure I understand the purpose of a MAC in this case. What benefit does it provide to hash storage? If the attacker has write access to your database to tamper with the hash, they will mostly likely also be able to sign up as a user, and clone that (properly signed + encrypted) hash over to whichever account they want to log into. When cracking the hash, they'll just ignore the MAC.

I agree, but it's actually hard not to nerf scrypt, since it's time-cost and memory-cost are tied together. I'm not sure if they could have increased the memory cost sufficiently for their purposes, without making the time cost prohibitively high.

That's one of the things argon2 (https://github.com/P-H-C/phc-winner-argon2) is trying to fix, though I don't think any cryptocurrencies are using it yet (which is reasonable, it's just too young)

They weren't down for the entire two weeks, but various datacenters went up and down for hours, then quieted down for a few days, then was back again, then another hit; stretching across two weeks.

One thing that took them so long was that their upstream ISPs at some of the datacenters were themselves unable to handle the DDOS, so they had to switch ISPs, which took a while.

I don't see Google/AWS as easy to attack; but I'm not sure why similar tier players like DigitalOcean aren't being hit -- or maybe they're just less transparent about things, or are actually a smaller target (didn't think they were?).

edit: here's a postmortem from linode of the christmas attack - https://blog.linode.com/2016/01/29/christmas-ddos-retrospect...

The XEN update was a scheduled thing -- I got an email about it weeks ago (had one linode I hadn't moved to KVM), and it was already scheduled for this weekend.

That said, I don't disagree that the attackers might be trying to distract the team while they exploit that... though I don't see what it gets them compared to quietly exploiting the XEN issues before they were common knowledge on 9/8.

Though annoyingly it's signed using sha1, not sha256.

So if they were gonna put effort into making an sha1 collision, they'd probably target the signed payload, not the overall exe.

Though it doesn't look like sha1 is that broken yet, for the budget of this grade of attacker.

This comment (http://www.classicshell.net/forum/viewtopic.php?p=27961&sid=...) on the forum thread posted md5/sha1 checksums of clean & infected 4.3.0 installers (though it's not clear if those are only infected checksums).

   ClassicShellSetup_4_3_0_clean.exe
   MD5: e10881b65c27c6e09e5a33cd8bcd99c6
   SHA1: a6b06d07fe3b1a7204b1b62c67fbf3c602385364
   File size: 7220496 bytes

   ClassicShellSetup_4_3_0_infected.exe
   MD5: c67dff7c65792e6ea24aa748f34b9232
   SHA1: 438b6fa7d5a2c7ca49837f403bcbb73c14d46a3e
   File size: 7148732 bytes

Thanks, corrected that. Shows what I get for transcribing wrong :)

Yeah, windows is kinda crazy inconsistent for some of these. I had a file (created under Linux) which ended in a space... drove windows nuts. Could list it, open it in some programs, but couldn't even open/rename by shortname under DOS or python.

This is cribbing from source of a filename sanitizer in one of my company's internal libraries. The function is a little... paranoid... so I'm not positive all of these are actually forbidden.

/ and 0x00 for unix

:?"<>/|\* and chars 0x00 .. 0x31 for windows

'~!#$&%^; if there's a chance of filename being passed to shell w/o proper escaping.

Windows also forbids a bunch of filenames matching regex "CON|AUX|PRN|NUL|COM[1-9]|LPT[1-9]"

Also, ending filenames with space or period really messes up windows. File explorer can see it, but can't delete or rename it.

edit: fixed markup

I hope DOM access comes very close on the heels of the initial design...

Javascript is an interesting language (particularly after it's recent revival), but IMO it's recent jumpstart would never have happened if it weren't for one killer feature: access to the HTML DOM. People would (and have) forgiven many other things, just for the utility of that as the presentation layer.

I certainly would have picked up whatever language the browsers were pushing, where DOM access was a requirement.

Conversely, I remember trying to get java applets to interact with HTML -- you have to message things through a tiny hole to/from javascript; which was (one of the many) things which made everyone hate java applets.

The key bit is that it (sounds like) they use it only for identification, whereas the SSN in the US is treated as a "secret" which can be used for authentication (!?). Thus a weird legal limbo where it's officially not supposed to be shared around, as it can prove who you are... yet all kinds of businesses are required to record it to identify their employees :|

I'm not meaning when the comprehension is invoked, but during each iteration of the loop within the comprehension.

When doing something like `map(lambda x: 2+x, range(100))`, there will be 101 frames created: the outer frame, and 100 for each invocation of the lambda.

Whereas `[2+x for x in range(100)]` will only create 2: one for the outer frame, and one for the comprehension.

I'm not positive, but I think it saves the need to create a new execution frame for each lambda call, since the whole loop executes in single frame used by the comprehension.

In theory I suppose the VM could have a map() implementation which opportunistically extracts the code from a lambda and inlines them when possible; but doubt CPython does that. OTOH, I'd be surprised if PyPy doesn't do something like that.

Yeah, I was saddened by them abadoning Persona. It was a really great idea, even if there were some flaws related to how one was supposed to change username if you shift emails. I feel like they never gave it the effort it deserved... never even saw a FF addon providing the browser integration they targeting :(

I'm worried I might have to move off of hg eventually. But just can't get over all those points .. and also TortoiseHg, for which there doesn't seem to be even remotely as good an equivalent in the git ecosystem. It's kind of frustrating. I end up cloning git projects using hg-git plugin just so I can use it to search the repo history.

Not just on par, for those of us who want reliable cross platform behavior and gui tools (TortoiseHg), git seems lacking compared to mercurial.

Github is pretty shiny and popular though :|

and per part of a subsequent announcement from linode, "Multiple Federal law enforcement authorities are also investigating and have cases open" - http://status.linode.com/incidents/ghdlhfnfngnh

Except that they went and made .format() useless for bytes... which made everyone have to hang on to % for both 2/3 compatibility cases, and for all the cases where bytes templates were actually needed (all kinda of lowlevel wire protocols and file storage formats).

I think java apps failed to achieve more mainly because they didn't have decent access to the DOM, and the HTML rendering engine that goes with it.

IMHO that's the killer app of the browser... for all it's faults, the HTML+CSS rendering engine is a superior UI description api than anything previously devised.

I remember the brief period I wrote some java apps. The main pain was choosing between rendering a native java gui, or establishing hooks to have it instrument an html interface from behind the scenes. The native gui had better connection to the code... whereas using the DOM was insanely flexible, but talking to the DOM was like trying to drive a car by reaching through the tailpipe.

That I think is why java apps never prospered (outside of the whole "loading" issue... which could have been optimized away if the motivation was there).

---

JS currently has the best of both worlds, and not because of anything native to the language (though it does have many positive points).

I feel like WebAssembly, and things like PyPy.js, are a step in the right direction. Making the DOM and HTML+CSS just another ui library available to the language of the moment. Having PyPy.js is great, because (I assume) where PyPy's python goes, all the other pypy interpreters (Hippy, etc) can follow.

For me, running their sample script using the PyPy JIT resulted in a 12x speedup compared to cpython.

Though that still wasn't as fast as gcc on my system (core i5 3.4ghz; using 1e8 rounds):

* cpython 2.7.4 - 1.131s

* pypy 2.6.0 - 0.090s

* gcc w/ "-O2" - 0.050s

IMO...

For opensource applications, they're seeking widespread user adoption. To that end, they want to keep users & developers focused on a single project & codebase. Releasing under a license like the GPL ensures they can easily incorporate features from any knockoffs/forks... which pretty well ensures there won't be any longterm knockoffs/forks (unless the project is mismanaged).

GPL isn't so great for opensource libraries though. They don't care about users, they want widespread adoption by developers and their applications. Since applications may have all kinds of licensing requirements of their own (many of which can't mix with GPL), licensing a library under the GPL automatically limits the library's potential adoption.

Which is why LGPL makes a lot more sense for a library. It allows incorporation of forks, but at the same time allows widespread adoption of the library.

Of course, the BSD license almost makes great sense for a library, but mainly for ones which have little expectation that there will be significant enhancements made under closed-source forks; or ones whose purpose is to contribute a basic reference implementation for the greater good.

E.g. a BSD license works well for something like a reference PNG decoder, to encourage adoption of the format; but less sense for something like ffmpeg, where the project's survival depends on garnering as many contributions as possible from a limited base of coders (experts in the intricacies of video codecs).

Thus I think it's less hate, and more frustration that by using the wrong license, the project has hobbled itself at the start, which clack of contributor interest before the project even gets off the ground... and folks would like to see something (like) this succeed.