Selling a minority stake to outside investors is a good way to capitalize the company and give it the resources it needs to grow. Reddit has been notoriously resource-starved. A few hundred million dollars in a partial equity sale fixes that without draining Conde Nast.
I've been fiddling with Canvas for a while and yeah, it does get boring. But other people continue to use it so it must have some entertainment value. Just not for me, or for you.
What I think Canvas lacks compared to 4chan's imageboards is actual discussion. I'm a regular 4channer and have been for years. Canvas emphasizes images at the expense of text posts. What I like about 4chan is the often amusing, roaming, and dare I say occasionally insightful conversations that take place. If 4chan is like a comic book, Canvas is just a stream of funny pictures. Not my thing, but could be fun for others.
> What I think Canvas lacks compared to 4chan's imageboards is actual discussion. I'm a regular 4channer and have been for years. Canvas emphasizes images at the expense of text posts. What I like about 4chan is the often amusing, roaming, and dare I say occasionally insightful conversations that take place. If 4chan is like a comic book, Canvas is just a stream of funny pictures. Not my thing, but could be fun for others.
Agree completely. It's something we're working on.
Idea: have a keypress+click for attaching stickers - so Q+LMB¹ would be smile, W+LMB would be awful, E+LMB would be classy, etc., you have 3 blocks of 9 keys on a QWERTY keyboard allowing 27 different sticker types to be added in this way.
I realise one could make more blocks or size them larger (eg 1+LMB, 2+LMB) but I think the visual match of 3x3 blocks and the hand-eye-coordination works better this way.
It's down to how you work, who you're working with, and the processes you have in place.
My personal motto is just "don't break the build". It seems messy to me to create a ton of branches with broken stuff on them, having to remember the state of everything, what's been merged, what hasn't. I'd rather just write code to a single trunk. If I need to do big arch changes, I do them in bits that don't break the build.
Time is linear. So is my trunk. I develop linearly. I don't think in branches.
I can totally understand that other people see things a different way, and prefer to work like that. But I cannot. I tried. It was awful, painful and a waste of time.
So enough with the "This is better than this" mentality :)
Well, first, one of the points of branches is "don't break the build" since you always know that master is an appropriately tested version of the code. Branches give you feature isolation.
Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it.
But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug.
So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code.
If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready.
Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased.
So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?
As I say, I've worked in a team where branching was tried. It was a hinderance and slowed down development. I've never seen the point of branching for my own personal use.
Others may have different experiences, especially if they work on large teams.
The only reason I can see to "branch" is when you deploy code, make a copy of it in the repos, so that you can fix any bugs off it quickly.
As I say, branching is not something that a "team" does. Branches in git are not something that are published, in nearly every case. Branches are not something like "the dev branch" and "the stable branch". If you are referring to that, in your vague and nonspecifc way, then we are talking about different things.
Branches are feature isolation. For every different feature you add or bug you fix, you, personally and locally, create a branch to do so. If you think that is a lot of branches, you simply don't have the appropriate mental model. If you continue to think of a branch as "making a copy of it in the repos" (what does that even mean??) then, it's... just not the appropriate way to think about it.
Anyway, I'm not going to continue to have this conversation, since it's just not worth it. I just hope I don't have to work for a company that thinks that "branching is bad", but at least if I do they will never know that I am actually using features of my version control system (gasp!).
Works when its just you and friends, and you talk a lot, and are working on the same project and release schedule.
Change any of that, and you need a better technique.
There are lots of different ones, and switching between them is a mind-bend, so folks gripe a lot. But you'll likely have to learn one sometime, probably sooner than you'd like.
Please don't be the guy that gripes and drags his heels. There are legitimate reasons to need source control. Your personal convenience is one of the decision factors, but a very minor one.
I think there are some features where SVN is superior to Git (dealing with large binary files?) but I think you could basically use Git in the fashion you describe, and it would be a better experience than SVN. Just being able to quickly checkout old versions without touching the network is awesome.
On the other hand, as soon as you bring a bunch of people working on a project together, isn't the development inherently non-linear, and there's the possibility that you will need to deal with (implicit) branches? I guess if every person committed to the trunk frequently you wouldn't need to.
> So enough with the "This is better than this" mentality
I understand the sentiment, and the desire to avoid flamewars and endless bitching about tools, but no thanks. If I never have to deal with CVS telling me that every single file in my tree has a conflict in it again, I will be very pleased. If no one had a "This is better than this" mentality, we might not even have the choice of Git (or even SVN for that matter).
SVN is better than git for ANY binary files, really, because with no centralized repository it's rather hard for git to implement any kind of locking. Locking is pretty much essential for binary files, since most are not mergeable in any meaningful way. It's literally NO USE AT ALL to be forced to make somebody redo their recent work when there's a conflict :)
SVN's locking ain't so amazing, it must be said, because it's clearly not the way it's intended to work. But it's better than nothing, certainly, and TortoiseSVN on Windows has some nice features that make it work fairly well.
Another issue is the filling of your hard drive with crap - obviously git keeps the entire repository locally, and SVN keeps a previous revision (I think?), which is a bit useless for enormous hundreds-of-gigabytes repositories mostly filled with stuff that's not significantly further compressible. To add insult to injury, git then spits in your face by not letting you retrieve only part of the repository! - well, obviously the problem is that git just isn't designed for this kind of thing, not that its decisions are unreasonable. Shame, though... some kind of binaries-and-locking support would be nice. It would be great to be able to use git for everything.
You can create a git repository that has other git repositories in it (submodules) but you can't checkout an arbitrary subtree of a git repository. I spent a long amount of time searching for this, so I know.
Now, people have written scripts that will convert a directory to a git submodule by moving history around and stuff like that, but you need to check out the whole repository first.
Your last point is a good one, but it's sort of like arguing over gentoo/ubuntu/centOS. At the end of the day who really cares - none of them are windows, so they're all good enough.
That would make sense if we were talking about Git/Mercurial/Darcs/Bazaar opposite SVN, but in the context of SVN and Git, not so much. SVN is much, much closer to CVS than to Git.
Really? If Chrome's had updates pushed to it recently, how do I know that my browser itself, as installed on my filesystem, isn't now innately subverted by the Iranian government? (Note the domain in question in this particular case.)
I don't know about Chrome's update process, but they can simply have their own verification without root certificates (i.e. just like what most Mac software with Sparkle updater do: keep a public key inside the app, and verify the signature of updates).
The auto-update process should be far more secure than SSL certificates. They'll have keys in the current Chrome which it'll use to check any updates are legitimate before they get unpacked/installed.
There are lots of people between 'a HN reader' and 'your grandmother'.
There will always be people who don't understand what a CA is; but the more people who do, the more pressure there will be for them to do their job correctly.
Also, they don't need to understand the technical details. If every time they go to their bank it says 'connection to your bank certified by verisign', and then one day it says 'certified by <someone else>', then a cautious person will be suspicious, even if they are completely nontechnical.
There are much better ways to notify users than trying to convince them of the value of monitoring their bank's CA. The browser could simply keep track of the cert and notify the user if it changes unexpectedly. This doesn't require the user to understand anything new, and it still works in the case that the fraudulent cert is signed by Verisign.
I learned to make computer games by making below average computer games. What's wrong with someone learning to make programming langauges by making below average programming langauges?
"The move comes after Conde talked to several investors about selling off a chunk of the company as part of the spinout;"