* name patches (commit sets) & find them trivially by name later git-tag
* trivially apply explicit patches to alternate branches I don't really know what an "explicit patch" is. git-apply is probably what you want though.
* automatically find all patches that a patch depends on I don't know if git can do this, but you don't end up using it that way really. You can use git-cherry to figure out which commits are different from another branch, and then either cherry pick them as desired. You can also use git-format-patch in combination with git-am to do this as well. It'd be nice to just be able to give git a specific commit and have it figure out the ancestors that are necessary for it to apply cleanly. Generally though, it doesn't matter because you just merge from someone's work and trivially diverge using working branches.
* create repositories trivially git-init
* see who committed specific lines of code git-blame
Re:Turns out the whole reason for the attack was..
on
Ubuntu Servers Hacked
·
· Score: 1
Debian isn't geared towards 'more effort' or else tools like apt wouldn't have come out of the project. It's geared towards doing things at a high quality, which often necessitates some time and effort to get right. The grandparent's point about automatix is a valid one. Many Ubuntu devs are also Debian devs, and so they carry the emphasis on quality with them, which is why the restricted device manager is as good as it is, in contrast to automatix.
dpkg and apt work fine. It's the packaging scripts themselves that are often broken. This is why Debian has various development suites to help make these packaging scripts work properly. Ubuntu grabs packages from Debian when they're in a pre-release state. Normally that's fine and they work well, but you can end up with problems because the Debian developers who are following their own release schedule haven't necessarily fixed the bugs that might hit Ubuntu. Additionally, it doesn't look like the Ubuntu development branches get as much wide-spread testing as the corresponding Debian branches, so it might be that no one is aware of bugs like this before they release. Finally, there's a lot of crappy and overly complicated packaging out there (automatix falls under both categories) that is just crawling with bugs.
The stuff in experimental is really not polished yet. It hasn't been released upstream for a reason, after all, and the Debian packaging isn't really adapted to it yet. More importantly for Debian, no other driver besides the new intel supports randr 1.2 right now, so we'd have to special case a lot of things for that driver, which isn't really worthwhile right now. The Lenny cycle will be largely devoted to adapting to the new stuff going on at X.org including randr 1.2 and input hotplugging, but what's in experimental right now is just the first glimpses of what's in store.
We know it's a pain, and it's a major goal for the next release. The Debian X Strike Force burned the entire release cycle moving first from XFree86 to Xorg, and then from the monolithic Xorg to modular Xorg. By the time it all that was finished, about a year and a half had passed and there was a few months to polish things up for the release. During this time, essentially an entirely new team was built up (only one person from the team that worked on XFree86 in Sarge is still an active member) and there was huge changes as the entire codebase was repackaged for 7.0 and we moved from a private SVN repo to git.debian.org, which was no small feat while we did our best to keep the updates coming at a good pace.
So expect to see some improvements to this stuff in the next year or so. A lot of work is happening at X.org to improve autoconfiguration, and Debian is moving to help develop it and deliver it to the users. Lenny is going to be really exciting from this point of view.
My main objection to apt is that on 2 seperate occasions (once with Xandros, and once with Debian itself) I've had apt go berserk when trying to uninstall Open Office...the dep chain somehow got confused and I ended up with a completely corrupted system. It was deleting things in what seemed like an entirely random manner. That in my mind is not a stable system.
I won't speak to Xandros since I don't know it, but I've never had that problem in Debian. Sometimes for deeply connected things you do have to do some manual work to make it uninstall packages, but with some simple hand holding in an interactive apt frontend (aptitude, dselect, or synaptic) you can get it to pull these things out, and it's not a problem again.
Subpackaging is an attrocity in both systems as well...it makes source compilation outside either system (for scenarios where you find a package where there isn't an rpm/deb; it does happen) largely impossible.
No one said you had to package it. You can just as easily compile and install to/usr/local, just like slack. Granted, the problem is that the packaging system might not be aware of it, but that's what the equivs package is for.
The other thing is that saying you can put a custom kernel in without the system complaining isn't anything Debian users should be bragging about...it can be done in Slackware, minus the screwing around with making a kernel deb.
You don't have to make a deb. For years I ran custom kernels that weren't in debs, and it's still very well supported. Sure, you can do it with Slack too, but that doesn't make customizing Debian any harder.
A lot of Debian fanboys here might love apt...but it isn't the silver bullet it's made out to be. As I said earlier, for end users who don't use much other than Open Office, XMMS, VLC, and Firefox, it'd be fine...but for those of us who want to use our systems for something slightly more meaningful, there are areas where it is wanting.
I'll agree that it's no silver bullet, but come on. "Something slightly more meaningful" than the various examples I gave? Customized versions of Debian are being used right now to run city governments, mass-market embedded products, whole satellite networks, and far more. I don't know if that's "meaningful" or not to you, but it definitely speaks to its ready customizability beyond the basic desktop.
The Firefox update issue is probably not a fair consideration, since it's not actually Canonical, it's a function of Debian's issues with Mozilla.
Uh... no. First off, it's not Debian's job to support Dapper Drake LTS. That's Ubuntu's job. So Ubuntu is in charge of supplying patches for it in a timely manner.
For anyone who wants anything more versatile, however (and for anyone who cares about a system which follows UNIX design philosophy - I'm talking about the stuff here) both Ubuntu and Debian are to be avoided, in my own mind.
I'm seriously stunned that you would lump Debian in there. Debian is vastly popular in the embedded market, and it scales up to the monster s390 nicely. It can run a desktop or a server. It can run the Nokia 770 or the entire Munich city government infrastructure. The gigantic package repository means that you can take advantage of the vast majority of the free software that's out there without any serious work. You can use any of the bazillion wm's or shells that are available and craft the system to your needs. You can add in a custom kernel and the sytem will not complain or overwrite it. You can install custom versions of whatever you want to/usr/local and the system won't touch it or you can make your own packages that integrate nicely with the system. You can easily download the sources to the existing packages with apt-get source, modify them, build, and install with minimal labor. Your customizations in/etc will not be overwritten without your express permission (it's considered a serious bug otherwise). You can piece together pretty much any sort of system you like out of Debian, which is part of why it's proven to be so massively popular to derive and customize from.
Sure, a default install is tailored to specific scenarios, but Debian remains one of the most flexible Linux distros around.
Funny, I don't think I've ever heard of setting up 5.1 Surround Sound as being something "average" people do. Most people tend to think "average" means doing things like writing in a word processor or checking email in a web browser or playing music. All of these work out of the box in Debian and any other linux system (mp3 codec issues aside, which aren't a "linux" problem, you can always pay for Linspire if you want those out of the box). The centralized Debian model works amazingly well for such people because it promotes a higher level of quality control than the average decentralized Windows installation. It's not perfect though. For most people, linux suits their needs just fine because they're not windows power users like you are.
There are definitely still problems, but a few years ago we didn't even have a web browser or hotpluggable automounting devices. Only a few months ago, we didn't have a reasonable rendering infrastructure to compete with OSX or vista. If nothing else, Linux pushes forward and breaks barriers one by one. It's ready for a lot of desktops right now, and it'll be ready for even more in the coming years.
This is an issue with the Xorg i810 driver, and it's being remedied there. A beta version of the driver (xserver-xorg-video-i810-modesetting) is already available in the Debian unstable branch, and it'll be ready by the next Debian release.
You want the masses to migrate to Linux? Make application installations "point and click" operations, including all necessary dependency checks and library installations as part of that initial click of the mouse button. Installing apps has to be that easy.
Using an apt frontend of your choice really is that easy though. This author has gone out of his way to do things in a weird way, the same way it would be weird and difficult to set up an apt-like system for windows. That's what has made it hard for him. Installing software on Debian is insanely easy, provided you don't try and do things in a bizarre way, same as any other system. Just because you consider double-clicking setup.exe more normal than running synaptic doesn't mean that it's the right way to do things. People can and will learn if they make the move.
The problem with this article is that the guy clearly wants linux to work just like windows. That's all well and good, but it misses out on the real benefits of the linux (and debian) approach entirely. Still, it's nice to actually see someone write a positive article about Debian for a change.
Xorg is still broken in this regard. Happily, the new randr that's currently being worked on will begin to fix finally. Look for driver support to start appearing for it in the Xorg 7.3 release.
Because we're all on the same team. Poaching people from other projects simply isn't done not only because their work will benefit you even if they're working elsewhere, but also because it shows a lack of faith and friendship with other projects who depend on those people. What Mark did was very tacky, and anyone who doesn't recognize why probably isn't involved in any substantial way on a large free software project.
Trademark law requires that the name be different enough to not cause confusion. As a result, FreeFox or FireFaux or any of the other similar ones might cause problems and just result in Debian having to rename it yet again.
How is Debian bending over backwards to work with one of the top OSS projects to date? What exactly would "Debian" be sacrificing? As an end user I certainly have the ability to change the default trademarked FF icon if I wanted to.
Debian would be sacrificing the ability to patch firefox as need be. It would be sacrificing the ability to patch firefox for security issues in a timely manner. It would be sacrificing the ability to backport patches to the stable release's firefox so that stable users' browser doesn't change out from under them unexpectedly. It would be sacrificing the ability to freely modify the source code as they see fit without running those changes by mozilla.org first. It would be sacrificing the ability to allow distributions that rely and build on Debian, including Ubuntu, to have these rights. What the Debian firefox maintainer has chosen is to protect those rights not only for himself, but for all users of Debian, including Ubuntu.
As for you being able to change the firefox logo if you want, yes you can. But then you can't distribute the result of that change and call it firefox. With Debian Iceweasel you could though. That is the point of this whole thing, to protect your rights as a user.
None of this is to say that the Mozilla folks are wrong or bad or anything of that sort. This is just a conflict of interests. But please try to recognize that Debian is making this decision because it believes it is the best course of action for the users of Debian, including derived distributions like Ubuntu.
Lilypond is a fraction of the size and complexity of Debian. When you have a large and diverse group of developers involved, who gets paid and who doesn't can cause friction. And not everyone can get paid in a project like Debian, it's far too large.
The X featureset is pretty close to frozen actually. Xorg 7.2 will release far too close to the Etch release to actually make it in, so 7.1+updates is what will ship with Etch. The only features for X that are still being considered are related to what the article mentioned (XGL, AIGLX, and compiz).
Other than that, I don't understand why the --enable-compositor compile-time option isn't included by default. Logically, if the support is there, but the hardware isn't up-to-par or the X composite extention is not loaded, then the compositor just won't do anything. If everything is A-OK, then the compositor works as expected. For example, I compile support for my sound card directly into my kernel. One day, if I suddenly remove the sound card, my kernel will still work. So why not just turn stuff on by default?
I'd imagine it's because composite is extremely slow unless you're running a video driver with EXA, or running AIGLX or Xgl. The extension can still be loaded by the X server under these circumstances, and it would make metacity absolutely crawl. Ideally AIGLX and driver support will be improved to the point where this isnt an issue in the future, but for now I can see why they don't enable it. Ideally, I think it should be compiled in by default, but switched off by an option (most likely only in gconf while it's still experimental).
Slashdot Mirror
Debian isn't geared towards 'more effort' or else tools like apt wouldn't have come out of the project. It's geared towards doing things at a high quality, which often necessitates some time and effort to get right. The grandparent's point about automatix is a valid one. Many Ubuntu devs are also Debian devs, and so they carry the emphasis on quality with them, which is why the restricted device manager is as good as it is, in contrast to automatix.
dpkg and apt work fine. It's the packaging scripts themselves that are often broken. This is why Debian has various development suites to help make these packaging scripts work properly. Ubuntu grabs packages from Debian when they're in a pre-release state. Normally that's fine and they work well, but you can end up with problems because the Debian developers who are following their own release schedule haven't necessarily fixed the bugs that might hit Ubuntu. Additionally, it doesn't look like the Ubuntu development branches get as much wide-spread testing as the corresponding Debian branches, so it might be that no one is aware of bugs like this before they release. Finally, there's a lot of crappy and overly complicated packaging out there (automatix falls under both categories) that is just crawling with bugs.
None of the major linux distros actually ship their driver. In addition, Debian does have it in non-free, and it's very actively supported there.
The stuff in experimental is really not polished yet. It hasn't been released upstream for a reason, after all, and the Debian packaging isn't really adapted to it yet. More importantly for Debian, no other driver besides the new intel supports randr 1.2 right now, so we'd have to special case a lot of things for that driver, which isn't really worthwhile right now. The Lenny cycle will be largely devoted to adapting to the new stuff going on at X.org including randr 1.2 and input hotplugging, but what's in experimental right now is just the first glimpses of what's in store.
We know it's a pain, and it's a major goal for the next release. The Debian X Strike Force burned the entire release cycle moving first from XFree86 to Xorg, and then from the monolithic Xorg to modular Xorg. By the time it all that was finished, about a year and a half had passed and there was a few months to polish things up for the release. During this time, essentially an entirely new team was built up (only one person from the team that worked on XFree86 in Sarge is still an active member) and there was huge changes as the entire codebase was repackaged for 7.0 and we moved from a private SVN repo to git.debian.org, which was no small feat while we did our best to keep the updates coming at a good pace.
So expect to see some improvements to this stuff in the next year or so. A lot of work is happening at X.org to improve autoconfiguration, and Debian is moving to help develop it and deliver it to the users. Lenny is going to be really exciting from this point of view.
Reading the first page of that thread made me stupider. You owe me 5 minutes and 3 IQ points. Just be glad I stopped when I did.
The new Frozen Bubble with network play is the update that restarted my addiction.
Second, Ubuntu is sticking with firefox just like RedHat, so even if there was a significant delta between Iceweasel and Firefox, which there isn't, that shouldn't affect Ubuntu.
Sure, a default install is tailored to specific scenarios, but Debian remains one of the most flexible Linux distros around.
Funny, I don't think I've ever heard of setting up 5.1 Surround Sound as being something "average" people do. Most people tend to think "average" means doing things like writing in a word processor or checking email in a web browser or playing music. All of these work out of the box in Debian and any other linux system (mp3 codec issues aside, which aren't a "linux" problem, you can always pay for Linspire if you want those out of the box). The centralized Debian model works amazingly well for such people because it promotes a higher level of quality control than the average decentralized Windows installation. It's not perfect though. For most people, linux suits their needs just fine because they're not windows power users like you are.
There are definitely still problems, but a few years ago we didn't even have a web browser or hotpluggable automounting devices. Only a few months ago, we didn't have a reasonable rendering infrastructure to compete with OSX or vista. If nothing else, Linux pushes forward and breaks barriers one by one. It's ready for a lot of desktops right now, and it'll be ready for even more in the coming years.
The problem with this article is that the guy clearly wants linux to work just like windows. That's all well and good, but it misses out on the real benefits of the linux (and debian) approach entirely. Still, it's nice to actually see someone write a positive article about Debian for a change.
Xorg is still broken in this regard. Happily, the new randr that's currently being worked on will begin to fix finally. Look for driver support to start appearing for it in the Xorg 7.3 release.
Because we're all on the same team. Poaching people from other projects simply isn't done not only because their work will benefit you even if they're working elsewhere, but also because it shows a lack of faith and friendship with other projects who depend on those people. What Mark did was very tacky, and anyone who doesn't recognize why probably isn't involved in any substantial way on a large free software project.
The list of talks that should be on the DVD is here.
Why is it that the Mozilla representative never gave Debian this option?
How many bugs does it take to fork a project?
Trademark law requires that the name be different enough to not cause confusion. As a result, FreeFox or FireFaux or any of the other similar ones might cause problems and just result in Debian having to rename it yet again.
As for you being able to change the firefox logo if you want, yes you can. But then you can't distribute the result of that change and call it firefox. With Debian Iceweasel you could though. That is the point of this whole thing, to protect your rights as a user.
None of this is to say that the Mozilla folks are wrong or bad or anything of that sort. This is just a conflict of interests. But please try to recognize that Debian is making this decision because it believes it is the best course of action for the users of Debian, including derived distributions like Ubuntu.
Lilypond is a fraction of the size and complexity of Debian. When you have a large and diverse group of developers involved, who gets paid and who doesn't can cause friction. And not everyone can get paid in a project like Debian, it's far too large.
The X featureset is pretty close to frozen actually. Xorg 7.2 will release far too close to the Etch release to actually make it in, so 7.1+updates is what will ship with Etch. The only features for X that are still being considered are related to what the article mentioned (XGL, AIGLX, and compiz).