The users kyledlloyd, fletchtastic and emnroth seem to be fake/astroturfy. They have all commented on the exact same posts with meaningless praise that adds nothing to the discussion. For example, "Great article!"
The posts they've commented on link to wearableworldnews.com.
This is not a smart marketing strategy. Please stop.
When heroin was legal, addicts often took it in pill form which was cheap and sufficient to deter cravings. The chief negative long-term effect of being addicted to heroin is constipation...IF you can reliably keep a supply of it in pill form.
The negative effects we see in addicts today are mostly caused by two factors: (1) if you shoot up, needle - especially dirty needles - can be a vector for infection and diseases such as HIV, (2) if you can't get a reliable supply of known potency you can go through withdrawal or overdose - the wild swings are harmful. (Impurities in the drug can also be harmful depending on what it's been "cut" with.)
So if the drug were legal it'd be fine. But when it's illegal, some characteristics of an illegal market make it bad for people - those are problems related to the illegality, not really having much to do with the drug itself.
I read a funny quote somewhere, it basically said that git is a great library for building a DVCS...
Basicailly, I agree with you. What I'd personally like to see more of is an easy way for a company to define a workflow for version control, using git as the underlying mechanism, that fits exactly how they want it to work (think, if the company wants Git Flow, or some other workflow, they define it in my imaginary tool), but for the most part the developers never have to drop down to git to use it. They have an abstraction layer over the top of it.
I saw a paper, gitless, I think it was, that is trying to do something similar but less ambitious. Perhaps in the future we'll see stuff like it. GitHub Desktop and Atlassian Stash also do something similar, but not quite what I'm getting at.
This is a fantastic idea. Even the "nice" git tools like Github's desktop app don't abstract over tracked files and branches and all the confusing git plumbing. It'd be so much better to just be able to click "I'm working on a new feature" and "I'm done with the new feature."
I believe that version control should really get out of your way, and right now, that definitely isn't the case. To me, all the arguments about git's power just sound like "why use Dropbox when you can just sync your files with FTP?"
> It'd be so much better to just be able to click "I'm working on a new feature" and "I'm done with the new feature."
Maybe, but it might instead be better to ask people to invest a small amount of time in learning to use tools that make them more effective at doing their job. "I'm working on a new feature" and "I'm done with the new feature" are, sadly, not actually expressive enough concepts to deal with the problem.
Syncing files with FTP is pretty much at the same conceptual level as "Use Dropbox". Git solves problems significantly more complicated than "I'm working on a new feature / I'm done working on a new feature".
EDIT: when I say "conceptual level", I mean, "what you do with it", not "how easy it is to use". Obviously, Dropbox is more usable than FTP. My claim is that Git provides a much different level of power than "I'm working on a feature/I'm done with a feature", which is not a sufficiently expressive concept to deal with software development.
> Syncing files with FTP is pretty much at the same conceptual level as "Use Dropbox".
I disagree. My mom loves Dropbox -- she just sticks a file in a folder like she always does and it's magically synced. If she were to use FTP, she'd have to set up a server, remember login credentials or find her public key, and grab an FTP client. And not every client supports automatic syncing either, so she might have to manually trigger a sync.
Of course, FTP has way more power and flexibility than Dropbox, just like git vs <proposed VCS>. If your workflow is especially complicated, I'm sure all the git functionality comes in handy and an abstraction would be a hindrance. But most workflows, I'd argue, don't need all the plumbing.
That's the app was trying think of! Cheers :) what I want to see, is a way of building those work flows in sourcetree, and pushing that out to developers. Would be awesome... And I think I might try and hack on it perhaps.
Which part do you dislike? I think the basic idea of (1) Create a new branch (2) Develop your feature and commit (3) merge your changes back to master, those steps are as simple as it can possibly be. So is it that this article recommends rebasing (something you don't need to do) what makes it seem non-simple? Or is it the commands themselves (git doesn't have a great ui)?
So if you e.g. want to abandon the conflict-fixing, and do some things on your branch to make merging easier first, you've got to use a special command, and it's different depending on whether you were merging or rebasing (which is still a great improvement over a year or so ago, when you had to do an incantation like git reset --hard HEAD^). Contrast with svn where abandoning a merge is just a "svn revert" like any other.
Agree 100%. Whenever go beyond the very basic functionality in git I have to think so hard about what I'm doing that I lose flow on my actual development. In most cases I find using git to be more daunting than actually writing code.
Maybe I just don't use it enough. Right now I'm in a job where my git workflow is: pull, (do some work), commit, push.
It seems to me that whenever something security related is published, there is an expectation that it has to be something completely new. Something that was previously thought impossible. It's almost as if software has no value if it doesn't exploit some new bug.
For example, everybody knows that root is allowed to do basically anything on a system. If you write a blog post about a technique that requires root access, the typical reaction is "boring, of course root can do that". Everybody knows it's possible, and therefore it's considered uninteresting.
Why doesn't that same attitude apply to other software development? If I write a new chat app or a new operating system, nobody replies with "boring, of course a computer can do that". Even though everybody already knows it's possible to write an operating system.
It sometimes baffles me why the practical side of software development is often considered trivial just because it begins with a root shell, or in this case, physical access.
> For example, everybody knows that root is allowed to do basically anything on a system. If you write a blog post about a technique that requires root access, the typical reaction is "boring, of course root can do that". Everybody knows it's possible, and therefore it's considered uninteresting.
It's considered uninteresting because typically, the difficult part should be becoming root. The root account is a single point of failure in any security architecture which includes it, so the expectation is that access to it is guarded in such a well-thought fashion that executing code with root privileges is a great feat.
Not that the code you run as root shouldn't be good all by itself -- hiding traces, being difficult to wipe out and so on -- none of which actually applies to the one presented in this article.
But in any case, the fact that, in ten seconds, one is able to do nasty things on a machine which readily exposes unlimited access in about 8 seconds is, at best, an impressive feat of automation.
> Why doesn't that same attitude apply to other software development? If I write a new chat app or a new operating system, nobody replies with "boring, of course a computer can do that".
If you write a new chat app, I'd probably reply with "boring", but a new operating system? No, that's a reasonable feat of technical prowess, even if all it does is boot, expose a minimal shell and multitask a couple of processes with minimal I/O. It's not necessarily impressive, but it does nonetheless allow for an interesting glance in the thought process of another programmer. It also requires a little work -- unlike, say, rooting a machine that basically gives you root prompt on boot.
Just the 1-10 character lowercase alphanumeric rainbow table from freerainbowtables.com is 297 GB. Of course, you can generate rainbow tables with various parameters and tradeoffs so it's not trivial to compare them.
Still, I don't think I've ever had a rainbow table that contained plaintexts longer than 12 characters. Are 30+ length tables common these days?
I THINK(but I am not sure because I didn't look too much) that what is going on is that those balls are moving at high speed by small amounts with css and what wants to be demonstrated is how different browser render floating points pixel values. I think. I might be wrong.
(My use: MBPr, Mavericks, Chrome Dev vs. Firefox 25.0.1)
I'll confirm there is a demonstrable difference between the two browsers, to my eye, being that in Chrome the odd numbers don't animate and in Firefox they do. However, I'd like to add that both are equally smooth and antialiased for me.
I'd also like to point out that Chrome font rendering can be smoothed/"crisped" by using in your CSS: