grep: Limited substitute for some of the stuff cscope does. I love the '-r' option failing that use: find/directory -exec grep "pattern" {} \; -print
One small convenience git provides is "git grep", which does a recursive grep of your working directory, but just of paths that git is tracking. It's kind of surprising how often I find myself using that; it still doesn't quite replace cscope (plus vim keybindings) for me, but it's a heck of a lot better than the "find src/ -name '*.h' -o -name '*.c' | xargs grep" stuff that I used to find myself doing occasionally....
Something like ZFS, that "touches so many other applications and parts of the OS" has to be the default. Otherwise you have to support two completely different ways of using the system.
Perhaps you haven't heard of the VFS? (A fine paper, by the way, well worth the read.)
Supporting multiple filesystems is required in this case; users will not accept having to completely rebuild all their filesystems in order to use them under a new OS version, especially if doing so makes those filesystems inaccessible to earlier versions. "Default" in this case probably just means "default for newly created filesystems".
The thing is, Linux is actually a pretty small project.
OK, distributions (with FreeBSD essentially is) inherently have more lines of code. Compared to projects working on a single piece of software, Linux isn't that small. And it has a big active developer community, so the tree sees lots of commits.
Much larger projects would include FreeBSD, which uses CVS not only for the kernel but for every line of source of the entire OS. Now, Linus is a smart guy, but I don't know why he thinks CVS (and SVN by extension) won't work for large projects. It clearly can. It may not be suitable for the way he wants to run his project, but that's a different issue.
Hm. I've been managing to mostly avoid CVS recently, but a few years ago we tried developing with a linux kernel tree in CVS. My memory is that some operations that should have been nearly instantaneous (cvs update to fetch the latest version, cvs diff to compare two historical versions of the tree) were painfully slow.
So, ok, distributed is nice (though for some projects central may be preferred) but I don't see how this magic system bypasses politics.
Well, I agree, to a point--you can never eliminate politics. But it does make the politics better, by focusing it on the actual technical content; the example you give is right on:
In fact, I can potentially see more internal politics over this method. I can see factions gathering to support this or that branch, arguing about which is better, fighting about which one gets merged in.
That's exactly what you *should* be arguing about--you're arguing not about whether a certain developer can be trusted, but about whether given content should be merged in. That kind of "politics" is necessary and important. And the fact that these factions are, as far as git is concerned, on an equal footing--anyone can choose to pull from one, the other, or both, and can do so without endorsing either faction or trusting them for future development--means that the decision comes down to which tree is better, not to which group should be in charge.
In CVS, basically anyone can check out the whole tree and make any changes the like. They can then say, see, my changes are good and ask for them to get committed or ask for commit access themself. In Git, this commit access bottleneck is just moved from the commit stage to the merge stage. You make your changes, commit them to your separate and unique branch, and then ask someone with to merge it, or give you the ability to merge it in to mainstream. How exactly does this eliminate the politics? You are still going to have some people with "the power" and some people without. In any project where you have people who are going to fight about who gets commit access, you'll just have a fight about who has the ability to merge into mainstream.
With git there's no *technical* difference between "mainstream" and the rest--everybody has a complete copy of the project history, so it's trivial for someone else to take over the project. Of course, you still need to coordinate, and in many cases that means you still need to agree to designate one repository as more important than the others. But that's not a choice that's enforced by the technology. (OK, maybe it's not really enforced by CVS either, but with CVS, cloning a repository and switching everyone over to it is a fair amount of work. With git it's trivial--it's the normal way that git works, so there's nothing different to do.)
In the situation where nobody wants to change mainstream, there's still an important distinction between multiple committers and multiple people who a maintainer pulls from. The latter situation gives much finer-grained control to maintainers--even when pulling from a long-established and trusted developer, if a maintainer happens to notice something wrong, they can drop it and say "hey, fix up X first, then I'll pull again". Or they can pull some work from someone once if they think it's good work, without having to give further commit access.
In addition, git works well for simple projects but not so well for projects that have many different related subprojects which share code.
Linus has written some very low-level subproject support, but at this point I think it's only interesting to very early adopters and/or people who can help hack on the higher-level infrastructure that'll be needed to make it usable.
How is it possible for the vast majority of people who wish to compete in these events to do so without having to spend hundreds of dollars on round-trip airfare?
It looks like there's also a $100 registration fee, but that includes food and lodging for the event. Seems to me like they're actually working pretty hard to keep it inexpensive. There's also a scholarship to reduce the costs for students. I'm sure they'd be happy to do more, given the money--see their donation page if you know anyone that could chip in.
Things that could be moved into an add-on: spellcheck, clear private data, rss feed features, phishing checker...
Any idea what kind of resources that would save? (And how would we find out?)
Also, that stuff will have to be enabled by default--I don't want to have to go turn on a dozen configuration options just to get the features I've come to expect out of a browser. No doubt there could be interest in that kind of customization for older computers and embedded projects, though.
Then what's the difference? Closed source software has "many eyes," too. They just happen to be paid by someone.
Right. The same "someone", usually. And a "someone" whose interests are not those of users.
This is the same reason we usually trust a result published in a peer-reviewed journal more than one reported by a corporation with only internal peer review, even when the resources available for the internal peer review may be excellent.
It's the difference between "here's our results, here's how we got them, feel free to try yourself and see if you come to the same conclusions" and "here's our results, our best people checked them, honest!"
I don't understand why they don't keep fx slim with with all the proposed additional features as external (and hence optional) add-ons.
At least some of the complaints I've heard about "firefox bloat" have turned out, on closer examination, to be due to memory leaks in the Flash plugin.
And that's a disadvantage of plugins: they're complex bits of code that run in the same memory space as firefox and have the ability to screw it up arbitrarily badly, but that aren't part of the main code base, so aren't usually reviewable or fixable by Firefox developers.
Anyway, what piece of functionality would you identify as a candidate for moving into an optional add-on, and what do you expect that would save?
The original poster *should* have said "if it's not possible for anyone that wants to see the source to see it...".
The point isn't that everyone has to individually review it. The point is that if the provider makes some claim about it, it is possible for third parties to verify that claim.
Similarly, I trust long-standing scientific results not because I have personally reproduced every experiment on which they rest, but because I know that anyone *could* do so. It's a question of trusting a process that allows independent third parties to conduct and publish critical review, as opposed to a process that depends on trusting a single person or organization.
I think patents should only be granted for inventions that took very substantial amounts of work to invent and are very nonobvious.
Actually, in some extremely important cases, the really hard work is not in the invention itself but in bringing the invention to market. Pharmacuticals are the classic case--the original discovery may be trivial, but the studies required to demonstrate that a drug is actually safe and effective can be extremely expensive. And once those studies are done, it's only the patent that prevents any competitor from taking advantage of the results--and thus patents serve to give companies the incentive to invest in that kind of research.
Telecommuting does not work for programmers in any sort of team environment, which either is or should be most jobs.
Any number of open source projects would serve as excellent counterexamples of highly productive projects involving teams that collaborate closely across large distances. Most of my day job is Linux kernel development, and while I'm fortunate to have great kernel hackers in my office and in the neighborhood who I can go hang out with and ask questions, the nature of the project dictates that most of the people I work with are people I've never, or only occasionally, met face-to-face.
It certainly takes some getting used to. It's been a real test of my reading and writing skills--you need to be able to understand and explain complex technical ideas, and keep discussions going despite personality conflicts. And it'll help to have good local computer resources, a fast network connection, and a mail client that helps you handle massive mailing list traffic efficiently....
So what distinguishes a cell phone from having a conversation with a passenger? Or someone trying to find the right station on the radio. Or smoking a cigarette (assuming you are not just hanging the butt from your mouth and letting it ash all down your front.) Or trying to shush their screaming kid in the back seat. Or fishing around in a bag of fast food for a hamburger. Or trying to tip the last bit of coffee out of your spill-proof mug. Or listening attentively to their GPS navigation system. Or attempting to decipher driving directions scribbled on a napkin. Or listening to their books on tape.
Maybe not much. But the traffic code doesn't exist to tell you everything you need to know how to be a good driver. It's when a bunch of people start doing something pointless and stupid that as a society we step in and say "hey! Cut that out!". We're never going to come up with a traffic code that penalizes every possible dangerous behavior to exactly a degree that it is dangerous. So it's never much of an argument to say "sure, X is stupid, and a little dangerous, but Y is even stupider and more dangerous, and it's legal!"
If your only concern is safety then it makes more sense to lower the speed limit to 25 MPH and eliminate any car larger than a golf cart than it does to fine/ban cell phones.
Fine by me. Personally I choose to live within a couple miles of work and shopping, in part exactly because I think that spending hours every week commuting is boring and dangerous for everyone involved. But obviously what we choose to outlaw is determined by more than just safety, and whatever I think about the particular balance struck here, I'd certainly agree that asking people to give up texting while driving is a much smaller imposition than asking them to give up their job downtown or their big home in the suburbs.
Not 100% related, but I ordered a 965-based motherboard because Intel has open source drivers for the X3000.
Yup. I bought a new machine recently for work that's Intel-based (essentially this, minus the monitor). I mainly use it for kernel development. My criteria were:
I want the fastest kernel compile I can get for cheap. (Turns about to be 3.5 minutes with my kernel config, for about $700 spent. Not bad.)
I want to boot the latest kernel out of git and have a fighting chance that everything will Just Work.
I want to know that number 2 will still be true in a few years.
I don't care about top-notch video performance but, hey, I enjoy the wobbly windows, and maybe the occasional game of tuxracer or something.
It turns out the gigabit ethernet and the video both needed kernels more recent than the first distro I tried (they're fine in the latest fc7 betas), but otherwise it's worked out well. So when the student interns came in this summer and needed machines, we ordered five more. I'm considering another to replace my again home machine, too, if I can get an idea how loud it is. (My office has too many noisy machines, so it's hard to tell.)
My point is that Joe doesn't need the Genuine Areo Experience(TM) to check his email, and he knows this.
Sure. Aero is optional, though, isn't it? Are there other Vista demands that low-end (but new) machines aren't up to? And isn't the cheapest integrated graphics adequate for it by now? (Forgive my ignorance--I ignore Windows. The cheapest new stuff seems to be up to Beryl/Compiz at this point, so I assume Aero isn't much harder.) If not, it's hard to imagine it won't be soon. The low end catches up very fast....
Is it? This isn't my area, and I haven't looked at it (beyond glancing at the git logs), but my vague impression was that they were playing well with others....
Do you honestly that Joe is going to opt for the $800 "vista ready" computer when it looks as though the $500 "ubuntu loaded" one is right next to it on the virtual shelf?
There's no way Microsoft would price itself out of the market like that. They can afford to give away the software load if they have to--they could probably afford to *pay* a small amount to get Windows loaded on there, if the value as advertising justified it. They'll be fine as long as they're still getting enough money from someplace (software on higher-margin machines, support,...) to continue Windows development.
There are always going to be people using programs like Skype and other non-free pieces of software on linux, because they choose to.
That's quite different--the kernel system call interface never changes, and software that runs on today's kernel has a good chance of running on whatever's current three years from now (with some exceptions depending on what other assumptions the software developers made about the system).
But device drivers depend on all sorts of internal kernel interfaces, and the chances of today's driver still working unmodified on a kernel three years from now are pretty much zero.
What'd be nice is if Dell labelled the 'free' builds clearly if they go down that route.
I agree, that would be helpful.
I don't imagine they will though as it may confuse people new to the concept of free software.
They could say that those builds include drivers not supported by Ubuntu itself; that might be clear enough. I think that's how Ubuntu's package management software explains it already, actually.
If Dell are building laptops with Ati graphics cards in them, Ati will probably be working to develop their drivers further anyway.
Great, so I get a "linux" machine that depends on proprietary drivers that can't actually be included in Linux, so 3 years from now I'm still totally dependent on ATI and Dell if I want to upgrade to the latest version of Linux to get some new feature (or fix a bug).
There's lots of reasons to like Linux, but I think it's biggest advantage is exactly that it's free/open source software, which means (among many other things) that you don't normally have to depend on a single vendor in that way.
So my hope is they either talk ATI/Nvidia into getting real free drivers into x.org and the kernel, or they just stick to the latest Intel hardware--so maybe it won't be a cutting-edge gaming machine, but it'll be more than adequate for a desktop (even a desktop with the latest 3-d bells and whistles). And then the latest software will continue to work on it regardless of the whims of ATI.
Now if you are merely speaking of home use, but even there, I want power for less cost too.
And I assume there's a strong correlation between power and noise. Most people's homes are quiet enough for a loud machine to really call attention to itself.
Slashdot Mirror
One small convenience git provides is "git grep", which does a recursive grep of your working directory, but just of paths that git is tracking. It's kind of surprising how often I find myself using that; it still doesn't quite replace cscope (plus vim keybindings) for me, but it's a heck of a lot better than the "find src/ -name '*.h' -o -name '*.c' | xargs grep" stuff that I used to find myself doing occasionally....
Perhaps you haven't heard of the VFS? (A fine paper, by the way, well worth the read.)
Supporting multiple filesystems is required in this case; users will not accept having to completely rebuild all their filesystems in order to use them under a new OS version, especially if doing so makes those filesystems inaccessible to earlier versions. "Default" in this case probably just means "default for newly created filesystems".
OK, distributions (with FreeBSD essentially is) inherently have more lines of code. Compared to projects working on a single piece of software, Linux isn't that small. And it has a big active developer community, so the tree sees lots of commits.
Hm. I've been managing to mostly avoid CVS recently, but a few years ago we tried developing with a linux kernel tree in CVS. My memory is that some operations that should have been nearly instantaneous (cvs update to fetch the latest version, cvs diff to compare two historical versions of the tree) were painfully slow.
Well, I agree, to a point--you can never eliminate politics. But it does make the politics better, by focusing it on the actual technical content; the example you give is right on:
That's exactly what you *should* be arguing about--you're arguing not about whether a certain developer can be trusted, but about whether given content should be merged in. That kind of "politics" is necessary and important. And the fact that these factions are, as far as git is concerned, on an equal footing--anyone can choose to pull from one, the other, or both, and can do so without endorsing either faction or trusting them for future development--means that the decision comes down to which tree is better, not to which group should be in charge.
With git there's no *technical* difference between "mainstream" and the rest--everybody has a complete copy of the project history, so it's trivial for someone else to take over the project. Of course, you still need to coordinate, and in many cases that means you still need to agree to designate one repository as more important than the others. But that's not a choice that's enforced by the technology. (OK, maybe it's not really enforced by CVS either, but with CVS, cloning a repository and switching everyone over to it is a fair amount of work. With git it's trivial--it's the normal way that git works, so there's nothing different to do.)
In the situation where nobody wants to change mainstream, there's still an important distinction between multiple committers and multiple people who a maintainer pulls from. The latter situation gives much finer-grained control to maintainers--even when pulling from a long-established and trusted developer, if a maintainer happens to notice something wrong, they can drop it and say "hey, fix up X first, then I'll pull again". Or they can pull some work from someone once if they think it's good work, without having to give further commit access.
I think the current tutorial is pretty good, actually. (But I'm biased--I wrote most of it. Suggestions welcomed....)
See also the user manual for a more thorough treatment.
Linus has written some very low-level subproject support, but at this point I think it's only interesting to very early adopters and/or people who can help hack on the higher-level infrastructure that'll be needed to make it usable.
It looks like there's also a $100 registration fee, but that includes food and lodging for the event. Seems to me like they're actually working pretty hard to keep it inexpensive. There's also a scholarship to reduce the costs for students. I'm sure they'd be happy to do more, given the money--see their donation page if you know anyone that could chip in.
Any idea what kind of resources that would save? (And how would we find out?)
Also, that stuff will have to be enabled by default--I don't want to have to go turn on a dozen configuration options just to get the features I've come to expect out of a browser. No doubt there could be interest in that kind of customization for older computers and embedded projects, though.
Right. The same "someone", usually. And a "someone" whose interests are not those of users.
This is the same reason we usually trust a result published in a peer-reviewed journal more than one reported by a corporation with only internal peer review, even when the resources available for the internal peer review may be excellent.
It's the difference between "here's our results, here's how we got them, feel free to try yourself and see if you come to the same conclusions" and "here's our results, our best people checked them, honest!"
At least some of the complaints I've heard about "firefox bloat" have turned out, on closer examination, to be due to memory leaks in the Flash plugin.
And that's a disadvantage of plugins: they're complex bits of code that run in the same memory space as firefox and have the ability to screw it up arbitrarily badly, but that aren't part of the main code base, so aren't usually reviewable or fixable by Firefox developers.
Anyway, what piece of functionality would you identify as a candidate for moving into an optional add-on, and what do you expect that would save?
The original poster *should* have said "if it's not possible for anyone that wants to see the source to see it...".
The point isn't that everyone has to individually review it. The point is that if the provider makes some claim about it, it is possible for third parties to verify that claim.
Similarly, I trust long-standing scientific results not because I have personally reproduced every experiment on which they rest, but because I know that anyone *could* do so. It's a question of trusting a process that allows independent third parties to conduct and publish critical review, as opposed to a process that depends on trusting a single person or organization.
They would? Why? This is patent, not copyright--copying doesn't have much to do with it.
Actually, in some extremely important cases, the really hard work is not in the invention itself but in bringing the invention to market. Pharmacuticals are the classic case--the original discovery may be trivial, but the studies required to demonstrate that a drug is actually safe and effective can be extremely expensive. And once those studies are done, it's only the patent that prevents any competitor from taking advantage of the results--and thus patents serve to give companies the incentive to invest in that kind of research.
It can? How?
Any number of open source projects would serve as excellent counterexamples of highly productive projects involving teams that collaborate closely across large distances. Most of my day job is Linux kernel development, and while I'm fortunate to have great kernel hackers in my office and in the neighborhood who I can go hang out with and ask questions, the nature of the project dictates that most of the people I work with are people I've never, or only occasionally, met face-to-face.
It certainly takes some getting used to. It's been a real test of my reading and writing skills--you need to be able to understand and explain complex technical ideas, and keep discussions going despite personality conflicts. And it'll help to have good local computer resources, a fast network connection, and a mail client that helps you handle massive mailing list traffic efficiently....
Maybe not much. But the traffic code doesn't exist to tell you everything you need to know how to be a good driver. It's when a bunch of people start doing something pointless and stupid that as a society we step in and say "hey! Cut that out!". We're never going to come up with a traffic code that penalizes every possible dangerous behavior to exactly a degree that it is dangerous. So it's never much of an argument to say "sure, X is stupid, and a little dangerous, but Y is even stupider and more dangerous, and it's legal!"
Fine by me. Personally I choose to live within a couple miles of work and shopping, in part exactly because I think that spending hours every week commuting is boring and dangerous for everyone involved. But obviously what we choose to outlaw is determined by more than just safety, and whatever I think about the particular balance struck here, I'd certainly agree that asking people to give up texting while driving is a much smaller imposition than asking them to give up their job downtown or their big home in the suburbs.
Yup. I bought a new machine recently for work that's Intel-based (essentially this, minus the monitor). I mainly use it for kernel development. My criteria were:
It turns out the gigabit ethernet and the video both needed kernels more recent than the first distro I tried (they're fine in the latest fc7 betas), but otherwise it's worked out well. So when the student interns came in this summer and needed machines, we ordered five more. I'm considering another to replace my again home machine, too, if I can get an idea how loud it is. (My office has too many noisy machines, so it's hard to tell.)
Sure. Aero is optional, though, isn't it? Are there other Vista demands that low-end (but new) machines aren't up to? And isn't the cheapest integrated graphics adequate for it by now? (Forgive my ignorance--I ignore Windows. The cheapest new stuff seems to be up to Beryl/Compiz at this point, so I assume Aero isn't much harder.) If not, it's hard to imagine it won't be soon. The low end catches up very fast....
Is it? This isn't my area, and I haven't looked at it (beyond glancing at the git logs), but my vague impression was that they were playing well with others....
There's no way Microsoft would price itself out of the market like that. They can afford to give away the software load if they have to--they could probably afford to *pay* a small amount to get Windows loaded on there, if the value as advertising justified it. They'll be fine as long as they're still getting enough money from someplace (software on higher-margin machines, support,...) to continue Windows development.
That's quite different--the kernel system call interface never changes, and software that runs on today's kernel has a good chance of running on whatever's current three years from now (with some exceptions depending on what other assumptions the software developers made about the system).
But device drivers depend on all sorts of internal kernel interfaces, and the chances of today's driver still working unmodified on a kernel three years from now are pretty much zero.
I agree, that would be helpful.
They could say that those builds include drivers not supported by Ubuntu itself; that might be clear enough. I think that's how Ubuntu's package management software explains it already, actually.
Great, so I get a "linux" machine that depends on proprietary drivers that can't actually be included in Linux, so 3 years from now I'm still totally dependent on ATI and Dell if I want to upgrade to the latest version of Linux to get some new feature (or fix a bug).
There's lots of reasons to like Linux, but I think it's biggest advantage is exactly that it's free/open source software, which means (among many other things) that you don't normally have to depend on a single vendor in that way.
So my hope is they either talk ATI/Nvidia into getting real free drivers into x.org and the kernel, or they just stick to the latest Intel hardware--so maybe it won't be a cutting-edge gaming machine, but it'll be more than adequate for a desktop (even a desktop with the latest 3-d bells and whistles). And then the latest software will continue to work on it regardless of the whims of ATI.
And I assume there's a strong correlation between power and noise. Most people's homes are quiet enough for a loud machine to really call attention to itself.