Slashdot Mirror

Or you can just install the enterprise-ready version right from the original source here. Why settle for imitations when you can have the original?

You mean like these?

Debian may have a slight bug squashing problem. But judging by the chart, the new submission rules are leveling this out. IF this was a stock chart I would say "BUY!"

And a small stab at ubuntu, the little disk I got had the (IIRC) exploitable password problem. (good thing it was being tested in a VM) Anyway, that did that for me. The disk was purposly shreded after that.

My understanding is that Ubuntu is based on Debian. Not vice-versa. Sort of like Suse is based on Slack. FC on RH.

I use debian on all my linux desktop boxes, except for the video editing box still needs xp cause cinelerra still ain't there yet--(not a debian problem though.) and servers I use fbsd. Use what works. If DSL 2.0 on your flashdrive works, use it, if you need to boot on a knopix disk, why not!? If your grandmother loves suse, go for it. If your girlfriend likes xp, then great. (hint make it dual boot.)

peace in - bush out

Amen to that. To rehash what I said in a earlier thread, I bought a wifi card which had an GPL driver provided by the manufacturer themselves, only to find that it had not been merged into the Debian kernel or made into a binary deb file, and I had to apt-get install the source and compile the damn thing myself. Barely an improvement on downloading a tar.gz from the vendor's site.

Meanwhile, Ubuntu 5.10 supported the card out-of-the-box. No compiles, re-configurations, or downloading additional software needed.

Nearly 7 months later, Debian *still* doesn't have binary driver packages for the Ralink card, even though they've discussed it since last year. I know Debian's slow and conservative, but not shipping a driver for a card where a GPL driver already exists is extremely unhelpful. Especially when a vendor provides a GPL driver like we've always asked them to, it makes the community look bad if the distro doesn't actually merge it.

> "one of the Debian Project Leader candidates (and self proclaimed "Debian Pope") Jonathan Walther"...

