Is still really true anymore? Granted, I'm not exactly a Linux newbie, but the simple installation option, where you install collections instead of individual packages, aren't that bad.
If the real storyline in any way resembles the fake ones on the site, he could have been sued for not given credit (remember the Spielberg movie, Amistad a couple of years back. He got sued even though the movie was based on a historic event, and then we have the Eddie Murphy movie, Back to America (?), Whoopie Goldberg's "Sister Act". Lots of examples).
You download it once after installation. After that, just download the patches. 1 Mb should be pretty fast, even on a slow connection.
And if the distributions would just give us a kernel source that wasn't patched to heck, it would be even easier (although I think Redhat's.src.rpm keep the pristine source and the patches separately before compilation).
It's mentioned that KDE is not included, which is true, but only tells half of the story.
Most (if not all) Debian users install applications using 'apt-get install'. apt-get uses a file/etc/apt/sources.list, which has a list of sites (web and ftp), to check for new packages.
Previously, if you wanted to install KDE, you would just add the line
deb http://kde.tdyc.com stable kde
to your sources.list
You would then install KDE like you would do any other Debian packages. From a user's pov, there would be no difference from having KDE included. In fact, some people install their GNOME this way (they added a option pointing to the Helix site, so the system installs HELIX GNOME instead of 'normal' Debian GNOME).
This is one reason I saw no reason to cry about the suggestion that Debian 'not include' non-free.
Well, considering the fact that RedHat and the commercial distributions business model is not to make money on the CD but rather the services, it shouldn't matter much.
And even though apt-get is great, I wouldn't be using it to upgrade a whole distribution if I was on a dial-up line (I'm sorry, but I can't wait 15 hours+ to upgrade/install my system).
I think that it's time the linux community stop wasting time on frills and spend more time on what they do best: building a stable OS with good, solid and secure code.
Who are you to tell what the "Linux Community" is should or shouldn't do? If the both KDE and GNOME teams decide to spend the rest of their natural life writing notepad clones, guess what? You don't have a say in the matter.
You're not paying them to do what they're doing. And just because you happen to use somebody's program, don't pretend that the author 'owe' you anything.
As to dependencies. You must have a lot of time on your hand. I fail to see what I can learn from the fact that application Foo depends on library FuuBarLib.so.1.0.2.5-1 and FaabarLib.so.3.32.102.2, but won't work with FuuBarLib.so.1.0.1.4-3. Of course, since most of the time, the documentation (if there are any) only mentions that it depends on FuuBarLib.so.1.0.2.5-1. Nowhere does it mention where this particular library is found, nor what the package it might be found in.
And what are you doing, using RPM if you want to know what is installed on your system? Just roll your own distribution and feel really 3L337.
Remember, just because something is properly installed on your system, doesn't mean that you can't download the sourcecode and check it out. You just don't have to do it if you don't want to.
Both of them only specify dependencies by name, rather than by function.
Actually, there is a hack to make Debian depend on function.
For instance, mutt depends on a mail server to work. Now exim, sendmail and qmail will all satisfy this dependency. Create a virtual (forget the official name for it) package that mutt depends on, for instance smtp-daemon package. Make exim, sendmail and qmail satisfy this dependency.
So, dpkg will satisfy by function rather than package name.
I used RedHat for about 4 years, and recently switched to Debian mostly because of dpkg.
I'm sorry, but dpkg as a package management tool is so superior to rpm, that it was like going from Windows to Linux again. Yes, Windows is nice if you've never experienced anything else, but once you tried something better, you really don't understand how you could have been so blind.
Redhat 5.x used rpm 2.x. Redhat 6.x uses rpm 3.x. Redhat 7 will be using rpm 4.0. Guess what, each major version of rpm is incompatible with the previous version. This coupled with the fact that I have never successfully upgraded a RedHat system (I usually either reinstall or do a manual update, as in go through my list of rpms and do a rpm -Uvh package.rpm from the CD, making sure I don't upgrade packages that are newer than those on the CD).
In Debian, I changed my sources.list and did a 'apt-get dist-upgrade'.
apt-get install will ask stop and ask for configuration issues. I have yet to find a rpm package that did that.
rpm -bb -clean --rmsource package.spec is supposed to compile, create rpm, and remove the source and spec file according to the docs. It never removed the spec file in rpm v3.x
lets say I wanted to remove xanim. I have aktion installed dependent on xanim.
In dpkg, I would do:
apt-get remove xanim
Since aktion depends on xanim, dpkg will ask if I want to remove xanim to and *do* it in the same step.
rpm -e xanim
Failes because aktion (if the dependency is even set up) has something dependent on it. You then have to do a rpm -e for each dependent.
Quite frankly, having used both, I just like dpkg much better, I wish all Linux distributions would just bite the bullet and standardize on it. Heck, if each major version of rpm is uncompatible with the previous version, it's no harder to go over to dpkg than to go to the new rpm (just write a tool that convert the rpm database to dpkg's text based database).
I LOVE rpm! What could be easier than rpm -Uvh file.rpm?
apt-get install package.
Try downloading gnucash and install it. It will fail with a bunch of dependencies. Of course, it's close to impossible to find the where those programs/libraries are, and if you find them, you can't find the rpms for them.
In Debian, 'apt-get install' will retrieve the dependencies too.
Why can't American libraries do like the Norwegian libraries do, have an adult section and children's section? I remember when I grew up, you had to have adult supervision if you wanted to go into the adult section.
Not that the adult section had anything pornographic, but it did have some mature subjectmatters (like war, death etc etc), while the children section had stuff more geared towards kids (there is a difference between a history book written for fifth graders and a history book written for college students).
Why didn't the guy block everything by default, and then let selected services through?
Here is easy firewall rules:
/sbin/ipchains -P input DENY # deny everything by default
# local have full access
/sbin/ipchains -A input -i lo -j ACCEPT
# let some basic services through
/sbin/ipchains -A input -p udp --sport domain --dport 1024: -j ACCEPT
/sbin/ipchains -A input -p tcp --sport domain --dport 1024: -j ACCEPT # not strictly necessary, but some dns services return answers using tcp
/sbin/ipchains -A input -p tcp --sport telnet --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport ftp --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport ftp-data --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport ssh ! -y -j ACCEPT # ssh uses a lower numbered port when you want RSA access
/sbin/ipchains -A input -p tcp --sport www --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport https --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport smtp --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport pop3 --dport 1024: ! -y -j ACCEPT # note that redhat calls the port pop-3
# let some icmp messages through
/sbin/ipchains -A input -p icmp --icmp-type pong -j ACCEPT
/sbin/ipchains -A input -p icmp --icmp-type destination-unreachable -j ACCEPT
# finally, add a catch all logging
/sbin/ipchains -A input -l
you need to set your ftp to passive=off (check prefs_v3 if you are using ncftp). You can expliclty deny addresses from the private network block, but according to the IPCHAINS-HOWTO there is a better way to do it. Check it out.
When you finish, type '/sbin/ipchains-save > ipchains.rules' to save it, and '/sbin/ipchains-restore ipchains.rules' to restore the rules.
Re:Left it a little late.
on
Qt Going GPL
·
· Score: 1
Eh, Troll Tech/QT is not KDE. KDE uses Trolltech's free technology, but QT does not belong to the KDE project.
The failure of KDE in the Linux/OpenSource environment will not affect Troll Tech in any way. The GNOME people doesn't have Trolls 'by the balls', anymore than Microsoft has VALinux by the balls (competing in different fields).
But, being an informed reader, you probably already knew that, so what was your point again?
What I'm saying is, what if you have a slow connection at home, but have access to a fast connection somewhere else (for instance at work). In those cases, an ISO is nice (and better than the pseudo-image thingie they have now. Tried it, didn't work).
You know, information wants to be free, free to be sold, repackaged, used, and anything people can come up with no matter what the original author's wants are.
Slashdot Mirror
Debian is hard to install.
Is still really true anymore? Granted, I'm not exactly a Linux newbie, but the simple installation option, where you install collections instead of individual packages, aren't that bad.
If the real storyline in any way resembles the fake ones on the site, he could have been sued for not given credit (remember the Spielberg movie, Amistad a couple of years back. He got sued even though the movie was based on a historic event, and then we have the Eddie Murphy movie, Back to America (?), Whoopie Goldberg's "Sister Act". Lots of examples).
Why are you downloading the whole sourcetree?
.src.rpm keep the pristine source and the patches separately before compilation).
You download it once after installation. After that, just download the patches. 1 Mb should be pretty fast, even on a slow connection.
And if the distributions would just give us a kernel source that wasn't patched to heck, it would be even easier (although I think Redhat's
No, pick any dictatorships, and you would find a government who is more paranoid.
Eh, you haven't had problems with Sendmail?
And here I thought Sendmail was on top of the list of buggy programs which lead to security problems. Guess I was wrong.
It's mentioned that KDE is not included, which is true, but only tells half of the story.
/etc/apt/sources.list, which has a list of sites (web and ftp), to check for new packages.
Most (if not all) Debian users install applications using 'apt-get install'. apt-get uses a file
Previously, if you wanted to install KDE, you would just add the line
deb http://kde.tdyc.com stable kde
to your sources.list
You would then install KDE like you would do any other Debian packages. From a user's pov, there would be no difference from having KDE included. In fact, some people install their GNOME this way (they added a option pointing to the Helix site, so the system installs HELIX GNOME instead of 'normal' Debian GNOME).
This is one reason I saw no reason to cry about the suggestion that Debian 'not include' non-free.
Well, considering the fact that RedHat and the commercial distributions business model is not to make money on the CD but rather the services, it shouldn't matter much.
And even though apt-get is great, I wouldn't be using it to upgrade a whole distribution if I was on a dial-up line (I'm sorry, but I can't wait 15 hours+ to upgrade/install my system).
There is, dpkg. If you don't want to use Debian, Stormix and Corel is using this package system too.
Who are you to tell what the "Linux Community" is should or shouldn't do? If the both KDE and GNOME teams decide to spend the rest of their natural life writing notepad clones, guess what? You don't have a say in the matter.
You're not paying them to do what they're doing. And just because you happen to use somebody's program, don't pretend that the author 'owe' you anything.
As to dependencies. You must have a lot of time on your hand. I fail to see what I can learn from the fact that application Foo depends on library FuuBarLib.so.1.0.2.5-1 and FaabarLib.so.3.32.102.2, but won't work with FuuBarLib.so.1.0.1.4-3. Of course, since most of the time, the documentation (if there are any) only mentions that it depends on FuuBarLib.so.1.0.2.5-1. Nowhere does it mention where this particular library is found, nor what the package it might be found in.
And what are you doing, using RPM if you want to know what is installed on your system? Just roll your own distribution and feel really 3L337.
Remember, just because something is properly installed on your system, doesn't mean that you can't download the sourcecode and check it out. You just don't have to do it if you don't want to.
Both of them only specify dependencies by name, rather than by function. Actually, there is a hack to make Debian depend on function. For instance, mutt depends on a mail server to work. Now exim, sendmail and qmail will all satisfy this dependency. Create a virtual (forget the official name for it) package that mutt depends on, for instance smtp-daemon package. Make exim, sendmail and qmail satisfy this dependency. So, dpkg will satisfy by function rather than package name.
If you don't like Debian, use Stormix then. It uses .debs too, *and* can still use the deb packages from the Debian website.
I used RedHat for about 4 years, and recently switched to Debian mostly because of dpkg.
I'm sorry, but dpkg as a package management tool is so superior to rpm, that it was like going from Windows to Linux again. Yes, Windows is nice if you've never experienced anything else, but once you tried something better, you really don't understand how you could have been so blind.
Redhat 5.x used rpm 2.x. Redhat 6.x uses rpm 3.x. Redhat 7 will be using rpm 4.0. Guess what, each major version of rpm is incompatible with the previous version. This coupled with the fact that I have never successfully upgraded a RedHat system (I usually either reinstall or do a manual update, as in go through my list of rpms and do a rpm -Uvh package.rpm from the CD, making sure I don't upgrade packages that are newer than those on the CD).
In Debian, I changed my sources.list and did a 'apt-get dist-upgrade'.
apt-get install will ask stop and ask for configuration issues. I have yet to find a rpm package that did that.
rpm -bb -clean --rmsource package.spec is supposed to compile, create rpm, and remove the source and spec file according to the docs. It never removed the spec file in rpm v3.x
lets say I wanted to remove xanim. I have aktion installed dependent on xanim.
In dpkg, I would do:
apt-get remove xanim
Since aktion depends on xanim, dpkg will ask if I want to remove xanim to and *do* it in the same step.
rpm -e xanim
Failes because aktion (if the dependency is even set up) has something dependent on it. You then have to do a rpm -e for each dependent.
Quite frankly, having used both, I just like dpkg much better, I wish all Linux distributions would just bite the bullet and standardize on it. Heck, if each major version of rpm is uncompatible with the previous version, it's no harder to go over to dpkg than to go to the new rpm (just write a tool that convert the rpm database to dpkg's text based database).
I LOVE rpm! What could be easier than rpm -Uvh file.rpm?
apt-get install package.
Try downloading gnucash and install it. It will fail with a bunch of dependencies. Of course, it's close to impossible to find the where those programs/libraries are, and if you find them, you can't find the rpms for them.
In Debian, 'apt-get install' will retrieve the dependencies too.
Plus, most homeusers don't need a fullfledged dns server. They just need a dns cache, which dnscache does well.
If you want dns server, go for tinydns.
Why can't American libraries do like the Norwegian libraries do, have an adult section and children's section? I remember when I grew up, you had to have adult supervision if you wanted to go into the adult section.
Not that the adult section had anything pornographic, but it did have some mature subjectmatters (like war, death etc etc), while the children section had stuff more geared towards kids (there is a difference between a history book written for fifth graders and a history book written for college students).
Why didn't the guy block everything by default, and then let selected services through?
Here is easy firewall rules:
/sbin/ipchains -P input DENY # deny everything by default
# local have full access
/sbin/ipchains -A input -i lo -j ACCEPT
# let some basic services through
/sbin/ipchains -A input -p udp --sport domain --dport 1024: -j ACCEPT
/sbin/ipchains -A input -p tcp --sport domain --dport 1024: -j ACCEPT # not strictly necessary, but some dns services return answers using tcp
/sbin/ipchains -A input -p tcp --sport telnet --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport ftp --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport ftp-data --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport ssh ! -y -j ACCEPT # ssh uses a lower numbered port when you want RSA access
/sbin/ipchains -A input -p tcp --sport www --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport https --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport smtp --dport 1024: ! -y -j ACCEPT
/sbin/ipchains -A input -p tcp --sport pop3 --dport 1024: ! -y -j ACCEPT # note that redhat calls the port pop-3
# let some icmp messages through
/sbin/ipchains -A input -p icmp --icmp-type pong -j ACCEPT
/sbin/ipchains -A input -p icmp --icmp-type destination-unreachable -j ACCEPT
# finally, add a catch all logging
/sbin/ipchains -A input -l
you need to set your ftp to passive=off (check prefs_v3 if you are using ncftp). You can expliclty deny addresses from the private network block, but according to the IPCHAINS-HOWTO there is a better way to do it. Check it out.
When you finish, type '/sbin/ipchains-save > ipchains.rules' to save it, and '/sbin/ipchains-restore ipchains.rules' to restore the rules.
Eh, Troll Tech/QT is not KDE. KDE uses Trolltech's free technology, but QT does not belong to the KDE project. The failure of KDE in the Linux/OpenSource environment will not affect Troll Tech in any way. The GNOME people doesn't have Trolls 'by the balls', anymore than Microsoft has VALinux by the balls (competing in different fields). But, being an informed reader, you probably already knew that, so what was your point again?
No, use Debian because it has the best package management system.
What I'm saying is, what if you have a slow connection at home, but have access to a fast connection somewhere else (for instance at work). In those cases, an ISO is nice (and better than the pseudo-image thingie they have now. Tried it, didn't work).
And if you have a slow connection?
On Linux, wchar_t is typedef long. Also, libstdc++ still does not have stream support for wchar_t.
>>Now, if they were to make a Batman movie with the help of Frank Miller or Alan Moore, that would be something I'd like to see.
Eh, Frank Miller wrote the screenplay for RoboCop 3, the worst in the series.
Doesn't apt-get dist-upgrade also install packages that you didn't have originally?
Say, I have a system without X, won't dist-upgrade install X too?
I thought ./'ers didn't believe in copyright?
You know, information wants to be free, free to be sold, repackaged, used, and anything people can come up with no matter what the original author's wants are.
Why was this considered a 'great article'. It was disjointed, incoherent, and it had what, five sentences per page?
Business are competitive? Wov, what a surprise.