How did you know what to type? You had to know what you were supposed to be looking for. That's not so cool for most users. What if I just want to be able to play some a DVD? Am I supposed to magically know that I need "libdvdcss" and "mplayer"?
There's nothing magical about it, you type 'apt-cache search dvd' and in the list is mplayer, you type 'apt-get install mplayer' and it grabs all of mplayer's dependencies including libdvdcss.
* apt-get depends extremly on the quality of the repository from which it grabs stuff, unofficial packages often cause throuble and if the maintainers of the repo to something ugly like removing a programm that you depend on, bad luck for you, there is no easy workaround, then to not use apt-get and do everything manually
How is that different than installing things manually? If the maintainer of a web site hosting the RPMs you were using decides to take them down you're just as screwed.
A solution to the dependcy hell would be one that is not distrospecific and allows me to download and install any Linux stuff I want from the net, not just the one that some Debian maintainers thought would be worth packaging. It should also allow to install any number of different versions of the same programm without relying on extra work of the maintainer to handle the situation.
So basically you want packages that create and manage themselves?
If distributions come together on key points such as those (and of course, I'm sure there's more I missed), then that will go a long way towards making packages distribution-neutral (and solving a whole slew of other problems).
It would also go a long way towards making every distribution the same, thus making all but one obsolete.
See the pattern? You still haven't given a general "how to install packages" guide that works on _Linux_ in general. You're still talking about a subset of Linux distributions.
Considering that the only way a sane person would use Linux is to install a distribution and a distribution is a collection of packages to run on the linux kernel it would make sense to leave package management at the distribution level.
But that's beside the point. Why should I have to edit config files to do install packages? Looks like this "simple guide to installing packages" is quickly spiraling out of control.
Because everything isn't available in ever repository for various reasons. And if you really want to avoid editing files run RedCarpet and use the pretty GUI. If all of this seems like spiraling out of control, perhaps you should shut the computer down and go do something slower.
Do you mean an RPM for your (I presume popular) distribution? Or did you mean an RPM that could work on pretty much any distribution?
If you don't like trying to determine which RPM goes where, install Debian and be done with it, in sid there's over 13K packages.
You could also look at ngrep, but learning tcpdump's filter syntax should probably be your first priority since you use it every day and it's available on just about every system.
Description: grep for network traffic
ngrep strives to provide most of GNU grep's common features,
applying them to the network layer. ngrep is a pcap-aware tool that
will allow you to specify extended regular expressions to match
against data payloads of packets. It currently recognizes TCP, UDP
and ICMP across Ethernet, PPP, SLIP and null interfaces, and
understands bpf filter logic in the same fashion as more common
packet sniffing tools, such as tcpdump and snoop.
I'm not suggesting a better gauge and I don't think data that bad should be used, perhaps if 1/4 of it wasn't 'unknown' it wouldn't be as bad but as it stands now there's more Debian developers than entries in popcon. I mean hell there's 36541 people registered to the debian-announce mailing list and even that's probably a small percentage of the total amount of Debian installations.
The minimum that needs to be done is to modify policy to require packages that can be optimised to have support for end users compiling optimised for themself.
Having precompiled optimised packages for every flavour of every architecture may place excessive burdens to the debian infrastructure.
May? Do you have any idea what the disk space requirements alone would be? And how far should it go? Should we have i486, i586 and i686 packages to make sure everyone's covered?
If you really want custom compiled packages either do it by hand for the few that might matter (apt-get source) or look at apt-build which can be setup to recompile everything on your system.
How can you ignore the unknown chunk, if it was smaller maybe but not since it's 1/4th of the submissions.
Anyway I run Debian on 3 non-i386 machines and none of them have popcon on them and considering the page says there's only just under 5000 submissions, way too few people have it installed and 1/4th of them mucked it up somehow so I'd say popcon isn't a good gauge for anything right now
As I mentioned in another post, the real problem comes when someone has a problem with their 'tainted' kernel. They post a backtrace or "my kernel hung" message to lkml and if it's marked tained the developers can say "talk to the company behind the binary-only driver, they have our source code but we don't have theirs" instead of wasting hours tracking down a bug that may or may not be fixable by them.
The drivers would work the same with a non-GPL license string, the problem is that when these drivers cause a problem and someone posts to lkml with a backtrace of an oops there's no quick way to tell that a binary-only module was involved so they may waste tons of time tracking down bugs they can't fix.
If the drivers would say they're non-GPL then the lkml people would be able to say "talk to LinuxAnt, they have our source code but we don't have theirs so we can't help you" and move on to problems they can actually fix.
If you would spend an extra 5 minutes you could have both. Just grab the src.rpm, it has the source and an already made-up.spec file, apply the patch (or include it in the.spec file so it's applied for you on build) and make a patched RPM. That way you still have consistency with the package database and you don't have vulnerable software.
That's not entirely true. Sure all the HTML rendering functions used by Windows help, Explorer, etc are implemented in MSHTML.dll but it's not impossible to register a different HTML renderer. Infact a while back someone wrote a Gecko ActiveX control that did all of that, you could register it and all those APIs would then call on Gecko for the rendering instead of MSHTML. But IIRC it was a huge PITA to keep the control up to date, and that combined with the general lack of interest made him stop maintaining it.
No, it's an advantage. If MS suddenly changed the MSHTML license that said it couldn't be used by free programs what would happen? The only choice would be to get a new HTML renderer like Gecko, because XFree is open source we can take the code that is still under the free license and fork a new copy under a free license.
XFree86 was a much bigger issue because so many things link against the X libraries, with Apache this only really affects apache modules, if even them.
The real question is what SP level was this fixed at? IE6 isn't vulnerable and I believe the leaked Win2K code was only SP1, so that means there's 3 SPs and all of them include IE so there's no telling when, if at all, the bug was fixed.
Blah blah. Looks like a microkernel. It's going to suck performancewise, but it'll be very easy to get soft realtime performance. Of course, a big question is whether this performance loss is significant in the big picture.
I realize it's possible, but it would be so slow compared to current performance it wouldn't be worthwhile. Drivers now are discourages from using copy_to_user and copy_from_user unless absolutely necessary, having every driver do that every interrupt would be insane. And since the kernel would need atleast 1/3 of the driver logic to bring up the hardware and deal with interrupts and errors you gain almost nothing.
XFree86 can easily cope with video cards running from a process by writing to/dev/kmem,/dev/port, etc. to do all necessary manipulations to switch screenmodes, set resolutions, set refresh rates, blit bitmaps.
But it's highly discouraged even for XFree to do that. With the new input system the kernel generates errors on the console because X fiddled with the keyboard directly when it's not supposed to.
What would be nice would be to give users the option of kernel/userspace drivers.
But the amount of work needed to convert them all and to maintain two sets of drivers would be huge and I'm sure just about noone would want to maintain it.
Personally, I'd probably end up using userspace drivers because I don't really need the highest maximum throughput to chat on irc, write some code, do some email, and browse the web, but I'd definitely appreciate the added insulation between the kernel and potentially bad drivers.
But it would gain you almost nothing. Almost every userspace driver would need the ability to put data into kernel memory somewhere for the mini-driver to hand off to the hardware so the potential for crashing the kernel is still there, it's just been moved around a bit.
And with all those added context switches and (previously) unnecessary memory copies I wouldn't be surprised if things like X and xmms started showing lag and higher latency than before, which is what most people use to judge how well the kernel is handling user interaction and general scheduling of things.
How would that even be possible? Take a NIC driver for instance, currently data from the NIC is retrieved from a certain memory address by a driver responding to an IRQ being raised. For your userland daemon idea to have any chance of working the kernel would still need a driver for the hardware to be able to initialize the hardware, respond to and acknowledge the IRQs, copy the data somewhere the userland daemon can handle it and probably other things I'm not thinking off.
At the very least the speed would make it impossible. context switches take a very long time, relative in the kernel, so imagine taking the amount of IRQs you can process per second and cutting by like a hundred or more.
Some things like modems and printers may be possible to have partial userland components, but most things need the kernel to initialize, setup and just generally manage the hardware in a way that's not possible from userland.
It's not neglected it's just there isn't the man power to reverse engineer every piece of hardware in existance to make a driver for it. Pretty much all the mainstream stuff is supported (some with a vendor driver like the nVidia driver) and if you need/want Linux support for something that doesn't have a driver talk to the manufacturer. Many companies like Intel, Dell, etc are writing and maintaing GPL'd drivers in the kernel these days.
Slashdot Mirror
There's nothing magical about it, you type 'apt-cache search dvd' and in the list is mplayer, you type 'apt-get install mplayer' and it grabs all of mplayer's dependencies including libdvdcss.
How is that different than installing things manually? If the maintainer of a web site hosting the RPMs you were using decides to take them down you're just as screwed.
A solution to the dependcy hell would be one that is not distrospecific and allows me to download and install any Linux stuff I want from the net, not just the one that some Debian maintainers thought would be worth packaging. It should also allow to install any number of different versions of the same programm without relying on extra work of the maintainer to handle the situation.
So basically you want packages that create and manage themselves?
It would also go a long way towards making every distribution the same, thus making all but one obsolete.
Considering that the only way a sane person would use Linux is to install a distribution and a distribution is a collection of packages to run on the linux kernel it would make sense to leave package management at the distribution level.
But that's beside the point. Why should I have to edit config files to do install packages? Looks like this "simple guide to installing packages" is quickly spiraling out of control.
Because everything isn't available in ever repository for various reasons. And if you really want to avoid editing files run RedCarpet and use the pretty GUI. If all of this seems like spiraling out of control, perhaps you should shut the computer down and go do something slower.
Do you mean an RPM for your (I presume popular) distribution? Or did you mean an RPM that could work on pretty much any distribution?
If you don't like trying to determine which RPM goes where, install Debian and be done with it, in sid there's over 13K packages.
Description: grep for network traffic ngrep strives to provide most of GNU grep's common features, applying them to the network layer. ngrep is a pcap-aware tool that will allow you to specify extended regular expressions to match against data payloads of packets. It currently recognizes TCP, UDP and ICMP across Ethernet, PPP, SLIP and null interfaces, and understands bpf filter logic in the same fashion as more common packet sniffing tools, such as tcpdump and snoop.
My notebook's touchpad lets me tap with both fingers on the touchpad to middle-click and with 3 fingers for a right-click.
I'm not suggesting a better gauge and I don't think data that bad should be used, perhaps if 1/4 of it wasn't 'unknown' it wouldn't be as bad but as it stands now there's more Debian developers than entries in popcon. I mean hell there's 36541 people registered to the debian-announce mailing list and even that's probably a small percentage of the total amount of Debian installations.
The minimum that needs to be done is to modify policy to require packages that can be optimised to have support for end users compiling optimised for themself.
Having precompiled optimised packages for every flavour of every architecture may place excessive burdens to the debian infrastructure.
May? Do you have any idea what the disk space requirements alone would be? And how far should it go? Should we have i486, i586 and i686 packages to make sure everyone's covered?
If you really want custom compiled packages either do it by hand for the few that might matter (apt-get source) or look at apt-build which can be setup to recompile everything on your system.
How can you ignore the unknown chunk, if it was smaller maybe but not since it's 1/4th of the submissions.
Anyway I run Debian on 3 non-i386 machines and none of them have popcon on them and considering the page says there's only just under 5000 submissions, way too few people have it installed and 1/4th of them mucked it up somehow so I'd say popcon isn't a good gauge for anything right now
It's not like making a custom package or getting the source to the original and patching it up to current is terribly difficult.
As I mentioned in another post, the real problem comes when someone has a problem with their 'tainted' kernel. They post a backtrace or "my kernel hung" message to lkml and if it's marked tained the developers can say "talk to the company behind the binary-only driver, they have our source code but we don't have theirs" instead of wasting hours tracking down a bug that may or may not be fixable by them.
The drivers would work the same with a non-GPL license string, the problem is that when these drivers cause a problem and someone posts to lkml with a backtrace of an oops there's no quick way to tell that a binary-only module was involved so they may waste tons of time tracking down bugs they can't fix.
If the drivers would say they're non-GPL then the lkml people would be able to say "talk to LinuxAnt, they have our source code but we don't have theirs so we can't help you" and move on to problems they can actually fix.
If you would spend an extra 5 minutes you could have both. Just grab the src.rpm, it has the source and an already made-up .spec file, apply the patch (or include it in the .spec file so it's applied for you on build) and make a patched RPM. That way you still have consistency with the package database and you don't have vulnerable software.
That's not entirely true. Sure all the HTML rendering functions used by Windows help, Explorer, etc are implemented in MSHTML.dll but it's not impossible to register a different HTML renderer. Infact a while back someone wrote a Gecko ActiveX control that did all of that, you could register it and all those APIs would then call on Gecko for the rendering instead of MSHTML. But IIRC it was a huge PITA to keep the control up to date, and that combined with the general lack of interest made him stop maintaining it.
No, it's an advantage. If MS suddenly changed the MSHTML license that said it couldn't be used by free programs what would happen? The only choice would be to get a new HTML renderer like Gecko, because XFree is open source we can take the code that is still under the free license and fork a new copy under a free license.
XFree86 was a much bigger issue because so many things link against the X libraries, with Apache this only really affects apache modules, if even them.
That's the opinion of a few people in the GNU project, the GPL says nothing about what projects containing GNU tools have to be called.
The real question is what SP level was this fixed at? IE6 isn't vulnerable and I believe the leaked Win2K code was only SP1, so that means there's 3 SPs and all of them include IE so there's no telling when, if at all, the bug was fixed.
I don't think they mentioned the hardware used, but I doubt there were any IDE disks involved.
The 2.6 Linux process scheduler is O(1) meaning it'll scale to as many CPUs as you want and it's NUMA aware already.
I wouldn't be surprised if the FreeBSD scheduler was O(1), hell even NT's scheduler is O(1), but is it ready for NUMA or HT CPUs yet?
A PII is a 686, unless there was some upgrade chip I had never heard of.
Blah blah. Looks like a microkernel. It's going to suck performancewise, but it'll be very easy to get soft realtime performance. Of course, a big question is whether this performance loss is significant in the big picture.
/dev/kmem, /dev/port, etc. to do all necessary manipulations to switch screenmodes, set resolutions, set refresh rates, blit bitmaps.
I realize it's possible, but it would be so slow compared to current performance it wouldn't be worthwhile. Drivers now are discourages from using copy_to_user and copy_from_user unless absolutely necessary, having every driver do that every interrupt would be insane. And since the kernel would need atleast 1/3 of the driver logic to bring up the hardware and deal with interrupts and errors you gain almost nothing.
XFree86 can easily cope with video cards running from a process by writing to
But it's highly discouraged even for XFree to do that. With the new input system the kernel generates errors on the console because X fiddled with the keyboard directly when it's not supposed to.
What would be nice would be to give users the option of kernel/userspace drivers.
But the amount of work needed to convert them all and to maintain two sets of drivers would be huge and I'm sure just about noone would want to maintain it.
Personally, I'd probably end up using userspace drivers because I don't really need the highest maximum throughput to chat on irc, write some code, do some email, and browse the web, but I'd definitely appreciate the added insulation between the kernel and potentially bad drivers.
But it would gain you almost nothing. Almost every userspace driver would need the ability to put data into kernel memory somewhere for the mini-driver to hand off to the hardware so the potential for crashing the kernel is still there, it's just been moved around a bit.
And with all those added context switches and (previously) unnecessary memory copies I wouldn't be surprised if things like X and xmms started showing lag and higher latency than before, which is what most people use to judge how well the kernel is handling user interaction and general scheduling of things.
How would that even be possible? Take a NIC driver for instance, currently data from the NIC is retrieved from a certain memory address by a driver responding to an IRQ being raised. For your userland daemon idea to have any chance of working the kernel would still need a driver for the hardware to be able to initialize the hardware, respond to and acknowledge the IRQs, copy the data somewhere the userland daemon can handle it and probably other things I'm not thinking off.
At the very least the speed would make it impossible. context switches take a very long time, relative in the kernel, so imagine taking the amount of IRQs you can process per second and cutting by like a hundred or more.
Some things like modems and printers may be possible to have partial userland components, but most things need the kernel to initialize, setup and just generally manage the hardware in a way that's not possible from userland.
It's not neglected it's just there isn't the man power to reverse engineer every piece of hardware in existance to make a driver for it. Pretty much all the mainstream stuff is supported (some with a vendor driver like the nVidia driver) and if you need/want Linux support for something that doesn't have a driver talk to the manufacturer. Many companies like Intel, Dell, etc are writing and maintaing GPL'd drivers in the kernel these days.
Even if you are using a vendor kernel it doesn't matter because everything is modular, only modules for things you're using are loaded.