Any member of the project (about 800-1000 people worldwide at this point) can toss their hat into the ring. Saying that he was a candidate is true, but the implications may not be as serious as they seem. Mr. Walther was the first person ever to be ranked below "None of the Above" in a Debian Project Leader election (in the 2005 elections) In the 2006 DPL election, two candidates came in below "None of the Above", but one of them, Ari Pollak, was running as an openly "joke" candidate; his platform involved allowing his cat help him make decisions, and putting snakes on Plan9 (don't ask). Despite this, Mr. Pollak still managed to garner more votes than Mr. Walther, who was again, dead last.

I wouldn't worry about the Debian leadership until someone like Mr. Walther can at least beat "None of the Above" in an election. :)

> "one of the Debian Project Leader candidates (and self proclaimed "Debian Pope") Jonathan Walther"...

Any member of the project (about 800-1000 people worldwide at this point) can toss their hat into the ring. Saying that he was a candidate is true, but the implications may not be as serious as they seem. Mr. Walther was the first person ever to be ranked below "None of the Above" in a Debian Project Leader election (in the 2005 elections) In the 2006 DPL election, two candidates came in below "None of the Above", but one of them, Ari Pollak, was running as an openly "joke" candidate; his platform involved allowing his cat help him make decisions, and putting snakes on Plan9 (don't ask). Despite this, Mr. Pollak still managed to garner more votes than Mr. Walther, who was again, dead last.

I wouldn't worry about the Debian leadership until someone like Mr. Walther can at least beat "None of the Above" in an election. :)

> "one of the Debian Project Leader candidates (and self proclaimed "Debian Pope") Jonathan Walther"...

Any member of the project (about 800-1000 people worldwide at this point) can toss their hat into the ring. Saying that he was a candidate is true, but the implications may not be as serious as they seem. Mr. Walther was the first person ever to be ranked below "None of the Above" in a Debian Project Leader election (in the 2005 elections) In the 2006 DPL election, two candidates came in below "None of the Above", but one of them, Ari Pollak, was running as an openly "joke" candidate; his platform involved allowing his cat help him make decisions, and putting snakes on Plan9 (don't ask). Despite this, Mr. Pollak still managed to garner more votes than Mr. Walther, who was again, dead last.

I wouldn't worry about the Debian leadership until someone like Mr. Walther can at least beat "None of the Above" in an election. :)

One example:

(c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software;

From: "Brian M. Carlson" <...>
Date: Wed, 17 May 2006 12:02:34 +0000
 
[...]
> Could someone please explain to me why paragraph 2(f) does not pose a
> problem? I couldn't find ANY discussion about the license on Debian legal
> which surprises me a little bit, but then maybe I just missed the
> relevant parts of the license. Anyway, as a non-lawyer I'm surprised
> that we seem to accept that we have to "defend and indemnify Sun".
 
Also, section 4 poses a major issue. If, for any reason, the Linux
kernel doesn't do something that Java requires, then we are obligated to
either fix it or inform everyone who has acquired Java from us.
 
Section 10 is not possible with our infrastructure. The ftp-master
scripts merely remove the package from the tag database, not the archive
(at least until there are no dependencies), and not from all of our
mirrors.
 
Section 2(b) prohibits allowing people to develop software with Java
that is to be run on another system.
 
Section 2(c) prohibits us from using the software in conjunction with C,
C++, Perl, Python, or *any reasonable Turing-complete programming
language*.
 
Section 12 requires that this software be in non-US/non-free. It is
not, which is not only a violation of the license, but a violation of
United States law.
 
This conflicts with other project policies and exposes Debian/SPI to
major legal liabilities. I think that this should be removed from the
archive as soon as possible, preferably before the next mirror pulse.
[...]

For example the License states "you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software;". The FAQ states "It is of course perfectly OK to ship programs or libraries that use the JDK... there is nothing in the DLJ intended to prevent you from shipping alternative technologies with your OS distribution." This explanation doesn't match the license! And the FAQ states: "nothing in this FAQ is intended to amend the license, so please consult the license itself for the precise terms and conditions that actually apply."

Secondly: "(f) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from (i) the use or distribution of your Operating System, or any part thereof, in any manner, or..." If you analyse the section Debian is liable even if they do nothing wrong so long as a modification is made under Debian's control.

Follow this thread (click on the `Follow-Ups' links) to confirm what I've highlighted.

Here's the discussion about it on debian-legal. The new debian package for Sun's Java(tm) is intended to go into non-free, indicating they don't think it's really open source. Furthermore, it seems the debian-legal people were not consulted first, and they are not happy with the license even for a non-free package.

Actually, there is a lot of discussion going on right now on the debian-devel and debian-legal mailing lists about if the new SUN License is compatible. See this thread on debian-legal to follow the discussion. People are calling for Sun's Java to be removed from non-free.

Not from Debian, just from Anthony Towns. He was soundly thrashed for this on debian-legal and debian-devel -- he's pretty much the only person who seems to believe Sun's new license is any good.

Correct.

I suppose Debian has only accepted it into non-free?

I suppose Debian has only accepted it into non-free?

I suppose Debian has only accepted it into non-free?

Here's the debian.org listserv postmortum. They subsequently discovered an error in do_brk(), which is described in eweek and has the CVE of CVE-2003-0961. Slashdot discussion here.

Keep in mind that support varies between distros, as well. I got a Ralink-based PCMCIA wireless card for my laptop last fall, and found that Debian, Suse, and Knoppix did not support it, even though Ralink themselves had released GPL drivers for it. To quote HP's Linux wireless page: Like for the RT2400, Ralink wrote a Linux driver for the RT2500 and RT2750, but this time they decided to release it themselves as GPL. Moreover, the driver is functional, full of features and with a graphical utility, so this represent a very generous contribution to the OpenSource community.

Yes, I tried both testing and unstable for Debian, and fairly newish versions of Knoppix and Suse LiveEval. I suppose I could have compiled them myself for Debian, but I want to avoid that kind of hassle.

Luckily, I had a spare partition, and I found that Ubuntu 5.10 (Badger) supported the Ralink card just fine.

Suse LiveEval on the other hand supported my built-in Broadcom chipset, apparently through ndiswrapper.

I must say that I lost some faith in Debian through this. I mean, a company does what we've always asked companies to do - release full GPL drivers, which is more than what other companies in the field have done - and the Debian team did not live up to their expectations. I found out that the drivers had been discussed for inclusion since October of '05, but as of today, May of '06, there are only source packages available for Debian.

Keep in mind that support varies between distros, as well. I got a Ralink-based PCMCIA wireless card for my laptop last fall, and found that Debian, Suse, and Knoppix did not support it, even though Ralink themselves had released GPL drivers for it. To quote HP's Linux wireless page: Like for the RT2400, Ralink wrote a Linux driver for the RT2500 and RT2750, but this time they decided to release it themselves as GPL. Moreover, the driver is functional, full of features and with a graphical utility, so this represent a very generous contribution to the OpenSource community.

Yes, I tried both testing and unstable for Debian, and fairly newish versions of Knoppix and Suse LiveEval. I suppose I could have compiled them myself for Debian, but I want to avoid that kind of hassle.

Luckily, I had a spare partition, and I found that Ubuntu 5.10 (Badger) supported the Ralink card just fine.

Suse LiveEval on the other hand supported my built-in Broadcom chipset, apparently through ndiswrapper.

I must say that I lost some faith in Debian through this. I mean, a company does what we've always asked companies to do - release full GPL drivers, which is more than what other companies in the field have done - and the Debian team did not live up to their expectations. I found out that the drivers had been discussed for inclusion since October of '05, but as of today, May of '06, there are only source packages available for Debian.

Keep in mind that support varies between distros, as well. I got a Ralink-based PCMCIA wireless card for my laptop last fall, and found that Debian, Suse, and Knoppix did not support it, even though Ralink themselves had released GPL drivers for it. To quote HP's Linux wireless page: Like for the RT2400, Ralink wrote a Linux driver for the RT2500 and RT2750, but this time they decided to release it themselves as GPL. Moreover, the driver is functional, full of features and with a graphical utility, so this represent a very generous contribution to the OpenSource community.

Yes, I tried both testing and unstable for Debian, and fairly newish versions of Knoppix and Suse LiveEval. I suppose I could have compiled them myself for Debian, but I want to avoid that kind of hassle.

Luckily, I had a spare partition, and I found that Ubuntu 5.10 (Badger) supported the Ralink card just fine.

Suse LiveEval on the other hand supported my built-in Broadcom chipset, apparently through ndiswrapper.

I must say that I lost some faith in Debian through this. I mean, a company does what we've always asked companies to do - release full GPL drivers, which is more than what other companies in the field have done - and the Debian team did not live up to their expectations. I found out that the drivers had been discussed for inclusion since October of '05, but as of today, May of '06, there are only source packages available for Debian.

You mean something like module assistant?

The real reason for choosing Ubuntu/Debian would be the Debian Policy, not any packaging format. A quote from the linked page:

People often say how they came to Debian because of apt-get, or that apt is the killer app for Debian. But apt-get is not what makes the experience so great: apt-get is a feature readily reproduced (and, in my opinion, never equalled), by other distributions -- call it urpmi, apt4rpm, yum, or what have you. The differentiating factor is Debian policy, and the stringent package format QA process (look at things like apt-listchanges, apt-list-bugs, dpkg-builddeps, pbuilder, pbuilder-uml -- none of which could be implemented so readily lacking a policy (imagine listchangelog without a robust changelog format)). It is really really easy to install software on a Debian box.

This resembles cargo cult religions: that is, apt-get is the visible aspect of Debian's policy system, the same way that cargo-cult practices saw runways and other characteristics as the source of western goods ("cargo"), and built their own replicas, complete with fake wooden headphones for control towers. In the same way, other distributions have created the shallow visible aspect of Debian's packaging infrastructure, without addressing the deep issues of policy. Worse: the conflicts of technical requirements and marketing / economic imperatives often work at cross purposes. Less perversely for most GNU/Linux distros than for proprietary software, but still clearly present.

The real reason for choosing Ubuntu/Debian would be the Debian Policy, not any packaging format. A quote from the linked page:

People often say how they came to Debian because of apt-get, or that apt is the killer app for Debian. But apt-get is not what makes the experience so great: apt-get is a feature readily reproduced (and, in my opinion, never equalled), by other distributions -- call it urpmi, apt4rpm, yum, or what have you. The differentiating factor is Debian policy, and the stringent package format QA process (look at things like apt-listchanges, apt-list-bugs, dpkg-builddeps, pbuilder, pbuilder-uml -- none of which could be implemented so readily lacking a policy (imagine listchangelog without a robust changelog format)). It is really really easy to install software on a Debian box.

This resembles cargo cult religions: that is, apt-get is the visible aspect of Debian's policy system, the same way that cargo-cult practices saw runways and other characteristics as the source of western goods ("cargo"), and built their own replicas, complete with fake wooden headphones for control towers. In the same way, other distributions have created the shallow visible aspect of Debian's packaging infrastructure, without addressing the deep issues of policy. Worse: the conflicts of technical requirements and marketing / economic imperatives often work at cross purposes. Less perversely for most GNU/Linux distros than for proprietary software, but still clearly present.

Debian has libgcj too...

Also, if you read the other link it says "During the past weeks there has been close collaboration between Sun engineers and Debian and Ubuntu developers."

"Can anyone tell me why a person would want to use Ubuntu on a server, as opposed to just using Debian?"

http://packages.debian.org/cgi-bin/search_packages .pl?keywords=mod-php&searchon=names&subword=1&vers ion=stable&release=all

vs

http://packages.ubuntu.com/cgi-bin/search_packages .pl?keywords=mod-php&searchon=names&subword=1&vers ion=breezy&release=all

And in less than 1 month, 5.1.2 will be available on stable ubuntu.

If I want up to date packages on debian, my options are:
1. Roll my own (if I do this, why am I running debian?)
2. Run testing (minus security updates....)
3. Add in backports (oh the humanity)

In order to get php5 period, or an up to date php4, I cannot run a "sane" debian install. I CAN, however, run a sane, and in fact COMMERCIALLY SUPPORTABLE, ubuntu install.

Add to this the fact that as of 6.06 ubuntu has seperatly tuned desktop and server kernels and you can see how ubuntu is shaping up.

Thanks.

Perhaps we'll see a repository for Java .debs at last, eh?

You must have missed the big news: official packages of Sun Java .debs were uploaded into Debian's non-free archive yesterday.

The announcement

Link to the page for the "source" package (I put "source" in quotes since it actually contains tarballs of the binaries, but you can obtain real source code in the sun-java5-source binary Debian package.)

License and FAQ about the license under which these packages are made available (note in particular that it permits sublicensing for derived distributions).

Perhaps we'll see a repository for Java .debs at last, eh?

You must have missed the big news: official packages of Sun Java .debs were uploaded into Debian's non-free archive yesterday.

The announcement

Link to the page for the "source" package (I put "source" in quotes since it actually contains tarballs of the binaries, but you can obtain real source code in the sun-java5-source binary Debian package.)

License and FAQ about the license under which these packages are made available (note in particular that it permits sublicensing for derived distributions).

Perhaps we'll see a repository for Java .debs at last, eh?

You must have missed the big news: official packages of Sun Java .debs were uploaded into Debian's non-free archive yesterday.

The announcement

Link to the page for the "source" package (I put "source" in quotes since it actually contains tarballs of the binaries, but you can obtain real source code in the sun-java5-source binary Debian package.)

License and FAQ about the license under which these packages are made available (note in particular that it permits sublicensing for derived distributions).

Perhaps we'll see a repository for Java .debs at last, eh?

While I make my living programming Java, I think it is a stretch to say Java performs on par with C. Perhaps good implementations in Java are better than bad implementations in ... whatever, but in the general case an interpreted language is one order of magnitude slower than a natively compiled one. For the record, XML Spy is a piece of shit, and I question whether its implmentation is even "natively compiled." Granting it is for the sake of argument, it's still a piece of shit and it's no surprise an enterprise XSLT engine written in Java outperformed it.

Check the great language shootout . I certainly don't believe these benchmarks are perfectly fair, but I do think that Java and C are well represented languages. The results speak for themselves. Java isn't even close to C in memory or runtime efficiency.

I can speak from experience that garbage collection IS a serious issue in corporate IT. Many enterprise applications that are loose with object creation can quickly create objects faster than they are collected and crash the container. This is under heavy load. Of course, a C application with a memory leak does not even have the benefit of garbage collection to save it. But C applications are generally FAR more memory efficient (just look at the shootout!). It is no secret that Java also has severe memory footprint issues (Hello 2 gb Websphere instance). In C you can malloc a chunk of memory and continually repurpose it where in Java you must continually create and throw away objects. Yes, the whole operation is optimized, but the differences are like night and day. They say Java 1.6 "Mustang" will address the footprint issues, but there is no way it will be nearly as efficient as C.

Java is many wonderful things. It is a highly productive language thanks to the best libraries and components. No other language can boast that kind of consistency and interoperability.

But do stop fooling yourself. The Sun JVM is slower than GCC compiled code. Compiler researchers have known for years there is an order of magnitude difference between native and interpreted code across the board. Don't use bogus benchmarks and ignore the fact that different language implementations have real performance characteristics to match their capabilities.

This is what I used when I switched to Dvorak:
http://lists.debian.org/debian-user/2002/07/msg056 54.html

Can you show a real example instead of timing the amount of nanoseconds it takes to add two numbers together?

Well, with some basic benchmarks Ruby is indeed slower than javascript, though it uses massively less memory. Compared to Perl it does very well in one test, but is notably slower for everything else. Compared to Python it is occasionally slightly better in terms of memory, but consistently significantly slower. Compared to Psyco Python it simply gets its ass handed to it.

None of which says that Ruby is a bad language, nor inappropriate for the uses you are putting it to. It does say that it is quantatively slower than many of the alternatives that the OP mentioned.

Jedidiah.

Can you show a real example instead of timing the amount of nanoseconds it takes to add two numbers together?

Well, with some basic benchmarks Ruby is indeed slower than javascript, though it uses massively less memory. Compared to Perl it does very well in one test, but is notably slower for everything else. Compared to Python it is occasionally slightly better in terms of memory, but consistently significantly slower. Compared to Psyco Python it simply gets its ass handed to it.

None of which says that Ruby is a bad language, nor inappropriate for the uses you are putting it to. It does say that it is quantatively slower than many of the alternatives that the OP mentioned.

Jedidiah.

Can you show a real example instead of timing the amount of nanoseconds it takes to add two numbers together?

Well, with some basic benchmarks Ruby is indeed slower than javascript, though it uses massively less memory. Compared to Perl it does very well in one test, but is notably slower for everything else. Compared to Python it is occasionally slightly better in terms of memory, but consistently significantly slower. Compared to Psyco Python it simply gets its ass handed to it.

None of which says that Ruby is a bad language, nor inappropriate for the uses you are putting it to. It does say that it is quantatively slower than many of the alternatives that the OP mentioned.

Jedidiah.

Can you show a real example instead of timing the amount of nanoseconds it takes to add two numbers together?

Well, with some basic benchmarks Ruby is indeed slower than javascript, though it uses massively less memory. Compared to Perl it does very well in one test, but is notably slower for everything else. Compared to Python it is occasionally slightly better in terms of memory, but consistently significantly slower. Compared to Psyco Python it simply gets its ass handed to it.

None of which says that Ruby is a bad language, nor inappropriate for the uses you are putting it to. It does say that it is quantatively slower than many of the alternatives that the OP mentioned.

Jedidiah.

From what I've read, I think that might be because some developers on the Linux camp have been a factor of irritation when they produce Linuxisms is C code, foresaking portability.You see this phenomenom mentioned in what regards GNOME in the article. It almost sounds as if GNOME developers are a clique that don't give a shit about other projects.

Another famous little war was Linuxers resistance (glibc maintainers, to be exact) resistance against the safer strlcpy and strlcat functions from OpenBSD's libc:
See these amazing threads that illustrate prejudice against the OpenBSD developers. After 2 or smth years, they finally gave in and the OpenBSD functions are part of glibc. But here's my sample:

Here's a Debian developer calling on GNOME developer's biased and prejudiced views against OpenBSD's innovation for safer C programming:
http://lists.debian.org/debian-devel/2002/03/msg00 305.html

Here's the guy that sends the patch for glibc: http://sources.redhat.com/ml/libc-alpha/2000-08/ms g00052.html

Here's the amazing answer from the glibc's maintainer Ulrich Drepper, a real insight into strong software engineering principles. No wonder Linux boxes got so rootkitted:
This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy). http://sources.redhat.com/ml/libc-alpha/2002-01/ms g00002.html

Theo's take:
TdR: They're still not in glibc. They're everywhere else. They're in Solaris. We invented them two years ago. They're showing up in vendor operating systems. We made a convincing argument why these things are necessary. http://www.ddj.com/184404914

Look at CERT's list for "glibc" vulnerabilites here. Please draw comparisons with BSDs. Answer honestly: who's got bragging rights?

The HURD is one of many possible kernels on which the GNU system can run. The first GNU kernel was called TRIX, and was developed at MIT in the 80s. It was never very advanced, and much work was done instead using the GNU system on proprietary kernels from folks like Sun and HP as a result of its limitations. The FSF having very limited resources had to prioritise and economise. Rather than pull scarce resources off other, equally crucial projects to bring TRIX up to snuff, it was decided to pursue rights from CMU to use the Mach kernel. This would jumpstart the kernel project for free, without diverting resources needed elsewhere.

The HURD did, actually, exist in 1991. In that year, after several years of negotiation with CMU, all necessary issues were resolved and the longstanding plan to build a new GNU kernel on top of Mach began. Linus famously remarked in an early usenet posting that he expected in a few years everyone would be using it and his project wouldn't really matter.

What happened instead, of course, is that he was so successful at producing a good, working free kernel, people started running GNU on top of it, and the HURD team felt free to pursue long-term experimental strategies instead of feeling pressure to produce a working product quickly.

You can run the HURD, although it's still experimental and not recommended for production systems. The most popular way to set it up is through debian.

The latest version of Nautilus is 2.14.0, which is included in Fedora Core 5.

The version of Nautilus included with Fedora Core 5 is 2.14.0.

Both Debian Unstable & Ubuntu Dapper come with Nautilus 2.14.1 (and I'm sure other distros do too:

Debian Unstable
Ubuntu Dapper

howabout here... or here... or even here!

There's no such thing as "Linux userland". Some of the reasons for porting the FreeBSD kernel to the Debian GNU system are listed on the wiki: http://wiki.debian.org/Debian_GNU/kFreeBSD (for that question specifically check the FAQ).

What is very much alive is the Debian GNU/kFreeBSD project. Get the best of both worlds baby.

Here you go. Setup your own repository, either on a central server, or on removeable media. I guess slipstreaming is possible also, but I find this solution a lot more elegant...

Not that I use vim or would ever want to (I use and code for Emacs), but Debian has had it in experimental for some time:

  http://packages.debian.org/experimental/editors/vi m

Linux on SGI's MIPS workstations is already pretty usable. The core site is at http://www.linux-mips.org/, plus both Gentoo and Debian have functional MIPS Ports [ G | D ].

Between both distro's, most of SGI's systems from the Indy to the Octane are supported (although support for the individual components is dependent on the machine). We're hoping to get our hands on some of their newer stuff, like a Fuel or an Origin 300 to see how hard that will be to port to (especially the R14000), but the dream is to one day (hopefully before the year 3000) get Linux running on a quad-cpu Tezro :)

Linux on SGI's MIPS workstations is already pretty usable. The core site is at http://www.linux-mips.org/, plus both Gentoo and Debian have functional MIPS Ports [ G | D ].

Between both distro's, most of SGI's systems from the Indy to the Octane are supported (although support for the individual components is dependent on the machine). We're hoping to get our hands on some of their newer stuff, like a Fuel or an Origin 300 to see how hard that will be to port to (especially the R14000), but the dream is to one day (hopefully before the year 3000) get Linux running on a quad-cpu Tezro :)

Failing that, you could just install the Debian distro of it from here: http://www.debian.org/ports/hurd/hurd-cd

But do note that java-package, in the contrib section, enables installation of Sun (or Blackdown or IBM) Java as a Debian package. You still have to download from Sun and go through the license agreements, though, but it's still somewhat better than installing manually.

Then I got these fake-ass niggaz I first drew with
Claimin that they non-violent, talkin like they *He's not how he used to be*
Spit venom in interviews, speakin on reunions
Move units, then talk shit and we can do this
Until then - I ain't even speakin your name
Just keep my name outta yo' mouth and we can keep it the same
Nigga, it ain't that I'm too big to listen to the rumors
It's just that I'm too damn big to pay attention to 'em
That's the difference