The use of the Debian trademark without permission, and the laughable claim that calling it "DCC" where "DCC stands for Debian Common Core" avoids infringement (rather than, say, getting involved in discussion and not using the Debian name until it's resolved)
"Will the DCC "fork" the Debian project?
No."
Except it will. It won't be a big fork. The only packages of any consequence that aren't identical to the Debian ones are X and the kernel. But it's still a fork. Denying that merely panders to the idea that forking is somehow inherently bad, rather than being an entirely natural process in free software development.
Eh? I'm not saying that at all. I'm entirely in favour of what the DCC's doing. What I'm not in favour of is calling it Debian when it's not, and saying that it's not a fork when it is.
(To clarify further - there's nothing wrong with forking)
I like a good top down solution with centralized control because it "just works" and you don't have to worry about weirdo incompatibilities since you define compatibility.
Like, say, SMTP, NNTP or any of the other decentralised protocols that the Internet is built upon?
I'm not going to argue that a decentralised solution is inherently better (I can think of a few reasons why I'd benefit, but this probably isn't the case for most users), but the Internet has shown that services don't need to be centralised in order to work.
Because in the ACPI world, information stored in the BIOS is used for a wide variety of tasks during kernel runtime. How do you think the kernel learns how your interrupts are wired? How does it know what power saving modes your motherboard and processors support? For that matter, how does it know how many processors you have in the first place? All of this information is stored in tables in the BIOS, and a lot of the time vendors get it wrong in earlier BIOS revisions.
Because my laptop at home has a QWERTY keyboard, and my machine at work has a Dvorak one. My home desktop is also Dvorak, but I almost never touch it now.
The madwifi drivers are not entirely Free - there's a large closed section of driver that runs on the host processor (it's not merely firmware for the card). People are working on drivers for the softmac prism54s, the Intel 2200 has an entirely open driver (but awkward restrictions on distributing the firmware. Thanks, Intel), there's an experimental driver for TI's acx111 hardware, and the RT2500 is an 11g part.
Yes. Since I haven't tested every single piece of hardware on the market, I'm extrapolating. Based on my experience, I have no reason to believe that the underrepresented vendors are especially good or bad, and so the overall ratio of working/non-working machines should be similar.
As long as your Powerbook doesn't have nvidia graphics, it should work fine with a sufficiently recent kernel.
This isn't true for the majority of semi-decent hardware. Most resume failures are entirely down to Linux not resuming the IDE controller properly, with most of the remainder being video and i8042 related.
ACPI sleep works on most modern laptops. http://www.ubuntulinux.org/wiki/HoaryPMResults has rather more "Yes" entries than "No" ones, and a large number of the failures are now well understood. Toshiba, IBM and (surprisingly) Sony seem to be good for ACPI support. For HP, it depends on the range - a lot of their hardware is very different. Older Dells seem good, and some of their modern stuff works without problems.
Debian's income is larger than its outgoings. Money is good to have - it means that we can deal with hardware failures, get more people to conferences, and pay the fees for some industry representation bodies, but we don't need vast amounts of it. We've currently got about as much in reserve as we could possibly want.
Ubuntu ought to have good support on most Toshibas - however, there's a couple of Toshibas that appear to be made by another manufacturer and then rebadged. Those ones work less well.
If you want to experiment with ACPI sleep under Ubuntu, just edit/etc/default/acpi-support
and uncomment the ACPI_SLEEP line. Reboot, then hit the suspend to RAM key. It's not guaranteed to work (which is why it's disabled by default), but you have a decent chance of success.
Linux ignores the BIOS and uses it's own calls to talk to the hardware.
For ACPI? No. For APM? Really, really no.
ACPI sleep works well on about 75% of laptop hardware, though you have to go through some contortions to get the video back. Another 10% or so reboot immediately on resume for reasons that aren't understood yet. The others have a variety of issues, mostly on resuming IDE. Most hardware ought to work reasonably well in 6 months or so. We're already way beyond where we were 6 months ago.
Ok. Not to suggest that your efforts aren't worthwhile, but that doesn't really put you in the league of Ubuntu, the Debian-edu backers, Progeny, Linspire or any of the other groups that spend money on employing Debian developers. Is that something that's going to change in the future?
That's an interesting thing to say. You haven't posted to debian-project or debian-devel this year. There are only three Debian bug reports mentioning Userlinux - two are by the same person and turned out to be due to a bug in Vmware, and the third is from a Userlinux developer who wants some extra fields in the default Samba config file. He didn't supply a patch. In fact, I can't find a single case of a patch being submitted with a note stating that it came from Userlinux.
So, what are you doing to help? What solid technical improvements have Userlinux made to Debian? Will the money earned by offering certifications and support go into improving security support in Debian?
I'm already seeing Ubuntu gain adoption and support by commercial vendors. They've also put a great deal of code and money into Debian. What real, tangiable advantage will Userlinux provide over them?
Slashdot Mirror
No."
Except it will. It won't be a big fork. The only packages of any consequence that aren't identical to the Debian ones are X and the kernel. But it's still a fork. Denying that merely panders to the idea that forking is somehow inherently bad, rather than being an entirely natural process in free software development.
Eh? I'm not saying that at all. I'm entirely in favour of what the DCC's doing. What I'm not in favour of is calling it Debian when it's not, and saying that it's not a fork when it is. (To clarify further - there's nothing wrong with forking)
I like a good top down solution with centralized control because it "just works" and you don't have to worry about weirdo incompatibilities since you define compatibility. Like, say, SMTP, NNTP or any of the other decentralised protocols that the Internet is built upon? I'm not going to argue that a decentralised solution is inherently better (I can think of a few reasons why I'd benefit, but this probably isn't the case for most users), but the Internet has shown that services don't need to be centralised in order to work.
Because in the ACPI world, information stored in the BIOS is used for a wide variety of tasks during kernel runtime. How do you think the kernel learns how your interrupts are wired? How does it know what power saving modes your motherboard and processors support? For that matter, how does it know how many processors you have in the first place? All of this information is stored in tables in the BIOS, and a lot of the time vendors get it wrong in earlier BIOS revisions.
Because my laptop at home has a QWERTY keyboard, and my machine at work has a Dvorak one. My home desktop is also Dvorak, but I almost never touch it now.
I have QWERTY at home at Dvorak at work. Switching has never been a problem.
It's likely that third party companies will happily sell you support for beyond that period.
Your average NiMH AA is only 1.2 Volts. 1500mAh at 10 Volts is a lot more energy than 2300mAh at 1.2.
The madwifi drivers are not entirely Free - there's a large closed section of driver that runs on the host processor (it's not merely firmware for the card). People are working on drivers for the softmac prism54s, the Intel 2200 has an entirely open driver (but awkward restrictions on distributing the firmware. Thanks, Intel), there's an experimental driver for TI's acx111 hardware, and the RT2500 is an 11g part.
Yes. Since I haven't tested every single piece of hardware on the market, I'm extrapolating. Based on my experience, I have no reason to believe that the underrepresented vendors are especially good or bad, and so the overall ratio of working/non-working machines should be similar. As long as your Powerbook doesn't have nvidia graphics, it should work fine with a sufficiently recent kernel.
This isn't true for the majority of semi-decent hardware. Most resume failures are entirely down to Linux not resuming the IDE controller properly, with most of the remainder being video and i8042 related.
The only big vendor shipping with decent APM support nowadays is IBM. If you buy anything else, you need ACPI support for sleep.
ACPI sleep works on most modern laptops. http://www.ubuntulinux.org/wiki/HoaryPMResults has rather more "Yes" entries than "No" ones, and a large number of the failures are now well understood. Toshiba, IBM and (surprisingly) Sony seem to be good for ACPI support. For HP, it depends on the range - a lot of their hardware is very different. Older Dells seem good, and some of their modern stuff works without problems.
Debian's income is larger than its outgoings. Money is good to have - it means that we can deal with hardware failures, get more people to conferences, and pay the fees for some industry representation bodies, but we don't need vast amounts of it. We've currently got about as much in reserve as we could possibly want.
Ubuntu includes pbuttonsd and support for suspend to disk on PPC laptops.
Ubuntu ought to have good support on most Toshibas - however, there's a couple of Toshibas that appear to be made by another manufacturer and then rebadged. Those ones work less well.
/etc/default/acpi-support
If you want to experiment with ACPI sleep under Ubuntu, just edit
and uncomment the ACPI_SLEEP line. Reboot, then hit the suspend to RAM key. It's not guaranteed to work (which is why it's disabled by default), but you have a decent chance of success.
Linux ignores the BIOS and uses it's own calls to talk to the hardware. For ACPI? No. For APM? Really, really no. ACPI sleep works well on about 75% of laptop hardware, though you have to go through some contortions to get the video back. Another 10% or so reboot immediately on resume for reasons that aren't understood yet. The others have a variety of issues, mostly on resuming IDE. Most hardware ought to work reasonably well in 6 months or so. We're already way beyond where we were 6 months ago.
Try installing on something with an i915 chipset and video.
Why not ask Google?
Ok. Not to suggest that your efforts aren't worthwhile, but that doesn't really put you in the league of Ubuntu, the Debian-edu backers, Progeny, Linspire or any of the other groups that spend money on employing Debian developers. Is that something that's going to change in the future?
We're trying to help.
That's an interesting thing to say. You haven't posted to debian-project or debian-devel this year. There are only three Debian bug reports mentioning Userlinux - two are by the same person and turned out to be due to a bug in Vmware, and the third is from a Userlinux developer who wants some extra fields in the default Samba config file. He didn't supply a patch. In fact, I can't find a single case of a patch being submitted with a note stating that it came from Userlinux.
So, what are you doing to help? What solid technical improvements have Userlinux made to Debian? Will the money earned by offering certifications and support go into improving security support in Debian?
I'm already seeing Ubuntu gain adoption and support by commercial vendors. They've also put a great deal of code and money into Debian. What real, tangiable advantage will Userlinux provide over them?