Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: Linux
Why Linux repositories are a huge competitive advantage for Linux
By Chris DiBona
on
July 12, 2004 (8:00:00 AM)
Share
Print
Comments
My friend Robin Miller recently wrote a very decent article about how
spoiled we Linux users are, which inspired me to write this article that I've been kind of meaning to write for a while anyway, an article about
how the various Linux repositories are and have been such a vast competitive advantage for Linux.
You should definitely read the comments on that article. There were some terrific points made about Microsoft's role as the dominant source for
desktop software limiting their ability to bundle, and how things are much easier to install on Windows, that I found insightful.
The reality of adding software to an operating system is that every application you add makes it more difficult to keep your installation secure, stable, and up to date. This is true no matter what OS and applications you use.
Microsoft goes on about this kind of thing often, describing their Windows Update service as the path away from security and stability problems for their operating system. They are mostly correct in that. Windows Update provides a vital service for users, that of keeping security holes closed, certain infrastructural software up to date, and in generally keeping software in good shape.
But since Microsoft doesn't have a process which is open to third party ISV's, you cannot easily update all of your applications using Windows Update. Linux distributions have a fantastic advantage in that you can have all of your software come from a single repository if you choose. This makes Linux distributions much easier to maintain.
In Windows, if you want to keep other programs up-to-date, you are pretty much on your own. Some programs will auto-update, particularly games. But other programs are static.
With Fedora Core, applications that are not in a yum repository are the exception, not the rule. Same with Debian and apt, and Red Hat and RHN. Linux distributions have always been very good about including a great number of packages in their repositories. Linux repositories aren't perfect, but they are miles ahead of competing proprietary commercial offerings.
In fact, this very feature, combined with a guaranteed library set and security updates, is what Red Hat has had a great deal of success selling to ISVs. In case you were wondering why ISV's tend to target RH Enterprise, it is because RH guarantees that the target won't move so fast from a library and support file location perspective. This was you can have updatability and the security that comes with it while maintaining a stable platform to run your application/site/database on.
These update methods are coming for Windows desktops, I'm sure. But a Linux user doesn't have to wait for them to arrive.
Comments
on Why Linux repositories are a huge competitive advantage for LinuxNote: Comments are owned by the poster. We are not responsible for their content.
He did this. Read the article before posting. Unless I didn't understand what you're meaning, in which case I apologize...
He mentioned by name Fedora (yum), Debian (apt), and Red Hat (rhn/up2date) by name, ignoring Mandrake (urpmi) and Gentoo (portage), which both have significantly more packages than Fedora or Red Hat.
well fedora has loads of packages, all rhat family distros do. its suse and mandrake that dont
Go and look at the contrib and plf repositories after doing a search on google for easy urpmi.
Mandrake has the largest collection of software after Debian.
Why do people just post random garbage without doing basic research?
Mandrake has the largest collection of software after Debian.
Why do people just post random garbage without doing basic research?
One of the strengths of Linux is exemplified by Debian's apt-get. You can configure multiple repositories for your apps. Under Debian it is a very common practice. There are quite a few people who are using the stable (woody) release, but want to keep a few rapidly developing apps more up-to-date. I'm one of those. I've pointed to backports for a handful of apps. Then running <TT>apt</TT> hits all of the repositories that you have configured. There is no additional effort to stay up-to-date from multiple sources once you've configured it.
For anyone out there not already familiar with them, I recommend a couple of sites:
I don't intend this to criticize any other distro. I have used several very happily over the years. Debian happens to be the distro I'm using now, so I'm simply describing the mechanisms and resources I'm currently most familiar with.
For anyone out there not already familiar with them, I recommend a couple of sites:
- <A HREF="http://www.apt-get.org/" title="apt-get.org">Unofficial APT repositories (www.apt-get.org)</a apt-get.org>
- <A HREF="http://www.backports.org/" title="backports.org"> Debian Backports (www.backports.org)</a backports.org>
I don't intend this to criticize any other distro. I have used several very happily over the years. Debian happens to be the distro I'm using now, so I'm simply describing the mechanisms and resources I'm currently most familiar with.
Having used several distros, i have to say that SuSE's YaST is one of the (if not *THE*) best ways to install new apps (by downloading the rpm, click on it, click the "Install With YaST" button and wait). For new users, this has to be the best way. No CLI, just a couple of clicks and its done, and is similar enough to Windows Installer for Windows converts to feel at home.
The problem with YaST is dependencies. It still relies on the user to solve dependency problems. If YaST was combined with either Apt or Yum (or both), IMHO it should be the "standard" installer for Linux apps. No dependencies, no CLI. Surely this is what Desktop Linux should be aiming for?
The problem with YaST is dependencies. It still relies on the user to solve dependency problems. If YaST was combined with either Apt or Yum (or both), IMHO it should be the "standard" installer for Linux apps. No dependencies, no CLI. Surely this is what Desktop Linux should be aiming for?
Check out http://www.madpenguin.org/cms/?m=show&id=1740 and see how Xandros does it with apt.
I second this. YaST plus apt is about the best solution for all of these problems.
There's nothing wrong with the CLI for desktop use, but sometimes using YAST to install rpms is click-easy, it's true. And while I second (or third?) the suggestion of combining YAST with apt (that would be fantastic), one quick thing YAST should do is return some kind of message when YAST-rpm installation fails because of dependencies. The only hint you get is that the rpm fails to install.
What I do next is then copy the url and from the CLI try rpm -ivh [insert url] from there. That will tell you the dependencies missing or why the rpm will not install. Also, from the CLI, you can upgrade your package with the new rpm instead of just installing it, using rpm -Uvh [insert url], and oftentimes that will fix the dependency problem.
YAST is pretty good. But it still could use a whole lot of improvement. (It is similarly weak in editing configuration files). Hopefully its recent open-sourcing will result in such improvements. Apt with an improved YAST? Yum.
What I do next is then copy the url and from the CLI try rpm -ivh [insert url] from there. That will tell you the dependencies missing or why the rpm will not install. Also, from the CLI, you can upgrade your package with the new rpm instead of just installing it, using rpm -Uvh [insert url], and oftentimes that will fix the dependency problem.
YAST is pretty good. But it still could use a whole lot of improvement. (It is similarly weak in editing configuration files). Hopefully its recent open-sourcing will result in such improvements. Apt with an improved YAST? Yum.
Are you aware that there are GUI front ends to APT? Synaptic, I believe, is the Free one you can easily get with Debian (or for RedHat, etc), there's alos proprietary (I believe) ones like Click & Run from Lindows, and I think Libranet has one too.
If you are familiar with these, what advantage does YaST offer over Synaptic? I am not trying to argue here, just curious about where the pros and cons are.
Disclaimer: I am not currently a Debian user, though I do use apt (from the command line) on my RedHat box. My main Desktop system runs Gentoo (but I'm not gonna get all preachy about it - I like it, but I know it's not everyone's distro). and I have a server running FreeBSD. The RH9 box is my gf's system, I installed/maintain it. I am currently working on deciding whether to move it to FC2, SuSE (In the running because I managed to get in on the free offer, I'm expecting the package to arrive at some point), Gentoo or Debian - Not highly narrowed choices, I know, but I'm early in the decision making process. SuSE is probably the favorite just because I have a good feeling about the directions Novell is taking the distro and would like to get to know it a bit - I've never worked with SuSE yet.
I should add that personally I would be annoyed with a system that worked only through the GUI - I do a lot of my work through SSH, and tend to be one of those weirdos who prefers working on the command line for many types of tasks anyway.
Sorry if this is a bit rambling or incoherent, it's late & I'm off to bed as soon as I finish this post. Ask for clarifications if they're needed, I'll try to answer in the morning.
If you are familiar with these, what advantage does YaST offer over Synaptic? I am not trying to argue here, just curious about where the pros and cons are.
Disclaimer: I am not currently a Debian user, though I do use apt (from the command line) on my RedHat box. My main Desktop system runs Gentoo (but I'm not gonna get all preachy about it - I like it, but I know it's not everyone's distro). and I have a server running FreeBSD. The RH9 box is my gf's system, I installed/maintain it. I am currently working on deciding whether to move it to FC2, SuSE (In the running because I managed to get in on the free offer, I'm expecting the package to arrive at some point), Gentoo or Debian - Not highly narrowed choices, I know, but I'm early in the decision making process. SuSE is probably the favorite just because I have a good feeling about the directions Novell is taking the distro and would like to get to know it a bit - I've never worked with SuSE yet.
I should add that personally I would be annoyed with a system that worked only through the GUI - I do a lot of my work through SSH, and tend to be one of those weirdos who prefers working on the command line for many types of tasks anyway.
Sorry if this is a bit rambling or incoherent, it's late & I'm off to bed as soon as I finish this post. Ask for clarifications if they're needed, I'll try to answer in the morning.
I was aware of front ends for APT, and have played around with Synaptic on FC1 (with less than impressive results, sadly. It crashed almost all the time and insisted on installing the crippled version of XMMS (with no MP3 support)).
For me, the other major advantage of YaST is the way it handles system settings. They are grouped in one place and the UI is uniform throughout, which gives it a better feel. Its a bit wizard-like (which may or may not annoy you), but has plenty of help text on screen explaining what each option actually does. As someone who isnt up to configuring my firewall from scratch with vi (yet!), I like this.
At some point, I would like to move on to Gentoo or Debian and YaST is the one reason I havent made the move.
For me, the other major advantage of YaST is the way it handles system settings. They are grouped in one place and the UI is uniform throughout, which gives it a better feel. Its a bit wizard-like (which may or may not annoy you), but has plenty of help text on screen explaining what each option actually does. As someone who isnt up to configuring my firewall from scratch with vi (yet!), I like this.
At some point, I would like to move on to Gentoo or Debian and YaST is the one reason I havent made the move.
I too love apt in CLI mode, but SSH doesn't stop you from running Synaptic or KPackage or even a whole KDE or GNOME desktop remotely. In fact, an ssh tunnel make all of these securer.
I do realize that, and have meant to play around with tunnelling X sessions at some point, but I really do generally prefer CLI for system management types of jobs. Because of this I've been slow about getting around to figuring it out, since I don't really have anything in particular I want to do with it.
Hi. For you and anyone else who has 'been slow about figuring it out' here's a leg up on the situation.
bash$ ssh -X -C [address of ssh server]
For example:
bash$ ssh -X -C mysshserver.net
This is extremely simple to understand what's going on here if you are at all familiar with SSH. The -X parameter automagically handles tunnelling for X applications, and the -C parameter tells SSH to use compression (in case of otherwise slow links).
Once logged in to the remote SSH server using at LEAST the -X parameter (note that this is CAPITAL X) any X application you run on the remote machine will have it's display forwarded directly to your LOCAL X server (the machine you connected FROM).
There's of course more to it than this, as SSH is capable of quite a few really amazing tricks if you take enough time researching the neverending details, but this should be enough to get you started tunneling graphical applications thru SSH with pretty much zero hassle (assuming your SSH server SUPPORTS X tunneling [it CAN be disabled in the config file by paranoid admins]).
Hopefully this is useful to someone, as I hate to waste Internet bandwidth uselessly... 8)
bash$ ssh -X -C [address of ssh server]
For example:
bash$ ssh -X -C mysshserver.net
This is extremely simple to understand what's going on here if you are at all familiar with SSH. The -X parameter automagically handles tunnelling for X applications, and the -C parameter tells SSH to use compression (in case of otherwise slow links).
Once logged in to the remote SSH server using at LEAST the -X parameter (note that this is CAPITAL X) any X application you run on the remote machine will have it's display forwarded directly to your LOCAL X server (the machine you connected FROM).
There's of course more to it than this, as SSH is capable of quite a few really amazing tricks if you take enough time researching the neverending details, but this should be enough to get you started tunneling graphical applications thru SSH with pretty much zero hassle (assuming your SSH server SUPPORTS X tunneling [it CAN be disabled in the config file by paranoid admins]).
Hopefully this is useful to someone, as I hate to waste Internet bandwidth uselessly... 8)
I use Mandrake and URPMI is the tool I use. It will work out and install the dependencies for you.
I have several source locations configured including PLF and loopback mounted ISO images of the install disks.
All I have to do is open the Mandrake control panel, click on "Install software" search for the package or file I am looking for, tick it and click on "Install".
It warns you about which dependencies are required and asks you if you approve.
I have several source locations configured including PLF and loopback mounted ISO images of the install disks.
All I have to do is open the Mandrake control panel, click on "Install software" search for the package or file I am looking for, tick it and click on "Install".
It warns you about which dependencies are required and asks you if you approve.
Getting toward the end of the article started me wondering...
I've just spent the last day trying to figure out how to get video from my vhs vcr's (you remember them, right?) video out port, through the video in port on my video card (geforce2mx/v7100 deluxe combo with tv something). And I've been running into error messages. Since I'm running knoppix, one message I'm getting from xawtv (exiting immediately after startup) is "no video device grabber", and something about v4l-conf, v4l2, v4l, and no such device on<nobr> <wbr></nobr>/dev/video0. Taking a look at video0, I see that there's a link from it in<nobr> <wbr></nobr>/dev, to<nobr> <wbr></nobr>/knoppix/dev/video0, so that may be the problem. I suspect that if I remove the link (after figuring out how, rm<nobr> <wbr></nobr>/dev/video0, but then how to get back<nobr> <wbr></nobr>/dev/video0?), so onward, and upward. Some googling brings me to dvgrab, but all the docs are around 1394 card, which is not my situation. Kino is out, I'm limited to the apps on knoppix, since I'm running from a live cd. So is cinerella. I tried xine, but I can't figure out how to let it scan the devices, so it runs into the playing video tape. I don't even know if that would work, because if the problem with<nobr> <wbr></nobr>/dev/video0 above is related to the<nobr> <wbr></nobr>/knoppix link...
All I'm looking to do is take some screen shots of the video, and output as jpeg images, or something that can be printed as a photo. The kicker is that xawtv worked, using an older version of knoppix, when I plugged in a usb cam and rebooted. I was able to take screenshots from the cam. So I know it's simply a matter of telling the computer where to get the video signal from. So back to Google. And then I run across mplayer.
I had mplayer on a suse install about a year ago. imho, mplayer is far better than xine. If I had mplayer, I'm sure I could get some screenshots of my video. But since I'm using knoppix from a live cd, and since mplayer isn't part of the available optional software that can be downloaded with the live cd, I'm out of luck for now. But either while looking at the mplayer docs, or in thinking back to my previous use of it, and going over everything I've been doing for the past day in trying to figure out the problem, I came across my point.
mplayer isn't available on the debian servers. I don't think xine is either, or some codecs aren't. And the non-US security servers, and the backports servers, and all the unofficial packages locations, brings forth one of the weaknesses in the many eyes argument of the advantage of open source/free software. As long as I stick to the official servers, I'm fairly safe. But if I want to listen to music on Red Hat, or want to view a movie DVD on Debian, or just about any other distro, or want to do something that isn't supported officialy (but still very popular), I have to trust the package maintainer, and hope he hasn't included a back door, or malicious code. The mplayer, xine, or similar apps, is more of a concern than others, because they are both widely used as a solution to a popular action, viewing videos, and at least some portion of mplayer iirc, needs to run as root. Installing the apps usually requires root priveleges. But the added requirement of running some part of the app as root, gives system wide access to an app/package that is maintained by a volunteer. Sure, everyone downloading the app has access to the code, and can inspect it. But how many people actually audit the code for security immediately upon a maintenance or security update? The next argument that pops up is "you can audit the code yourself" (no I can't), and "you can hire someone else to audit the code for you" (I don't have the money, and even if I did, I wouldn't, and this is reflected by others who have the money not doing it either, and no one stepping forward to do it for others, and standing behind the audits).
Maybe mplayer no longer runs anything as root. Or my memory is faulty, and it never did. And the same may be true of xine. But I certainly recall that there are apps that require they run as root. If any of these apps are packaged by third parties for rpm, or deb, or whatever, those apps are not as secure as if they are on the official distro servers, or in other words, I wouldn't give them the same level of trust.
I'm certainly not saying that the mplayer or other app hackers have some nefarious goals in mind. What I am saying is that for a fully functioning system, trust must be placed on third parties, in addition to the official distro maintainers. Trust in their intentions, but also trust in their servers not getting hacked, and the apps replaced with compromised versions.
I find it great that the majority of apps on a distro can be easily updated, and often, by going to one (the distro's) server, and updating everything in one shot. Not only great, but I still have trouble understanding how some individuals and companies can maintain Red Hat servers that are older than what is currently supported (RH 7.3?), and who maintain all the patches and security updates individually. I've seen comments by some people that this is what they're doing because of the large number of servers they have running...are they actually maintaining hundreds of packages, going to each individual package site every morning to check for security or update patches? Does this make sense? I can understand that servers have minimal packages installed, but if you are talking about multiple servers, you are still talking about apache, bind, postfix, sendmail, samba, ldap, ssl, ssh, vim, php, perl, and dozens of other apps. Is a visit made to each of the apps' sites every morning? Are all the security lists scanned as well? For every single app? And security/maintenance patches are being downloaded and installed manually? This last part actually argues in favor of a single point for all updates. But once the support stops for a single version... My main point was that some apps are not on the distro's servers, but elsewhere, and root access is given to install, and possibly run some portions of these apps, and they don't have the same trust or eyes as the apps that are found on the official servers.
"Well, you don't have to view videos..." And I don't have to use a toilet with a heated seat in the winter either, but once you do...
I've just spent the last day trying to figure out how to get video from my vhs vcr's (you remember them, right?) video out port, through the video in port on my video card (geforce2mx/v7100 deluxe combo with tv something). And I've been running into error messages. Since I'm running knoppix, one message I'm getting from xawtv (exiting immediately after startup) is "no video device grabber", and something about v4l-conf, v4l2, v4l, and no such device on<nobr> <wbr></nobr>/dev/video0. Taking a look at video0, I see that there's a link from it in<nobr> <wbr></nobr>/dev, to<nobr> <wbr></nobr>/knoppix/dev/video0, so that may be the problem. I suspect that if I remove the link (after figuring out how, rm<nobr> <wbr></nobr>/dev/video0, but then how to get back<nobr> <wbr></nobr>/dev/video0?), so onward, and upward. Some googling brings me to dvgrab, but all the docs are around 1394 card, which is not my situation. Kino is out, I'm limited to the apps on knoppix, since I'm running from a live cd. So is cinerella. I tried xine, but I can't figure out how to let it scan the devices, so it runs into the playing video tape. I don't even know if that would work, because if the problem with<nobr> <wbr></nobr>/dev/video0 above is related to the<nobr> <wbr></nobr>/knoppix link...
All I'm looking to do is take some screen shots of the video, and output as jpeg images, or something that can be printed as a photo. The kicker is that xawtv worked, using an older version of knoppix, when I plugged in a usb cam and rebooted. I was able to take screenshots from the cam. So I know it's simply a matter of telling the computer where to get the video signal from. So back to Google. And then I run across mplayer.
I had mplayer on a suse install about a year ago. imho, mplayer is far better than xine. If I had mplayer, I'm sure I could get some screenshots of my video. But since I'm using knoppix from a live cd, and since mplayer isn't part of the available optional software that can be downloaded with the live cd, I'm out of luck for now. But either while looking at the mplayer docs, or in thinking back to my previous use of it, and going over everything I've been doing for the past day in trying to figure out the problem, I came across my point.
mplayer isn't available on the debian servers. I don't think xine is either, or some codecs aren't. And the non-US security servers, and the backports servers, and all the unofficial packages locations, brings forth one of the weaknesses in the many eyes argument of the advantage of open source/free software. As long as I stick to the official servers, I'm fairly safe. But if I want to listen to music on Red Hat, or want to view a movie DVD on Debian, or just about any other distro, or want to do something that isn't supported officialy (but still very popular), I have to trust the package maintainer, and hope he hasn't included a back door, or malicious code. The mplayer, xine, or similar apps, is more of a concern than others, because they are both widely used as a solution to a popular action, viewing videos, and at least some portion of mplayer iirc, needs to run as root. Installing the apps usually requires root priveleges. But the added requirement of running some part of the app as root, gives system wide access to an app/package that is maintained by a volunteer. Sure, everyone downloading the app has access to the code, and can inspect it. But how many people actually audit the code for security immediately upon a maintenance or security update? The next argument that pops up is "you can audit the code yourself" (no I can't), and "you can hire someone else to audit the code for you" (I don't have the money, and even if I did, I wouldn't, and this is reflected by others who have the money not doing it either, and no one stepping forward to do it for others, and standing behind the audits).
Maybe mplayer no longer runs anything as root. Or my memory is faulty, and it never did. And the same may be true of xine. But I certainly recall that there are apps that require they run as root. If any of these apps are packaged by third parties for rpm, or deb, or whatever, those apps are not as secure as if they are on the official distro servers, or in other words, I wouldn't give them the same level of trust.
I'm certainly not saying that the mplayer or other app hackers have some nefarious goals in mind. What I am saying is that for a fully functioning system, trust must be placed on third parties, in addition to the official distro maintainers. Trust in their intentions, but also trust in their servers not getting hacked, and the apps replaced with compromised versions.
I find it great that the majority of apps on a distro can be easily updated, and often, by going to one (the distro's) server, and updating everything in one shot. Not only great, but I still have trouble understanding how some individuals and companies can maintain Red Hat servers that are older than what is currently supported (RH 7.3?), and who maintain all the patches and security updates individually. I've seen comments by some people that this is what they're doing because of the large number of servers they have running...are they actually maintaining hundreds of packages, going to each individual package site every morning to check for security or update patches? Does this make sense? I can understand that servers have minimal packages installed, but if you are talking about multiple servers, you are still talking about apache, bind, postfix, sendmail, samba, ldap, ssl, ssh, vim, php, perl, and dozens of other apps. Is a visit made to each of the apps' sites every morning? Are all the security lists scanned as well? For every single app? And security/maintenance patches are being downloaded and installed manually? This last part actually argues in favor of a single point for all updates. But once the support stops for a single version... My main point was that some apps are not on the distro's servers, but elsewhere, and root access is given to install, and possibly run some portions of these apps, and they don't have the same trust or eyes as the apps that are found on the official servers.
"Well, you don't have to view videos..." And I don't have to use a toilet with a heated seat in the winter either, but once you do...
I've just spent the last day trying to figure out how to get video from my vhs vcr's (you remember them, right?) video out port, through the video in port on my video card (geforce2mx/v7100 deluxe combo with tv something). And I've been running into error messages. Since I'm running knoppix, one message I'm getting from xawtv (exiting immediately after startup) is "no video device grabber"
knoppix doesn't include drivers for video capture for nvidia cards. you can find them at rivatv.sf.net
, and something about v4l-conf, v4l2, v4l, and no such device on<nobr> <wbr></nobr>/dev/video0. Taking a look at video0, I see that there's a link from it in<nobr> <wbr></nobr>/dev, to<nobr> <wbr></nobr>/knoppix/dev/video0, so that may be the problem. I suspect that if I remove the link (after figuring out how, rm<nobr> <wbr></nobr>/dev/video0, but then how to get back<nobr> <wbr></nobr>/dev/video0?), so onward, and upward.
knoppix doesn't still use udev, nor does it use devfs i believe (and if it does, there is some kind of problem). thus the presence of that<nobr> <wbr></nobr>/dev/video0 entry does not mean that a driver for that device is installed, it does not imply even that there is such hardware installed.
things will improve with udev, the presence of the device in<nobr> <wbr></nobr>/dev will imply that a driver capable of running that device is loaded.
Some googling brings me to dvgrab, but all the docs are around 1394 card, which is not my situation.
right, dvgrab works only with firewire devices
Kino is out, I'm limited to the apps on knoppix, since I'm running from a live cd.
you can always install it on hard disk and then install kino with "apt-get install kino". btw, look at the next versions of knoppix, they should provide some kind of magic in this regard. some other live cds are also experimenting with some kind of transparent filesystem.
So is cinerella.
once you have a debian on your hard disk i suggest this repository to get a good packaged cinelerra for debian:
deb http://www.kiberpipa.org/~minmax/cinelerra/builds<nobr>/<wbr></nobr> sid<nobr> <wbr></nobr>./
I tried xine, but I can't figure out how to let it scan the devices
i was never able to use xine as a way to watch tv or the video in signal. i'm not even sure that xine can be used to watch tv. btw, xine can only watch, it does not record anything.
All I'm looking to do is take some screen shots of the video,
once the drivers are installed, among many tools you should be able to use xsane or xscanimage (this last one is included in knoppix). at least i'm able to use them to capture from my bt8x8 chipset tvcard. the rivatv drivers can be loaded on knoppix even while you run it from the cd (on the next restart you will have to rebuild and reload them, obviously)
and output as jpeg images, or something that can be printed as a photo.
keep in mind that with a 720x576 (for pal, even less for ntsc) frame size and with interlaced input you won't get a very high quality, but that's a hardware issue, not a software one.
The kicker is that xawtv worked, using an older version of knoppix, when I plugged in a usb cam and rebooted.
because that webcam had already a driver in knoppix
I was able to take screenshots from the cam. So I know it's simply a matter of telling the computer where to get the video signal from.
in this case you still miss the driver
So back to Google. And then I run across mplayer.
I had mplayer on a suse install about a year ago. imho, mplayer is far better than xine.
it has a load of features, mplayer is very impressive.
If I had mplayer, I'm sure I could get some screenshots of my video.
again, not without the driver.
But since I'm using knoppix from a live cd, and since mplayer isn't part of the available optional software that can be downloaded with the live cd, I'm out of luck for now. But either while looking at the mplayer docs, or in thinking back to my previous use of it, and going over everything I've been doing for the past day in trying to figure out the problem, I came across my point.
mplayer isn't available on the debian servers for many unfortunate reasons. it will possibly be included in the near future.
however mplayer is avalilable here if you want:
http://marillat.free.fr
I don't think xine is either
xine is part of the main debian repository. you can find it out here:
http://packages.debian.org/unstable/graphics/xine<nobr>-<wbr></nobr> ui
btw, you can search for debian packages inside the main repository from this page:
http://packages.debian.org
and many others multimedia players, based on xine or not, are already included in debian, look ad videolan and totem for some examples.
or some codecs aren't.
the version you will find on the marillat page has most of the codeds you need. if you need some windows only codec there is even a win32codecs package there. i have not found yet a piece of video that i couldn't play with mplayer plus eventually those additional codecs.
and please remember that due to legal reasons many of those codecs won't be included in windows ever. this is not a problem isolated in the linux world.
And the non-US security servers
non-us is pretty useless at the current time. i am not using it right now.
and remember that non-US servers are set up directly by the debian installer. what's the problem?
and the backports servers
you need backports only (and not necessarily) if you use debian stable. most desktop debian users prefer to run debian testing or debian unstable currently
, and all the unofficial packages locations,
the important ones are not so many. debian is fully usable even without additional repository. and keep in mind that many of those repository are only a temporary storage of packages that after some time becomes part of the main debian repository.
As long as I stick to the official servers, I'm fairly safe. But if I want to listen to music on Red Hat,
the mp3 patents and the way the fraunhofer institute manages them has been unfortunate.
but currently debian provides several mp3 players directly from the main repository
or want to view a movie DVD on Debian
debian provides xine and ogle in the main archive. the installation of libdvdcss is suggested to the user, and the command to install it is printed to the screen in a pretty clear way if i remember correctly. unfortunatly there is not a much better way to do things, thanks to our patents and dmca overlords...
, or just about any other distro, or want to do something that isn't supported officialy (but still very popular),
if it is popular and not patent encumbered or the like, it will usually reach the main archives.
I have to trust the package maintainer, and hope he hasn't included a back door, or malicious code.
you have to trust every vendor of commercial software in exactly the same way. but here the presence of the source code of every package is a great help even if you will never directly read it.
The mplayer, xine, or similar apps, is more of a concern than others, because they are both widely used as a solution to a popular action, viewing videos, and at least some portion of mplayer iirc, needs to run as root.
no, you are wrong, absolutely no portion of mplayer needs to run as root
Installing the apps usually requires root priveleges.
installing the packages, yes. the same apply to windows too. but there are projects such as zeroinstall and gibraltar (i'm sure i'm mispelling it, sorry...) linux meant to help here. and you can often compile the software by yourself and install it in a directory of your choice, without needing root priviledges.
But the added requirement of running some part of the app as root, gives system wide access to an app/package that is maintained by a volunteer.
what's the problem here? most of the open source software you can find is written by volunteer. why can you trust them more than those that package those apps for you?
Sure, everyone downloading the app has access to the code, and can inspect it. But how many people actually audit the code for security immediately upon a maintenance or security update?
the availability of the source is by itself a strong discouragdmenent for someone who wants to distribute backdoor, because it is easier to find a backdoor when you have the code.
Maybe mplayer no longer runs anything as root.
i strongly believe that mplayer NEVER had this problem.
Or my memory is faulty, and it never did. And the same may be true of xine. But I certainly recall that there are apps that require they run as root.
for example an app that needs to bind to a tcp or udp port lower than 1000 needs to start as root, and only than can drop priviledges.
If any of these apps are packaged by third parties for rpm, or deb, or whatever, those apps are not as secure as if they are on the official distro servers, or in other words, I wouldn't give them the same level of trust.
don't give them the same level of trust. this is perfectly understandable.
I'm certainly not saying that the mplayer or other app hackers have some nefarious goals in mind. What I am saying is that for a fully functioning system, trust must be placed on third parties, in addition to the official distro maintainers. Trust in their intentions, but also trust in their servers not getting hacked, and the apps replaced with compromised versions.
sure. but is it a problem? or how is it different from commercial software? you must trust those who wrote it, and those who distribute it, and no, they are not always the same people. look at the frontpage extension vulnerability in internet information server some years ago. search google for "netscape engineers are weenies", you will find out that microsoft bought some code from some other company, and that code contained a backdoor. they didn't even bothered to read the sources before shipping it...
I find it great that the majority of apps on a distro can be easily updated, and often, by going to one (the distro's) server, and updating everything in one shot. Not only great, but I still have trouble understanding how some individuals and companies can maintain Red Hat servers that are older than what is currently supported (RH 7.3?), and who maintain all the patches and security updates individually.
i don't know, i am used to upgrade the entire os when a new version cames out, and with debian this is about a couple of years.
I've seen comments by some people that this is what they're doing because of the large number of servers they have running...are they actually maintaining hundreds of packages, going to each individual package site every morning to check for security or update patches? Does this make sense? I can understand that servers have minimal packages installed, but if you are talking about multiple servers, you are still talking about apache, bind, postfix, sendmail, samba, ldap, ssl, ssh, vim, php, perl, and dozens of other apps. Is a visit made to each of the apps' sites every morning? Are all the security lists scanned as well? For every single app? And security/maintenance patches are being downloaded and installed manually? This last part actually argues in favor of a single point for all updates. But once the support stops for a single version...
this is open source software, everybody can provide updates if they want. look at progeny, they support some versions of redhat not supported anymore by redhat itself.
My main point was that some apps are not on the distro's servers, but elsewhere, and root access is given to install, and possibly run some portions of these apps, and they don't have the same trust or eyes as the apps that are found on the official servers.
ask your distro to ship that important and popular package. if it is not important and popular enough, why do you think it is different from the windows world? there you have to trust a multitude of vendors too. and you don't even have the source as a guarantee.
for a thorough, helpful, and non-confrontational response. You took time out to answer in detail, my rambling post, without calling me an idiot, telling me to rtfm, telling me to find another distro, etc. It isn't often that I see these type of responses for newbie and newbie-ish type posts. More responses like this will go a long way in making newer, less technically able users feel welcome in the FOSS space.
I certainly found it helpful, and others reading it should use it as a model for answering posts that attempt to point out what they see as a weakness, and for understanding that pointing out weakness, or the perception of weakness, in a platform does not necessarily mean that the poster is trashing the platform, or has an agenda.
Later tonight, or tomorrow I may add another post to explore my and your points further, right now I'm busy trying to transfer a w98 install from a small hard drive, to a larger hard drive, after many attempts by the user himself ending in failure. I hope dd will help me with this. I'm actually posting from the new drive now, but dd appears to have shrunk the new drive to the old drive's size. I'm going to try qtparted to recover the extra space on the new drive now.
If I could only convince him to use linux...or just stop using the AOL desktop and use Mozilla instead to access web pages...
I certainly found it helpful, and others reading it should use it as a model for answering posts that attempt to point out what they see as a weakness, and for understanding that pointing out weakness, or the perception of weakness, in a platform does not necessarily mean that the poster is trashing the platform, or has an agenda.
Later tonight, or tomorrow I may add another post to explore my and your points further, right now I'm busy trying to transfer a w98 install from a small hard drive, to a larger hard drive, after many attempts by the user himself ending in failure. I hope dd will help me with this. I'm actually posting from the new drive now, but dd appears to have shrunk the new drive to the old drive's size. I'm going to try qtparted to recover the extra space on the new drive now.
If I could only convince him to use linux...or just stop using the AOL desktop and use Mozilla instead to access web pages...
Maybe this is too late.
When dd from source to dest, try to use partition instead of the whole drive.
Instead of<nobr> <wbr></nobr>:
After dd done, meta data of your new partition will be somewhat incorrect, but it won't affect operation of your OS, and you can fix it with Linux's partition tools.
When dd from source to dest, try to use partition instead of the whole drive.
Instead of<nobr> <wbr></nobr>:
<TT>dd if=/dev/hda of=/dev/hdb bs=32k</TT>try this:
<TT>dd if=/dev/hda1 of=/dev/hdb1 bs=32k</TT>Of cause, you must first create the partition<nobr> <wbr></nobr>/dev/hdb1 of the same size as or a few MB larger than<nobr> <wbr></nobr>/dev/hda1.
After dd done, meta data of your new partition will be somewhat incorrect, but it won't affect operation of your OS, and you can fix it with Linux's partition tools.
There's a <A HREF="http://klik.berlios.de/" title="berlios.de">point'n'klik</a berlios.de> repository for Knoppix users. MPLayer is not there yet but KPlayer is.
I have the 3.4 live cd. When I go to the menu of installing additional software, it presents me with a pre-defined list. I don't seem to recall kplayer being on that list, I'll be checking this later. If it isn't on the menu list, is it still possible to install the app if it is in the repository you mention? I thought I could only download what was added to the menu in the kde desktop.
I have a persistant home, a swap partition, plus writeable partitions. So if I can install apps in addition to what is presented in the kde menu for additional software through the point and click feature, is there a guide, or can you provide a key sequence or menu sequence, or a command line example for doing it? I've been following the point and click feature, and one of the apps I asked for was included by the author (probono I believe, thanks probono!), but apparently I haven't been following it closely enough, if I understand what I think it is you are saying.
Thanks!
I have a persistant home, a swap partition, plus writeable partitions. So if I can install apps in addition to what is presented in the kde menu for additional software through the point and click feature, is there a guide, or can you provide a key sequence or menu sequence, or a command line example for doing it? I've been following the point and click feature, and one of the apps I asked for was included by the author (probono I believe, thanks probono!), but apparently I haven't been following it closely enough, if I understand what I think it is you are saying.
Thanks!
IMHO, that's all described on the homepage I linked above. I'm not using Knoppix or KDE or Klik but it seems rather simple.
First, get the Klik client by pressing ALT+F2 (probably for the console). Then type
First, get the Klik client by pressing ALT+F2 (probably for the console). Then type
wget klik.berlios.de/client/install -O -|sh
to get the client. You need to open this site in Konquoror, then click <A HREF="klik:kplayer" title="klik">this link</a klik>, and KPlayer should be installed, probably on your writeable partition as a application directory as known from MacOS. See the Klik homepage for more applications and explanations.
Re:hmmm... [Getting DVD's to play under Debian]
Posted by: Anonymous Coward on July 13, 2004 03:41 PM
Mplayer isn't in Debian because its licensing is a mess. People are working on this but it won't come soon. Xine works: I prefer Totem.
The secret is that you have to install libdvdread3
- then go read the docs under<nobr> <wbr></nobr>/usr/share/docs/libdvd3/examples or so.
Enjoy - use the main Debian servers and all should be well
Andy
The secret is that you have to install libdvdread3
- then go read the docs under<nobr> <wbr></nobr>/usr/share/docs/libdvd3/examples or so.
Enjoy - use the main Debian servers and all should be well
Andy
The software needed to create these apt-get/yum repositories is of course also available on oss/fs licenses. This allows any third party entity to construct and operate an apt-get/yum updatable software repository for gnu/linux systems. Since tools like apt-get allow multiple repositories to be used and integrated, it's possible for third parties to easily make updates available that can be processed through a single unified administrative interface.
More to the point, since the entire process is open and controllable, large enterprises can also choose to mirror and maintain their own local repositories, both for ouside applications and internally developed ones, and also control what applications are updated when if they wish to choose. For the serious enterprise user, this can be a very effective means of maintaining and updating a large infrastructure on your own terms.
More to the point, since the entire process is open and controllable, large enterprises can also choose to mirror and maintain their own local repositories, both for ouside applications and internally developed ones, and also control what applications are updated when if they wish to choose. For the serious enterprise user, this can be a very effective means of maintaining and updating a large infrastructure on your own terms.
There is a hook in these third party apt-get/yum repositories. If in one of these third party repositories a higher versioned library is added, you will only see this third party versioned library and you will not be able to get an other versioned library from the 'normal' repositories.
What is missing is the possibility to select which package from which repository you would like to update. Remind that debian is using a different file-hierarchy then Redhat or Suse does, so it is quite wel possible to have the same library (of different versions) on your system, and it is questionable if it works but it will definitly not improve stability.
What is missing is the possibility to select which package from which repository you would like to update. Remind that debian is using a different file-hierarchy then Redhat or Suse does, so it is quite wel possible to have the same library (of different versions) on your system, and it is questionable if it works but it will definitly not improve stability.
These repositories are definitely a competitive edge for Linux, but also for free software projects on other systems.
Free software projects under Sourceforge for MacOSX were one of the things I discovered with getting a Mac -- you can download prebuilt applications, doubleclick on the disk image, and try them out directly without installing them on the system. I've identified a few utilities (Fire, iTerm, Mplayer OSX) that I use on a regular basis this way.
Once I installed the Mac's free developer tools, I learned how to help out by testing recent CVS snapshots of these apps. Under sourceforge, it boiled down to:
% cvs update -d blah.../foobucket
% pbxbuild (or xcodebuild, more recently)
% open build/foobucket.app
to download, compile, and run the latest cvs snapshot of an application. For sufficiently stable apps, this process is easy enough that I *only* run the app's latest CVS snapshot. This way I can contribute back bug reports (and infrequently, patches).
What amazes me is that these are full-blown GUI apps that were built using a single build command and without additional development library downloads. IMO, the combination of Apple's providing free development tools/libraries and Sourceforge's hosting free projects provides a competitive edge to MacOSX as well.
Free software projects under Sourceforge for MacOSX were one of the things I discovered with getting a Mac -- you can download prebuilt applications, doubleclick on the disk image, and try them out directly without installing them on the system. I've identified a few utilities (Fire, iTerm, Mplayer OSX) that I use on a regular basis this way.
Once I installed the Mac's free developer tools, I learned how to help out by testing recent CVS snapshots of these apps. Under sourceforge, it boiled down to:
% cvs update -d blah.../foobucket
% pbxbuild (or xcodebuild, more recently)
% open build/foobucket.app
to download, compile, and run the latest cvs snapshot of an application. For sufficiently stable apps, this process is easy enough that I *only* run the app's latest CVS snapshot. This way I can contribute back bug reports (and infrequently, patches).
What amazes me is that these are full-blown GUI apps that were built using a single build command and without additional development library downloads. IMO, the combination of Apple's providing free development tools/libraries and Sourceforge's hosting free projects provides a competitive edge to MacOSX as well.
As an example of one of the best packaging systems I have found, is Arch Linux with it's pacman and abs.
To update my whole system I write 'pacman -Syu' and just wait while my computer downloads all updated software packages, and installs them, checks if there are any new dependencies, downloads and installs them too.
If I find that the Arch Linux developers are too slow to upgrade a software package (most packages are updated within a week after a new release), I can use abs to upgrade the package myself. Usually I only have to change the version number in the PKGBUILD file, and then run 'makepkg', and the source of the package is downloaded, compiled and packaged. Then I just 'pacman -A *package name*', and it's done.
Then I come to the most excelent thing; The PKGBUILD script format is very easy to understand. So if there is a program I need that isn't in the Arch Linux package archive, I can make my own package. Or if it's too difficult, the user community for Arch Linux is really friendly, so I just ask in the Forum, and answers will come. And then, when my package is ready, I'll post the PKGBUILD in the Forum for other people to use, and who knows, sooner or later it'll be maintained in the official repository. With Arch Linux I have the feeling that the developers and the users together are part of a project to create something good.
Re:Arch Linux has a very good packaging system
Posted by: Anonymous Coward on August 18, 2004 11:31 AM
Debian was that much open some years ago. However, size matter, and some more control were needed at the end. However, everybody is free to contribute, either directly into debian by applying as a maintainer, or through a local apt repository (see apt-get.org for examples).
If you're a gentoo-like compiling freak, you can maintain your own compiled packages using apt-src. You can also try cvs-buildpackages, svn-buildpackage on Debian, will help you maintain your own version of the packages if you need it, either it came from a cvs or svn repository. True, however, the format of the debian/* dir is more complex. I find it necessary however, in regards to the quality standard of Debian (package downgrade, installation error handling, respect of standards, automatical build on more than 12 archs, pristine orig. sources, etc.). However, multiple debs scripts are just there to help you (like debhelpers), and can even automated packages creation from simple sources (like dh-make for autotools like sources, dh-make-perl for CPAN packages, etc.).
And if that's not enough, you can always create your own packages, either by using alien, or directly from source into<nobr> <wbr></nobr>/usr/local (which the Debian standards will always kept free) using stow and dequivs for integrating them into the packaging dependency system.
Hope this can give you some idea.
A biased-Debian Maintainer<nobr> <wbr></nobr>;)
If you're a gentoo-like compiling freak, you can maintain your own compiled packages using apt-src. You can also try cvs-buildpackages, svn-buildpackage on Debian, will help you maintain your own version of the packages if you need it, either it came from a cvs or svn repository. True, however, the format of the debian/* dir is more complex. I find it necessary however, in regards to the quality standard of Debian (package downgrade, installation error handling, respect of standards, automatical build on more than 12 archs, pristine orig. sources, etc.). However, multiple debs scripts are just there to help you (like debhelpers), and can even automated packages creation from simple sources (like dh-make for autotools like sources, dh-make-perl for CPAN packages, etc.).
And if that's not enough, you can always create your own packages, either by using alien, or directly from source into<nobr> <wbr></nobr>/usr/local (which the Debian standards will always kept free) using stow and dequivs for integrating them into the packaging dependency system.
Hope this can give you some idea.
A biased-Debian Maintainer<nobr> <wbr></nobr>;)
Mention other distros as well?
Posted by: Anonymous Coward on July 12, 2004 08:54 PMShould you not also mention Mandrake (approx 8000 packages - see <A HREF="http://qa.mandrakesoft.com/twiki/bin/view/Main/ReleasesHistory" title="mandrakesoft.com">ReleasesHistory</a mandrakesoft.com>) or Gentoo?
#