The Linux OS broke no new ground; Linux broke a great deal of ground in terms of open source project development model. Many FSF projects still do not run with the same level of transparency and free code exchange as the Linux kernel. Interestingly, and not coincidentally, Linus' main point about VCS is how they can be used to enhance that development model rather than break it.
Re:Well, Linus is an ass, what's new.
on
Linus on GIT and SCM
·
· Score: 2, Interesting
I use SVN if a medium sized team and see SVN used extensively in all kinds of projects around the globe with great success. I personally love the workflow of SVN.
If all you've ever known is centralized version control, you don't know what you are missing. Having used *both* centralized and decentralized version control on the same projects, I can say that decentralized wins hands down, but you have to work with it for a while to truly appreciate it.
The only thing that they need to work is merging of branches, and incidentally I've talked to the developers, they're quite aware of this flaw of SVN and working on it. We'll see new versions that can track changes in each branch and even attempt automated merges with good success.
If you take branching and merging to its logical limit, you end up with distributed version control. It's far easier to design with that in mind from the beginning. SVN has probably sunk more developer hours than darcs, mercurial, and monotone combined, which is a shame when you consider those three later projects have superior branching, merging, and disconnected operation than SVN. Git, while powerful, is highly adapted to the Linux kernel workflow, so many might not find it easy to use. However, there are several good distributed VCS options to choose from now, and there is a good option available for just about any project.
Darcs is arguably easier to use, although it doesn't scale well to large projects like Mercurial can. In particular, Mercurial requires commits at odd times (pull + merge) and doesn't support the same level of cherry-picking that darcs can support. Anything you could imagine wanting to do is likely possible in darcs; The main problem this raises is that supporting that rich model makes efficient implementation difficult or potentially impossible. However, for small projects <100k LOC, this is not really an issue, so darcs is hard to beat.
Yeah and luckily the whole "haves versus have nots" on who gets CVS commit access rights has never, ever, been a problem in *BSD or XFree86. Right?
Seriously, centralized version control fails for large open source projects for political reasons, not technical ones. That's really Linus' main point, although his lack of tact in presentation is going to cause many people to miss that insight. With a changeset-based distributed version control system, you only have to trust patches and code, not people. The whole concept of "the chosen few who get commit access" goes away, and problems like the XFree86/X.org fork or the EGCS/GCC semi-fork disappear.
While space will eventually be a problem, I think cost is still the limiting factor right now. How many houses can afford to cover their entire south-facing roof with panels right now? If you see panels on a house, its usually only covering a fraction of the available area, which implies the limit is cost.
Right now, we've got ~40% efficiency panels which are very expensive, and 1-2% panels which are cheap to make. I think the real breakthrough will be when we can make 20% efficiency panels that are inexpensive enough to cover a roof. So, in the long run, you are right that space will be the overriding factor, but right now it's cost-per-watt that is the biggest problem.
How much does it cost in comparison to Beagle 2? Now there's a comparison we can already make, although it's one the rover designers might not be too fond of.
The OS could send a "SIG_FREE_UP_SOME_DAMN_MEMORY". The best part would be applications that don't handle it would just crash, freeing up lots of memory:) But yeah, your point is valid; An OS managed shared cache could make cache management easier. An easier to add although not quite as elegant solution would be to have that cache be part of the desktop suite; While not fully shared, at least all the desktop apps for one user would be cooperating.
Good point, I had forgotten about fire alarms. I guess for completeness' sake, I should mention that I use a non-rechargeable battery in my watch as well, although it's a lithium and not an alkaline.
...out of control inflation in the USA... While I agree with most of what you say, I have no idea what makes you think inflation is out of control right now in the US. The average for the last 8 months is a 2.36% yearly rate. The EU has averaged 0.5% better over the same period. Most analysts seem to think that is pretty reasonable.
Heh, yet another way to squeeze a little bit more out of alkaline batteries. I hope most research is going into rechargeable battery tech these days, because those are the batteries I really care about. I only use alkalines in remote controls nowadays.
...and your Civic isn't a bomb on wheels waiting to go off should the battery compartment be intruded upon by another vehicle. Since when have NiMH batteries been explosive? They are just about the safest battery around (better than the lead-acid, certainly). Would you feel safer with a larger gas tank in its place? I'm not a Prius owner, but this is just FUD.
tracking down all the other items an install requires Nothing shows off your adept debating skills like using an argument that hasn't been true for 10 years.
Well, backwards compatibility is a double-edged sword, and I think it would be best to find some sort of middle ground between what Linux does (constant change), and what Sun and Microsoft do. I was pretty happy with IRIX when it was popular, as they seemed to hit a good medium between improvement and compatibility.
I do think OpenSolaris was a wonderful idea, and will allow Sun to catch up to what FreeBSD and Linux are doing in terms of attention to detail. Open source works great for fixing minor, yet annoying issues. Solaris can combine that with paid software architects to create a good overall design, and it's a combination I feel can work well for Sun.
While I used to use many OSes, I've settled on Debian now for all of my computers. It works and doesn't tend to get in my way. If I ever get a compelling reason to switch, I will, but so far there aren't any features on another OS I feel I must have. While I find them interesting, I don't personally need "enterprise" features, but YMMV.
No, this is a variant on a common "Simultaneous Localization and Mapping" (SLAM) algorithm that brings in elements similar to Image Completion from the computer graphics community. SLAM is a sensor and sensor interpretation problem, not a behavior/reasoning or action/control problem. While there are probabilistic reasoning systems, the only thing SLAM has in common with them is that it uses conditional probabilities.
Who cares? Do they work? In a 100% Solaris environment, sure. In a multi-platform environment with several *nix systems, with user account portability between machines, it most definitely does not work. At my university I used Linux, Solaris, IRIX, Tru64, and HP-UX. Linux and IRIX were nice to use Tru64 was decent, but Solaris required much tweaking to keep scripts running. The compiler was also a piece of crap in the 96-99 timeframe, though eventually it caught up. Admittedly, HP-UX was much worse, so I avoided it like the plague. Sun started beating out other vendors, so it was impossible to avoid using Sun boxes.
I expect vi to be the same from platform to platform. grep as well. Make???? grep, and many other programs, would be missing lots of options, or have incompatible options. The shell would have lots of subtle differences requiring many "if solaris" options in my setup. I consider make unusable if it doesn't support gmake's extensions. If you don't have gmake, you need to use things like automake, but if you are going to install those why not just make gmake the default? Sun's cc was terrible when compared to the MIPS or Alpha compilers that came with their respective unices. On the bright side, the man pages were far and away the best IMO.
I have always thought of Solaris as an awesome kernel paired with a userland that was only an afterthought. Kernel features are nice (low latency, scalability, etc), and the trend continues with ZFS and DTrace, but I wish they wouldn't neglect the userland. After all, where does a user spend his time?
It used to be that way, but it has long since been overrun with a more "general computing" crowd. I would bet that if you add up the regular Windows and Mac users, it would outnumber regular Linux users Disagreed. I don't recall it ever being that way. I remember long, long ago reading that most (> 70%) of the hits on/. were coming from Microsoft Windows boxes. Well, it seemed to me that Slashdot was a lot more Linux-centric in 1998/99. Then again, there were few posts to read on any given story, so it's hard to know for sure. I too remember a site statistic showing a large number of Windows users, which was the basis of the claim in my post. Wish I could find that story now...
The biggest savings with a hybrid come during times of deceleration and moderate acceleration; "Intelligent" cars would do their best to avoid it. So combining them is more of a case of 1+1=1.5 rather than 2. However, it would still make sense to combine them, because making highways intelligent is reasonable, but turning all the winding town and city streets into intelligent streets with 1-3 minutes of predictability is not. In robotics environments with multiple moving robots, you're lucky if you can predict a good 10 seconds into the future, let alone 180... you need the structure of something like a highway for good predictability.
It's a myth that Slashdot has almost all Linux users. It used to be that way, but it has long since been overrun with a more "general computing" crowd. I would bet that if you add up the regular Windows and Mac users, it would outnumber regular Linux users. For UIDs below 100k however, you would probably see a quite different statistic. People only notice Linux users here because we're not at 1-2%, like on almost any other discussion site.
Frankly, I'm now getting tired of the number of posts with the same tone as yours. You lament losing Karma in a sea of angry "Linux-zealot" mods, but I would guess you will be modded up, not down. Enjoy the karma...
Well, that could be part of the quiz... It could try to find out if you are the type of person that takes things apart to try to fix them, and doesn't get too angry if they don't work 100% when you put them back together.
Instead of taking the "one size fits all" approach, why not make the OS vary its approach depending on the knowledge of the user? I've often joked with friends that the first thing an OS should do when it installs is quiz the user about technical knowledge. Some people are willing to admit to being a novice, but many aren't. Forums are constantly full of people complaining about software, where it often turns out to be someone who decided to select "expert" and then got over their heads. You see a lot of this on computer hardware forums/rating sites as well -- people who got way ahead of their knowledge, broke something expensive, and now blame the company.
Now, it would be a lot harder to design a variable UI which adjusts to the user's knowledge, and I don't expect one any time soon. However, that's the only long-term solution I can see where all users can be happy, from novices to experts. No single approach will ever fit all users.
Slashdot Mirror
Darcs is arguably easier to use, although it doesn't scale well to large projects like Mercurial can. In particular, Mercurial requires commits at odd times (pull + merge) and doesn't support the same level of cherry-picking that darcs can support. Anything you could imagine wanting to do is likely possible in darcs; The main problem this raises is that supporting that rich model makes efficient implementation difficult or potentially impossible. However, for small projects <100k LOC, this is not really an issue, so darcs is hard to beat.
Yeah and luckily the whole "haves versus have nots" on who gets CVS commit access rights has never, ever, been a problem in *BSD or XFree86. Right?
Seriously, centralized version control fails for large open source projects for political reasons, not technical ones. That's really Linus' main point, although his lack of tact in presentation is going to cause many people to miss that insight. With a changeset-based distributed version control system, you only have to trust patches and code, not people. The whole concept of "the chosen few who get commit access" goes away, and problems like the XFree86/X.org fork or the EGCS/GCC semi-fork disappear.
While space will eventually be a problem, I think cost is still the limiting factor right now. How many houses can afford to cover their entire south-facing roof with panels right now? If you see panels on a house, its usually only covering a fraction of the available area, which implies the limit is cost.
Right now, we've got ~40% efficiency panels which are very expensive, and 1-2% panels which are cheap to make. I think the real breakthrough will be when we can make 20% efficiency panels that are inexpensive enough to cover a roof. So, in the long run, you are right that space will be the overriding factor, but right now it's cost-per-watt that is the biggest problem.
How much does it cost in comparison to Beagle 2? Now there's a comparison we can already make, although it's one the rover designers might not be too fond of.
The OS could send a "SIG_FREE_UP_SOME_DAMN_MEMORY". The best part would be applications that don't handle it would just crash, freeing up lots of memory :) But yeah, your point is valid; An OS managed shared cache could make cache management easier. An easier to add although not quite as elegant solution would be to have that cache be part of the desktop suite; While not fully shared, at least all the desktop apps for one user would be cooperating.
Good point, I had forgotten about fire alarms. I guess for completeness' sake, I should mention that I use a non-rechargeable battery in my watch as well, although it's a lithium and not an alkaline.
...out of control inflation in the USA... While I agree with most of what you say, I have no idea what makes you think inflation is out of control right now in the US. The average for the last 8 months is a 2.36% yearly rate. The EU has averaged 0.5% better over the same period. Most analysts seem to think that is pretty reasonable.Heh, yet another way to squeeze a little bit more out of alkaline batteries. I hope most research is going into rechargeable battery tech these days, because those are the batteries I really care about. I only use alkalines in remote controls nowadays.
...and your Civic isn't a bomb on wheels waiting to go off should the battery compartment be intruded upon by another vehicle. Since when have NiMH batteries been explosive? They are just about the safest battery around (better than the lead-acid, certainly). Would you feel safer with a larger gas tank in its place? I'm not a Prius owner, but this is just FUD.Maybe his point is that it's really difficult to port to Windows compared to any other OS? I guess that's what he means by "ecosystem".
Did high energy elbow impact head of yours? This perhaps explain talk your way as reason. Apologies from me yet resist could not.
Or use only SI units, and yet crash it into Mars anyway.
Well, backwards compatibility is a double-edged sword, and I think it would be best to find some sort of middle ground between what Linux does (constant change), and what Sun and Microsoft do. I was pretty happy with IRIX when it was popular, as they seemed to hit a good medium between improvement and compatibility.
I do think OpenSolaris was a wonderful idea, and will allow Sun to catch up to what FreeBSD and Linux are doing in terms of attention to detail. Open source works great for fixing minor, yet annoying issues. Solaris can combine that with paid software architects to create a good overall design, and it's a combination I feel can work well for Sun.
While I used to use many OSes, I've settled on Debian now for all of my computers. It works and doesn't tend to get in my way. If I ever get a compelling reason to switch, I will, but so far there aren't any features on another OS I feel I must have. While I find them interesting, I don't personally need "enterprise" features, but YMMV.
No, this is a variant on a common "Simultaneous Localization and Mapping" (SLAM) algorithm that brings in elements similar to Image Completion from the computer graphics community. SLAM is a sensor and sensor interpretation problem, not a behavior/reasoning or action/control problem. While there are probabilistic reasoning systems, the only thing SLAM has in common with them is that it uses conditional probabilities.
If you want to know more, feel free to ask.
I have always thought of Solaris as an awesome kernel paired with a userland that was only an afterthought. Kernel features are nice (low latency, scalability, etc), and the trend continues with ZFS and DTrace, but I wish they wouldn't neglect the userland. After all, where does a user spend his time?
I guess I was unclear, by "it" I meant "acceleration and deceleration". From the rest of my post, you can see we actually agree.
The biggest savings with a hybrid come during times of deceleration and moderate acceleration; "Intelligent" cars would do their best to avoid it. So combining them is more of a case of 1+1=1.5 rather than 2. However, it would still make sense to combine them, because making highways intelligent is reasonable, but turning all the winding town and city streets into intelligent streets with 1-3 minutes of predictability is not. In robotics environments with multiple moving robots, you're lucky if you can predict a good 10 seconds into the future, let alone 180... you need the structure of something like a highway for good predictability.
It's a myth that Slashdot has almost all Linux users. It used to be that way, but it has long since been overrun with a more "general computing" crowd. I would bet that if you add up the regular Windows and Mac users, it would outnumber regular Linux users. For UIDs below 100k however, you would probably see a quite different statistic. People only notice Linux users here because we're not at 1-2%, like on almost any other discussion site.
Frankly, I'm now getting tired of the number of posts with the same tone as yours. You lament losing Karma in a sea of angry "Linux-zealot" mods, but I would guess you will be modded up, not down. Enjoy the karma...
Well, that could be part of the quiz... It could try to find out if you are the type of person that takes things apart to try to fix them, and doesn't get too angry if they don't work 100% when you put them back together.
Instead of taking the "one size fits all" approach, why not make the OS vary its approach depending on the knowledge of the user? I've often joked with friends that the first thing an OS should do when it installs is quiz the user about technical knowledge. Some people are willing to admit to being a novice, but many aren't. Forums are constantly full of people complaining about software, where it often turns out to be someone who decided to select "expert" and then got over their heads. You see a lot of this on computer hardware forums/rating sites as well -- people who got way ahead of their knowledge, broke something expensive, and now blame the company.
Now, it would be a lot harder to design a variable UI which adjusts to the user's knowledge, and I don't expect one any time soon. However, that's the only long-term solution I can see where all users can be happy, from novices to experts. No single approach will ever fit all users.
It would be loosen in that case. Please go back to English class...