Yes, actually it is really hard if you want it to be reliable, well documented, etc. Usually why APIs stay closed is because they don't meet the bar of documentation quality and in order to use it you have to overcome several idiosyncracies and have tight communication with the team that wrote the API. Remind me never to hire you as a programmer. Modularity and well-defined APIs help develop reliable software. I don't know who convinced you otherwise, but an undocumented spaghetti mess of an interface is not the right way to make things work.
Well, what if all image formats opened in Paint when you click on them, and there was no way to disable that? Adobe would be allowed to put a hook into Paint itself, so that after loading in Paint, it could then also pop up Photoshop. That's pretty much the equivalent situation.
I wonder why Microsoft doesn't make more of these features as seperate applications that integrate into the system using public apis. The answer to that one would be pretty obvious. MSFT is a dominant force in large part because it keeps integrating things in ways such that they can't be replaced or removed. Remember IE being a required core part of the OS? I hate bundling with a passion, even when the cable company is doing it. That's a major reason why I use FOSS, I get choices to make, rather than restrictions and hoops to jump through if I want to make something work how I want.
The PDF also boasts, actually boasts, that Congress is adding over 1.7 Billion dollars in extra funding that the White House did not request, which must be used for "drug enforcement". Nah, that's just $1.7B of pork.
No one is forcing you to use GPL code, and until they do, the viral nature of the GPL (it is viral, but it's amazingly easy to avoid, it doesn't leap from one directory to another and infect your code without your knowledge) is totally harmless to you. I've had it with you people! I'm going to develop an airborne variant of the GPL, capable of jumping from host to host, and call it GPLv4 (thus infecting all the "GPLv2 or later" code). It will be an OSS epidemic, and you'll see what happens to all that BSD/MIT code which does not have resistance to being infected by other licenses. Only then will the truly viral nature inherent in the GPL be appreciated, but it will be too late to prevent *BSD from dying, and the CDC and NetCraft will confirm it.
Well, I imagine that General Mills has some computers and computer systems, and just maybe they have people to build and maintain said systems. I heard those computers all have cereal ports too. Nice perk IMO.
Ps - the brainwashing was a joke (i think they just put something in the water) No, they put it in the "Talking Rain". That's why it tastes the way it does. Resist...
Seriously though, they managed to get the author information to fit on three pages. Here's the preprint. Usually it's bad when your paper has 10 times as many authors as references, but in this case I guess one can make an exception.
Agreed. You can encode whatever you want into an algorithm, and it can certainly be biased and even illegal. For example, in some applicant rating system for a hiring "screen" program, if you have:
if(applicant.sex == female) rating = 0.0;
That would certainly violate equal opportunity laws, unless the company could prove that the output of said program was not used at all.
I hate when sites ZIP up an already compressed file, as this site does with their downloadable videos. Gamer sites in particular seem to love to do this. Is the 1% size reduction (or in some cases, increase) really worth it?
Release early, release often. Don't end up like Emacs.
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 1
I guess my question was more along the lines of "what sort of policies do you need to enforce with ACLs". Such as "a developer can only check-in under a certain subdirectory", or a certain file, or whether you need to be able to prevent developers from even reading certain subdirectories... I ask because I participate in the mailing list for an actively developed DSCM; If there's a single feature that is keeping it from being accepted in the corporate environment, the developers would like to know. From an implementation standpoint, write restrictions are relatively easy for a DSCM, while read restrictions would require more work. Several DSCMs are working on the concept of nested repositories / super-repositories as well, with some of the same usage cases as goals that ACLs might otherwise be used for. The more feedback on whether that could be useful, the better.
Re:Well, Linus is an ass, what's new.
on
Linus on GIT and SCM
·
· Score: 3, Insightful
No, wait: I recognize the benefits if his system. The problem is, his system has benefits with open source projects at most. I have several projects which have not been released as open source, and I can state for a fact there are benefits.
But here's what: in OSS, he can afford to "reject 99% of the branches out there". This is because he "believe[s] most of you guys are incompetent idiots". What you may not realize is that those branches still feed code to his tree, through delegation. Linus trusts 10 people, and they in turn trust 10 people, and in a few levels you can accept code from all those trees through an established web of trust.
In a small team, we don't throw 99% of our work out or keep a consistent base of developers who we believe are incompetent idiots. Can you give brand-new interns commit access to your core system? probably not. Can I code review a patch from a brand-new intern and accept it if it meets the quality standards for our core system? Yes I can. A distributed VCS can take advantage of possibly less skilled developers because its about trusting the well-defined patch, not the person. While such a workflow is not always precluded by centralized systems, distributed VCS's make this workflow very easy and natural.
Instead, we work together, frequently communicate, have fast turnaround times, and often work with files that can't be actually merged together (such as design related files, AI, PSD etc.). Centralization of the VCS itself has little or no effect on this. How would a distributed VCS inhibit your team from acting this way?
I clearly see the benefits of his system, but it shines for his own needs, SVN shines for the needs of the majority of small teams out there, and for more linear/classic style organized projects. Like I said, you just don't know what you are missing. If a developer has ever checked in something to mainline that wasn't done, just so another person could use it, you've just found a case where you really wanted a distributed VCS. If you've ever wanted to commit code on an airplane, so that you could easily revert if a new idea didn't work, you really wanted a distributed VCS. If you've ever wished you could test two patches together before merging them into the mainline, to avoid affecting other developers if the integrated version was buggy, you really wanted a distributed VCS. I've done all those things, and our project has had only 2-5 developers. At the same time, if you want to, you can use a distributed VCS in a centralized and linear manner; The only difference is that your team now has the choice of workflow models.
It also works for the majority of small OSS projects, which can't afford to be spread in hundreds of branches at a time, as features are clearly defined, priorities as well, so there's no need to spread what we do in hundreds of branches by definition. You aren't being forced to have hundreds of branches, just like SVN doesn't force you to make hundreds of checkouts. This is a red herring.
Also one of the benefits he mentions, basically everyone has his own branch and can diff locally with the other revisions, until someone "pulls" from him. That's handy but in its very basic core is the same as SVN cache. I can diff locally, save files as much as I want, revert files to the locally stored revisions etc., before I commit to the central repo. Not quite all the features he has, but as long as it does the job, that's all that takes. How about commit so that you have a logical development history, separating changes into logical parts, such as a new feature and a random bugfix you found along the way that you'd like to also push to stable -- all while disconnected. Like you say, if you don't run into that, it's not a problem. However, when I used CVS, I didn't realize all the times where I would have used a distributed VCS feature, because at the time I didn't think in those terms. Ignorance was bliss. Now that I use a distributed VCS, I use it even for single developer projects; The extra features do come in handy, and they aren't a hindrance.
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 1
It would be interesting to know more details of what you were trying to do, to see if there is some non-ACL way of mapping it to distributed VCS functionality. From a distributed VCS background, I would probably do something like the following: (1) Split off non-development files into a separate repository, with different permissions to that tree (2) Give release engineers their own tree which developers cannot push to; If a release engineer needs a fix from a developer, he can pull it.
In fact, a whole lot of nice things fall in to place when you make pull the fundamental operation rather than push. The general workflow is for a developer to finish an implementation, checking in as necessary, and then notify an upstream or more central developer that the patch is complete. The upstream developer reviews the patch and pulls it if is correct (works, doesn't violate policy, etc). In this flow, code review is emphasized, and at no point is any developer trusted with "push" rights until you get to the final central integrator (usually a release/QC person).
Distributed SCMs are extremely addictive. Once you've gotten used to one, there really is no going back. Once I had used BitKeeper, CVS became unusable from a feature standpoint. Thankfully now there are many FOSS options for distributed SCMs. Until you have worked with one, you don't even know what you are missing.
Btw, if you can publish your repo, the darcs developers might be interested in looking at it. Although there are still some unresolved computational issues with the patch model, darcs has improved greatly in the past year for many formerly common bad cases.
Just so people are clear, if you merge with any frequency, darcs should work just fine. I've worked with branches active up to a year, but I generally keep pulling into those long-lived branches from mainline so that there isn't too much drift. The most common cause of "exponential" repositories is trying to check-in and version machine-generated files, which is generally a bad thing to do anyway. If things do get really bad on some setup, you always have the option of rebasing a branch as a patch against the mainline (i.e. make a new branch, copy your working copy, and check that in). We've done that once when someone had a corrupted repository due to overzealous rsyncing (running "darcs check" after moving/copying repos is a good idea.)
Finally, a long term solution *is* being worked on in the form of a better patch model which avoids the exponential worst-case. As it stands now, darcs works great for small-to-medium sized projects, and for everything else there is Mercurial and Git.
Re:There's a difference between GIT and SVN
on
Linus on GIT and SCM
·
· Score: 3, Funny
Even bigger projects need specific directions, witness GCC. I am sorry but everyone who thinks distrubuted SCM are a good thing. I am going to say they are a bad thing for free software because they allow people to develop stuff in private. Yes this already happens. This is why for an example GCC's rules for branches are that they are free for all and they are used a lot. I'm sorry but this appears to be self-contradictory. If branches are good, distributed VCS's are good, because they are based around branches as a core concept. You seem to be under the mistaken belief that a branch in a distributed VCS must be private. In fact, you can push or publish any branch if you'd like to do so, and pull and merge any branch anyone makes public. All you need is for the development website to support multiple trees (this happens on kernel.org with multiple Git trees).
Take a look at http://gcc.gnu.org/svn.html and see how many branches there are, though most of them are inactive but some are very active (and getting ready to be merged into the trunk). I guess distrubuted SCM allows for people not to develop in public any more which I say is a bad thing. I have been working on a branch of GCC and who ever says merging is hard is wrong (I am dealing with an IR change which touches all front-ends and 50% of the middle-end, the tree level and I am able to merge at least once a week and the merge sometimes fix some of the regressions I was trying to fix before:)). For the most part you seem to be arguing for a distributed VCS, which makes branching easier. If you think CVS/SVN merging is easy, then these other systems would appear to be trivial. A not insignificant thing is that you can merge changesets from any branch, not just the trunk, and everything still works when you merge with the trunk later (think branch B which needs a feature from branch A, before A is ready to merge). No VCS forces people to work in public, and in fact distributed VCS are much better about encouraging people to check in early and often, rather than waiting until a feature is completely done (a common CVS model), or checking in too early when a feature has not been fully tested.
I don't know about you but having a policy of branches are free for all is a good thing and it causes what distrubuted SCM will cause which is more development and a "private" tree (though it is public but the branch is yours to deal with). Nothing forces anyone to hide their trees. You could require all developers to keep up-to-date trees on a centralized machine if it really matters.
I guess people don't see the bad side of distrubuted SCM that much because they don't deal with projects like GCC. The kernel has the same issue and I think Linus does not get the idea that public development is a good thing. I don't see how you draw that conclusion, or what evidence your conclusion is based on. Why do you feel this way?
I could have developed all of my branch (pointer_plus) in a private local tree but I would not get some of the testing I have been getting from people I did not expect to be testing my branch. Plus I don't have all the resources that other people are putting into the testing that they do. Nothing stops you from keeping the same workflow with a distributed VCS. Just put your tree somewhere where people can pull from it. You can even have people continuously following and aggregating/merging branches, allowing you to know about integration issues ahead of time.
Slashdot Mirror
That's only for people who think "optional" and "immutable" mean the same thing, as apparently you do. There is a difference.
Well, what if all image formats opened in Paint when you click on them, and there was no way to disable that? Adobe would be allowed to put a hook into Paint itself, so that after loading in Paint, it could then also pop up Photoshop. That's pretty much the equivalent situation.
While that may be true, did they at least have free (as in beer) drinks?
...
5) Higgs Profit!
Oops... for suitably large values of 10, that is. Namely 61.
Seriously though, they managed to get the author information to fit on three pages. Here's the preprint. Usually it's bad when your paper has 10 times as many authors as references, but in this case I guess one can make an exception.
1% of 30 million is still a lot of watch variables....
And if there are holes or parts missing when you are done, just say they will be filled with dark matter.
Could you explain your post for someone who isn't a geneticist/biologist?
Agreed. You can encode whatever you want into an algorithm, and it can certainly be biased and even illegal. For example, in some applicant rating system for a hiring "screen" program, if you have:
if(applicant.sex == female) rating = 0.0;
That would certainly violate equal opportunity laws, unless the company could prove that the output of said program was not used at all.
I hate when sites ZIP up an already compressed file, as this site does with their downloadable videos. Gamer sites in particular seem to love to do this. Is the 1% size reduction (or in some cases, increase) really worth it?
Release early, release often. Don't end up like Emacs.
I guess my question was more along the lines of "what sort of policies do you need to enforce with ACLs". Such as "a developer can only check-in under a certain subdirectory", or a certain file, or whether you need to be able to prevent developers from even reading certain subdirectories... I ask because I participate in the mailing list for an actively developed DSCM; If there's a single feature that is keeping it from being accepted in the corporate environment, the developers would like to know. From an implementation standpoint, write restrictions are relatively easy for a DSCM, while read restrictions would require more work. Several DSCMs are working on the concept of nested repositories / super-repositories as well, with some of the same usage cases as goals that ACLs might otherwise be used for. The more feedback on whether that could be useful, the better.
It would be interesting to know more details of what you were trying to do, to see if there is some non-ACL way of mapping it to distributed VCS functionality. From a distributed VCS background, I would probably do something like the following:
(1) Split off non-development files into a separate repository, with different permissions to that tree
(2) Give release engineers their own tree which developers cannot push to; If a release engineer needs a fix from a developer, he can pull it.
In fact, a whole lot of nice things fall in to place when you make pull the fundamental operation rather than push. The general workflow is for a developer to finish an implementation, checking in as necessary, and then notify an upstream or more central developer that the patch is complete. The upstream developer reviews the patch and pulls it if is correct (works, doesn't violate policy, etc). In this flow, code review is emphasized, and at no point is any developer trusted with "push" rights until you get to the final central integrator (usually a release/QC person).
Distributed SCMs are extremely addictive. Once you've gotten used to one, there really is no going back. Once I had used BitKeeper, CVS became unusable from a feature standpoint. Thankfully now there are many FOSS options for distributed SCMs. Until you have worked with one, you don't even know what you are missing.
Btw, if you can publish your repo, the darcs developers might be interested in looking at it. Although there are still some unresolved computational issues with the patch model, darcs has improved greatly in the past year for many formerly common bad cases.
Just so people are clear, if you merge with any frequency, darcs should work just fine. I've worked with branches active up to a year, but I generally keep pulling into those long-lived branches from mainline so that there isn't too much drift. The most common cause of "exponential" repositories is trying to check-in and version machine-generated files, which is generally a bad thing to do anyway. If things do get really bad on some setup, you always have the option of rebasing a branch as a patch against the mainline (i.e. make a new branch, copy your working copy, and check that in). We've done that once when someone had a corrupted repository due to overzealous rsyncing (running "darcs check" after moving/copying repos is a good idea.)
Finally, a long term solution *is* being worked on in the form of a better patch model which avoids the exponential worst-case. As it stands now, darcs works great for small-to-medium sized projects, and for everything else there is Mercurial and Git.