Re:incompetent people running the government are a
on
When Not to Use chroot
·
· Score: 1
Well, if the country in which you abide purports to be a democracy, then you have a stake in ensuring that incompetent people don't run the government.
There are workarounds. I use PulseAudio (hooked to an ALSA backend nonetheless) with the alsa-lib pulse plugin, and PulseAudio can use any number of backends including OSS.
Universe and multiverse receive no official core-dev support by default; they're community supported. A few of us have spent time with -updates and -security for universe, but we could use assistance.
Breezy (5.10) uses hotplug and udev. This is the nice, comfortable way with which most people using Linux 2.6 are probably at least vaguely familiar. Dapper (6.06) has ditched hotplug and uses udev. Why? Linux 2.6.15 and udev perform everything that the older 2.6.12 kernel, udev, and hotplug performed. Read more here [0].
Next, Dapper currently has v1.1.1 of the ipw2200 driver, and it supports "wardriving" just fine.
The X Window System is a huge component of the Ubuntu desktop. If you begin with Warty (4.10), the first official release, then attempt to grab Firefox from Dapper (6.06) using the current development release's updated package list, apt-get/aptitude/Synaptic/Adept will perform, essentially, a dist-upgrade for you, which means that you'll have XFree86 replaced by X.Org 7.0. In this example, no, there is no piecemeal upgrade possible in a simplistic and no-brainer manner.
Please give a daily build of the live CD (http://cdimage.ubuntu.com/daily-live/current/) a whirl if you have time, and be sure to update your packages using System> Administration> Update Manager. A slew of GNOME 2.12.1 packages were uploaded today (including Evolution updates). If you can still reproduce your issues, please file bugs in Ubuntu's Bugzilla. Thanks!
By default, the applet is configured to check every day, so an icon will appear in the system notification area if there are updates. In other words, your suggestion was implemented some time ago.
Just to clarify, of the major 'main' packages only linux-image and linux-restricted-modules are compiled with GCC 3.4. With very few exceptions, all the remaining packages in 'main', 'universe', and 'multiverse' are compiled with GCC 4 - from GNOME to KDE, from Xfce to Enlightenment and other things you can shake a stick at.
"Automatically" - as in without you clicking anything? No. You'll still have to click System> Administration> Update Manager, then choose to install the updates. (Or you could use System> Administration> Synaptic.) Then you'll be running Breezy/5.10 as if you had installed it from an install CD.
The counterpart is Masters of Main (MOM); "main" is the repository officially supported by Ubuntu. "Universe" is not supported by Ubuntu; the community and ourselves (the team, MOTU), have that honour.:)
I'm part of the Ubuntu (Masters of the Universe) MOTU Xfce team, and after 4 consecutive nights of merging, Xfce 4.2.1.1 (based on Xfld) is installable from your friendly neighborhood Ubuntu mirror. Enabling universe, updating, and installing 'xfce4' is all it takes.
I'm one of the universe maintainers (Masters of the Universe, or MOTU).
Ubuntu, being a Debian-based distribution, _can_ work with general apt (.deb) repositories. Whether one _should_ add such to one's sources.list is a completely different matter. Ubuntu's repos are tuned for our (Ubuntu) packages. Adding in external repos very well will result in massive dependency headaches (unless you're skilled with apt pinning, but even that can get messy - my home machine is Sid+experimental+Hoary base, Sid since '98, and I've snagged my share of "oh crap"s) - the notorious Ubuntu Backports used to be a source of much weeping and gnashing of teeth, though they've fixed many of the versioning problems that would have wrought insanity with a dist-upgrade.
Roughly speaking, we regularly sync with Debian Sid as a base, then work from that. For the universe packages, we sync (and merge) as often as we need to ("need" determined by the amount of effort required to backport versus simply merging a new sync from Sid). We have a system for requesting that new packages be synced from Sid. We also have "quite a few" packages that are newer than their counterparts, if they exist, in Sid. The development branch of Ubuntu tracks Sid regularly, but not all of Sid is in said development branch (though it's pretty darned close to being "all").
As part of the team that oversees nearly 15000 packages just for Hoary Universe, it's difficult to do extensive QA, but we're getting to the point where, through inviting new members to join our universe maintainer team and automated regression testing, we can make that a reality (http://higgs.djpig.de/ubuntu/www/ truly is wonderful). My colleagues are a great bunch.
The core Ubuntu team is very small - closer to two handfuls. Nearly all (if not all) of that team _are_ Debian developers (DDs). The universe team currently is as large or larger than that core team, but this latter group is volunteer-based (there are a couple DDs among us). As part of this team of "masters of the universe" (MOTU), it has been tremendously daunting to attempt to wade through nearly fifteen thousand packages for Hoary's upcoming release. We have great support from the core team, however, and we (our universe team) are as tight-knit as we are warmly welcoming of freshmen. Of course, the user community is lively and respectfully helpful, which ultimately is a rather significant impetus to join the larger Ubuntu team either as a member or a maintainer. Ubuntu makes the process of getting involved straightforward.
Ubuntu uses Debian-developed tools and contributes modifications back to Debian. Nearly everything that Ubuntu develops and uses is fed directly back into Debian - the core developers, again, are DDs. Universe's new bug tracking system, Malone, will facilitate this integration between Debian's BTS and the Debian and Ubuntu pools.
Through Hoary, the Ubuntu installers largely are based on the revamped Debian Sarge installer. There's no pretty gui yet. The Ubuntu installer aims to be streamlined and unintrusive - a few questions and you're on your way.
End-wise, however, Debian and {K}Ubuntu pursue different courses. Debian is not outdated. {K}Ubuntu {are}is not going to make Debian outdated.
Ultimately, we're using a Linux distribution. Diversity isn't a killer; it's a feature!
The question is not whether installing packages from "any old" repository will work, because (obviously) well-versioned and checked packages will install and work fine if their exact dependencies are available, but rather if the upgrade path from one stable Ubuntu release to another is not made more difficult by installing packages from external repositories. This issue is definitely the most constraining regarding http://ubuntu-bp.sourceforge.net/ . Even my own Warty backported packages, while I await 'universe' upload privileges, need to be reversioned correctly such that a user who uses my Warty mplayer backports will dist-upgrade smoothly to Hoary.
My MSc thesis implemented a grid service for (non-computer science) computational scientists through Globus (V3.2) that harnessed a Condor (V6.6) backend for a heterogeneous computational grid. Here at the university, because funds are not exactly forthcoming, we utilize idle resources in computer labs and classrooms.
It's not just hardware: the amount of non-parallelizable code in parallel applications impacts scalability most tremendously.
The upper bound on speedup is generally Amdahl's law. Plainly, the efficiency approaches zero as the number of processes is increased. Generally we consider the major sources of overhead to be communication, idle time, and extra computation. Interprocess communication is considered negligible for serial programs in this context (we consider message passing). Idle time ends up contributing to overhead, because processes idle awaiting information from others. Extra computation is virtually unavoidable at some point; for instance in MPI's Single Program Multiple Data model, each process in tree-structured communication other than the root is eventually idled prior to the completion of computation, and each process determines IPC at some point based on rank.
There are notable exceptions to Amdahl's law, however; Gustafson, Montry and Benner wrote about such in Development of parallel methods for a 1024-processor hypercube, SIAM Journal on Scientific and Statistical Computing 9(4):609-638, 1988.
One reply mentioned kerneltrap.org, which is excellent. I also recommend lwn.net's weekly edition, which is available initially only to lwn.net subscribers. It becomes freely available to everyone one week after its initial publication date every Thursday. Not only does it cover weekly news in Linux (the kernel, here) but also in security, noteworthy applications and announcements from OSS land and distros in particular. Look here for last week's edition, and note how concise yet illuminating Jonathan's style is. Please subscribe; lwn.net kicks major butt.
Fixed references (& relevant debian-security u
on
Kernel 2.4.26 Out
·
· Score: 2, Informative
Philippe Troin is one of many who crossed-checked the CAN list. Here are the relevant fixes in 2.4.26.
The question is more aptly (no pun intended) phrased in terms of why _wouldn't_ someone move from * to Linux. Just as there is no One True High-Level Programming Language for Every Problem, there is no One True Operating Environment for Every System.
From what we've been tracing, it actually looks like a bug in newer VIA chipsets triggerable in both 2.4 and 2.6 kernels. The patches at minion.de have a workaround for now.
To be fair, not even the technical consultant types and the security "experts" get it right all the time. The real world is very, very different from the edges of theory.
Furthermore, just because someone has "at most" a degree in English doesn't mean fresh insight hasn't been exposed. Narrow-minded elitism gets us nowhere.
Slashdot Mirror
Well, if the country in which you abide purports to be a democracy, then you have a stake in ensuring that incompetent people don't run the government.
There are workarounds. I use PulseAudio (hooked to an ALSA backend nonetheless) with the alsa-lib pulse plugin, and PulseAudio can use any number of backends including OSS.
See http://pulseaudio.org/ .
I haven't investigated the Flash 9 beta myself, but another poster reports http://linux.slashdot.org/comments.pl?sid=201501&c id=16499733 that the -dev packages are still required.
Universe and multiverse receive no official core-dev support by default; they're community supported. A few of us have spent time with -updates and -security for universe, but we could use assistance.
Let's clear up the misrepresentation.
n ounce/2005-December/000028.html
Breezy (5.10) uses hotplug and udev. This is the nice, comfortable way with which most people using Linux 2.6 are probably at least vaguely familiar. Dapper (6.06) has ditched hotplug and uses udev. Why? Linux 2.6.15 and udev perform everything that the older 2.6.12 kernel, udev, and hotplug performed. Read more here [0].
Next, Dapper currently has v1.1.1 of the ipw2200 driver, and it supports "wardriving" just fine.
[0] https://lists.ubuntu.com/archives/ubuntu-devel-an
The X Window System is a huge component of the Ubuntu desktop. If you begin with Warty (4.10), the first official release, then attempt to grab Firefox from Dapper (6.06) using the current development release's updated package list, apt-get/aptitude/Synaptic/Adept will perform, essentially, a dist-upgrade for you, which means that you'll have XFree86 replaced by X.Org 7.0. In this example, no, there is no piecemeal upgrade possible in a simplistic and no-brainer manner.
You need to click Reload.
$ evolution --version
Gnome evolution-2.4 2.4.1
Please give a daily build of the live CD (http://cdimage.ubuntu.com/daily-live/current/) a whirl if you have time, and be sure to update your packages using System> Administration> Update Manager. A slew of GNOME 2.12.1 packages were uploaded today (including Evolution updates). If you can still reproduce your issues, please file bugs in Ubuntu's Bugzilla. Thanks!
By default, the applet is configured to check every day, so an icon will appear in the system notification area if there are updates. In other words, your suggestion was implemented some time ago.
Just to clarify, of the major 'main' packages only linux-image and linux-restricted-modules are compiled with GCC 3.4. With very few exceptions, all the remaining packages in 'main', 'universe', and 'multiverse' are compiled with GCC 4 - from GNOME to KDE, from Xfce to Enlightenment and other things you can shake a stick at.
"Automatically" - as in without you clicking anything? No. You'll still have to click System> Administration> Update Manager, then choose to install the updates. (Or you could use System> Administration> Synaptic.) Then you'll be running Breezy/5.10 as if you had installed it from an install CD.
That's part of the humour. ;)
The counterpart is Masters of Main (MOM); "main" is the repository officially supported by Ubuntu. "Universe" is not supported by Ubuntu; the community and ourselves (the team, MOTU), have that honour. :)
I'm part of the Ubuntu (Masters of the Universe) MOTU Xfce team, and after 4 consecutive nights of merging, Xfce 4.2.1.1 (based on Xfld) is installable from your friendly neighborhood Ubuntu mirror. Enabling universe, updating, and installing 'xfce4' is all it takes.
I'm one of the universe maintainers (Masters of the Universe, or MOTU).
Ubuntu, being a Debian-based distribution, _can_ work with general apt (.deb) repositories. Whether one _should_ add such to one's sources.list is a completely different matter. Ubuntu's repos are tuned for our (Ubuntu) packages. Adding in external repos very well will result in massive dependency headaches (unless you're skilled with apt pinning, but even that can get messy - my home machine is Sid+experimental+Hoary base, Sid since '98, and I've snagged my share of "oh crap"s) - the notorious Ubuntu Backports used to be a source of much weeping and gnashing of teeth, though they've fixed many of the versioning problems that would have wrought insanity with a dist-upgrade.
Roughly speaking, we regularly sync with Debian Sid as a base, then work from that. For the universe packages, we sync (and merge) as often as we need to ("need" determined by the amount of effort required to backport versus simply merging a new sync from Sid). We have a system for requesting that new packages be synced from Sid. We also have "quite a few" packages that are newer than their counterparts, if they exist, in Sid. The development branch of Ubuntu tracks Sid regularly, but not all of Sid is in said development branch (though it's pretty darned close to being "all").
As part of the team that oversees nearly 15000 packages just for Hoary Universe, it's difficult to do extensive QA, but we're getting to the point where, through inviting new members to join our universe maintainer team and automated regression testing, we can make that a reality (http://higgs.djpig.de/ubuntu/www/ truly is wonderful). My colleagues are a great bunch.
The core Ubuntu team is very small - closer to two handfuls. Nearly all (if not all) of that team _are_ Debian developers (DDs). The universe team currently is as large or larger than that core team, but this latter group is volunteer-based (there are a couple DDs among us). As part of this team of "masters of the universe" (MOTU), it has been tremendously daunting to attempt to wade through nearly fifteen thousand packages for Hoary's upcoming release. We have great support from the core team, however, and we (our universe team) are as tight-knit as we are warmly welcoming of freshmen. Of course, the user community is lively and respectfully helpful, which ultimately is a rather significant impetus to join the larger Ubuntu team either as a member or a maintainer. Ubuntu makes the process of getting involved straightforward.
Ubuntu uses Debian-developed tools and contributes modifications back to Debian. Nearly everything that Ubuntu develops and uses is fed directly back into Debian - the core developers, again, are DDs. Universe's new bug tracking system, Malone, will facilitate this integration between Debian's BTS and the Debian and Ubuntu pools.
Through Hoary, the Ubuntu installers largely are based on the revamped Debian Sarge installer. There's no pretty gui yet. The Ubuntu installer aims to be streamlined and unintrusive - a few questions and you're on your way.
End-wise, however, Debian and {K}Ubuntu pursue different courses. Debian is not outdated. {K}Ubuntu {are}is not going to make Debian outdated.
Ultimately, we're using a Linux distribution. Diversity isn't a killer; it's a feature!
The question is not whether installing packages from "any old" repository will work, because (obviously) well-versioned and checked packages will install and work fine if their exact dependencies are available, but rather if the upgrade path from one stable Ubuntu release to another is not made more difficult by installing packages from external repositories. This issue is definitely the most constraining regarding http://ubuntu-bp.sourceforge.net/ . Even my own Warty backported packages, while I await 'universe' upload privileges, need to be reversioned correctly such that a user who uses my Warty mplayer backports will dist-upgrade smoothly to Hoary.
My MSc thesis implemented a grid service for (non-computer science) computational scientists through Globus (V3.2) that harnessed a Condor (V6.6) backend for a heterogeneous computational grid. Here at the university, because funds are not exactly forthcoming, we utilize idle resources in computer labs and classrooms.
It's not just hardware: the amount of non-parallelizable code in parallel applications impacts scalability most tremendously.
The upper bound on speedup is generally Amdahl's law. Plainly, the efficiency approaches zero as the number of processes is increased. Generally we consider the major sources of overhead to be communication, idle time, and extra computation. Interprocess communication is considered negligible for serial programs in this context (we consider message passing). Idle time ends up contributing to overhead, because processes idle awaiting information from others. Extra computation is virtually unavoidable at some point; for instance in MPI's Single Program Multiple Data model, each process in tree-structured communication other than the root is eventually idled prior to the completion of computation, and each process determines IPC at some point based on rank.
There are notable exceptions to Amdahl's law, however; Gustafson, Montry and Benner wrote about such in Development of parallel methods for a 1024-processor hypercube, SIAM Journal on Scientific and Statistical Computing 9(4):609-638, 1988.
One reply mentioned kerneltrap.org, which is excellent. I also recommend lwn.net's weekly edition, which is available initially only to lwn.net subscribers. It becomes freely available to everyone one week after its initial publication date every Thursday. Not only does it cover weekly news in Linux (the kernel, here) but also in security, noteworthy applications and announcements from OSS land and distros in particular. Look here for last week's edition, and note how concise yet illuminating Jonathan's style is. Please subscribe; lwn.net kicks major butt.
Philippe Troin is one of many who crossed-checked the CAN list. Here are the relevant fixes in 2.4.26.
module-init-tools plays well with modutils-2.4 just fine. I've been alternating 2.4 and 2.[56] kernels at work for quite some time.
Simply booting a new binary kernel image has no dependencies on binutils whatsoever.
And *never* remove your failsafe (eg. current working) kernel - even after your new one works.
The question is more aptly (no pun intended) phrased in terms of why _wouldn't_ someone move from * to Linux. Just as there is no One True High-Level Programming Language for Every Problem, there is no One True Operating Environment for Every System.
From what we've been tracing, it actually looks like a bug in newer VIA chipsets triggerable in both 2.4 and 2.6 kernels. The patches at minion.de have a workaround for now.
To be fair, not even the technical consultant types and the security "experts" get it right all the time. The real world is very, very different from the edges of theory.
Furthermore, just because someone has "at most" a degree in English doesn't mean fresh insight hasn't been exposed. Narrow-minded elitism gets us nowhere.