Slashdot Mirror
Domain: netsplit.com
Stories and comments across the archive that link to netsplit.com.
Comments · 10
-
Re:Automatix? Ugh
I was in the #ubuntu channel when people would say the following:
They had used automatix
Automatix had changed their system
People in #ubuntu had previously investigated and found out the reason their install was broken was a change automatix had made
They had gone to #automatix for help, explaining the situation.
#automatix turned them away, because #ubuntu had said it was their fault. Some were even banned from #automatix for suggesting it.
Just because you claim it isn't true, doesn't mean it isn't. A vast portion of issues with the Edgy upgrade were caused by the ubuntu-desktop package being removed, or a system file in main being overwritten -- in many of these situations, the root cause was found to be Automatix. Just because you claim the problem isn't there, and ban anyone that suggests it is, doesn't mean it doesn't exist.
See this blog entry, or the comments on this post or try Googling "Automatix Edgy dist-upgrade" -
Tough questions, although not tough enough
The interviewer asks some very good questions about the weak areas in Ubuntu-Canonical's business strategy and Shuttleworth has to dodge many questions and hide behind half-truths, handwaving and his usual marketing gobbledygook.
Ubuntu allegedly has a "policy of not doing our own software development, but only packaging what others have developed" -- with the few rare exceptions like the Upstart init system. Ubuntu-Canonical doesn't hire any top developers to do upstream development like some other commercial distros, Red Hat and Novell, do. For this precise reason, the GNOME hacker Jeff Waugh had to leave Ubuntu when he wanted to concentrate on developing GNOME.
Given this background, I'm inclined to believe that Shuttleworth is heavily distorting the reality when he claims that a lot of KDE 4 development is now happening inside of Ubuntu. This is one of the several points where I would have wished the interviewer to be a bit tougher and to push a bit harder in order to dig out the truth behind Shuttleworth's marketing talk. Of course, if Ubuntu-Canonical has indeed changed their policy lately and if they are now hiring KDE developers to do upstream development for KDE 4, then this revelation would have greatly added the news value of the interview. It's unfortunate that the interviewer didn't push this question (and some other questions) any further but, instead, left Shuttleworth's dubious claims open for speculations.
-
Re:launchd
Replying to my own post? Nice. I found this comparison between upstart and launchd. Long story short, launchd isn't event driven.
-
Re:Ubuntu
Ubuntu may always be "free of charge," but that doesn't mean it will always be free in the way that really matters. The Ubuntu team has already begun shipping binary blobs in the kernel, non-free wireless drivers, and proprietary nvidia drivers in their standard, default setup. Debian's primary goal is to be a free (as in free speech) operating system, and as Ubuntu diverges from that fact, it becomes difficult to argue that they're truly "part of the Debian family."
-
Re:On the other hand...
I 2nd this statement. In fact, Mark Shuttleworth and Ubuntu have already begun doing things that undermine the idea of free software. For example, Ubuntu now ships with binary blobs in the kernel, non-free wireless drivers, and proprietary nvidia drivers (for which free alternatives readily exist.) See Scott James Remnant's blog for details. Likewise, it's been reported and substantiated that Mark Shuttleworth is preventing the Debian GNOME maintainer (who also works for Canonical) from updating GNOME packages until after Ubuntu LSO had shipped. Of the two top committees governing Ubuntu, the Ubuntu Community Council and the Technical Board, are both made up of Mark Shuttleworth and people he employs, and Shuttleworth has been given "benevolent dictator for life" status within the project. A lot of people do not trust Shuttleworth either, and some, such as Debian Developer, Otavio Salvador, have made comments like, "what he says and what he does are different." You should be wary of supporting Shuttleworth's efforts as there's good reason to question his commitment to the ideals of free software and to the interests of the rest of the community.
-
Re:Without Debian
Without Debian, where would we have the amazing, huge codebase for every Ubuntu, Jibbajabba, or Lilixinidros distribution out there?
No one is questioning the contribution Debian developers have made to the Linux ecosystem as a whole. The question is, is Debian able to do anything groundbreaking on its own anymore? If someone were to try to move to a new init system in Debian, how long would it take to actually get done?
Personally, I think Debian should embrace its role as a distribution that others derive from. It is doing an excellent job in that respect, and I don't think the current organizational structure of the project could allow it to function as anything else in a more effective way. If some of the developers would stop antagonizing Ubuntu and embrace it instead, I think we'd all be better off. -
Re:Concept Versus Implementation
Acording to this page Ubuntu is getting upstart.
http://www.netsplit.com/blog/work/canonical/upstar t.html -
The Ubuntu Car is not brown !
It's no more brown ! It's orange ! There is even a Dapper Car ! Of course, this was before! If you look closely, you will see that the car has 4 wheels. This is not true anymore as we are now all using flying cars.
BTW, there's even Ubuntu in Belgium now...
-
Haven't we debunked this before?
By default, programs installed with root privileges are placed in
I sure hope that's a typo forWhen a package is removed, its dependencies remain. Hearn and Lai point out that dependencies are not always removed by some other package management systems, either.
Some package management systems may not do that, but at least they keep track of exactly which packages have been installed so you at least have a chance of removing the dependencies at some point in time. With this solution you end up with files on your system that have no clear correspondence to any package, which kind of defeats the purpose of having a package in the first place. (To just expose my bias... aptitude, synaptic or deborphan anyone?)
"A binary from one distribution doesn't always work on another, because of things like glibc symbols and C++ ABI." [...] "Native package managers' dependency detection depends on a database. Autopackage, on the other hand-detects dependencies by actually scanning for them."
Right, and what exactly is autopackage going to do about these dependencies once it has found that they don't match up? Use LD_PRELOAD and have multiple copies of system libraries in place instead? Oh wait, autopackage is for "desktop packages only".
Of course, all of that isn't to say that autopackage may not do something useful in the future, but it sure looks like some of the fundamental problems of developing and distributing packages which other packaging systems have already dealt with still remain to be solved.
In any case, if you don't believe me, see what Scott Remnant has had to say on the matter (he's currently the dpkg maintainer, so he at least is passingly familiar with the issues surrounding a packaging format.) -
Haven't we debunked this before?
By default, programs installed with root privileges are placed in
I sure hope that's a typo forWhen a package is removed, its dependencies remain. Hearn and Lai point out that dependencies are not always removed by some other package management systems, either.
Some package management systems may not do that, but at least they keep track of exactly which packages have been installed so you at least have a chance of removing the dependencies at some point in time. With this solution you end up with files on your system that have no clear correspondence to any package, which kind of defeats the purpose of having a package in the first place. (To just expose my bias... aptitude, synaptic or deborphan anyone?)
"A binary from one distribution doesn't always work on another, because of things like glibc symbols and C++ ABI." [...] "Native package managers' dependency detection depends on a database. Autopackage, on the other hand-detects dependencies by actually scanning for them."
Right, and what exactly is autopackage going to do about these dependencies once it has found that they don't match up? Use LD_PRELOAD and have multiple copies of system libraries in place instead? Oh wait, autopackage is for "desktop packages only".
Of course, all of that isn't to say that autopackage may not do something useful in the future, but it sure looks like some of the fundamental problems of developing and distributing packages which other packaging systems have already dealt with still remain to be solved.
In any case, if you don't believe me, see what Scott Remnant has had to say on the matter (he's currently the dpkg maintainer, so he at least is passingly familiar with the issues surrounding a packaging format.)