Slashdot Mirror

You are either misinformed or a liar. The nVidia Linux drivers support x86, x86-64, and IA-64 architectures. This is actually one more architecture than they support on Windows (no IA-64 for Windows systems).

I agree it would be nice to see open source replacements for the nVidia drivers, but please lets not spread or further any FUD about the current closed source drivers. nVidia has done a nice job with the drives. I use them without issue on two different x86-64 machines (one AMD, one Intel).

Or grab something like this patch: http://kerneltrap.org/node/1051 to do it automatically.

That way you programs can easily swap if you run low on active memory, but the cache won't pressure you into swapping even if you untar a 2 GB file.

Seems like OpenBSD's implementation does what DieHard claims, or at least some of it. See this interview from August 2005 for information:

http://kerneltrap.org/node/5584

Any thoughts?

http://kerneltrap.org/node/793

http://kerneltrap.org/node/2761

http://kerneltrap.org/node/7211

http://en.wikipedia.org/wiki/ReiserFS

http://kerneltrap.org/node/793

http://kerneltrap.org/node/2761

http://kerneltrap.org/node/7211

http://en.wikipedia.org/wiki/ReiserFS

http://kerneltrap.org/node/793

http://kerneltrap.org/node/2761

http://kerneltrap.org/node/7211

http://en.wikipedia.org/wiki/ReiserFS

Linus does not consider these modules to be "derived works". See http://kerneltrap.org/node/1735 (he doesn't mention the graphics drivers specifically, but it does make his general stance clear). Obviously it's a grey area, and he even says so, but it's (nominally) still his kernel and still up to him.

I suspect however that adding new and necessary interop functionality to Samba, a piece of software specifically made for interoperability, would be interpreted pretty damn quickly as a "derived" work, in which case it doesn't really matter how you attach it to the original work -- the GPL will still come into force.

When did OpenBSD start with randomization?

Actually, I'm pretty sure the NVIDIA Linux driver (which is closed source, written by NVIDIA) recently had a buffer overflow exploit. Good thing it only took them 2 years from the point of introducing the bug to fixing it. http://kerneltrap.org/node/7228

I never understood why I couldn't get a fast terminal prompt and have the remainder of the daemons start up in the background, all reniced to low priority during the initialization process, or maybe slowly started up to avoid disk contention. I personally amortize the bootup time by buying a bunch of ram, and dd'ing all the files in /usr/bin, /usr/lib/*.so, /lib/*.so, /etc and maybe /usr/share/apps, depending on how much ram I have. This pulls everything into the buffer cache and improves KDE startup significantly.

I'm sure I could optimize this by running some kind of kernel auditor that tracked every file that was run (executable) or loaded (.so), wrote out a list at shutdown, and reused that list to precache on reboot.

A few interesting links: http://kerneltrap.org/node/2157 , http://www.uwsg.iu.edu/hypermail/linux/kernel/0609 .2/2180/boot_linux_faster.pdf , http://initscripts-ng.alioth.debian.org/soc2006-bo otsystem/deliverable3.html , http://preload.sf.net/ , http://packages.ubuntu.com/dapper-backports/admin/ readahead .

That's exactly why "Hyper-Threading Technology" is disabled by default on FreeBSD, and probably other systems.

It's a know issue:
http://security.freebsd.org/advisories/FreeBSD-SA- 05:09.htt.asc
http://kerneltrap.org/node/5103

Cheers.

Linus isn't the only one. Ingo Molnar also got started on a Commodore. And so did I, for whatever that's worth!

LinuxBIOS supports several different types of payloads: Linux, Open Firmware, Etherboot, etc. If you are using a Linux kernel payload, then you probably don't want to be upgrading it often. In that case, you can set up the first kernel to kexec a second kernel (before kexec, there was a patch called the two kernel monte).

AMD64's 64-bit mode is definitely supported.

It's not trivial (yet) to boot a version of MS Windows with LinuxBIOS, but using Linux as a BIOS can give all sorts of benefits. One very interesting capability for people running beowulf clusters is that you can boot over any network device that Linux supports (e.g. Myrinet or Infiniband). That may not mean anything to a regular home user, but the point is that you have a whole lot more flexibility in what you can do. Even if you don't want to make it boot your home system over your wireless LAN, it does increase your freedom and it prevents people from nibbling away at the freedom you already have.

I would say freedom from future DRM really is the biggest incentive for trying out LinuxBIOS at home. You can avoid Intel's EFI standard (they're pushing for it to be on all desktops and servers), which will enable companies to inflict DRM on you. Linus has made some very good points about why EFI is not good. One way to look at EFI is that it is basically an OS, and not a very good one.

There are several white papers and tutorials that do a good job of explaining how LinuxBIOS works. Look at the LinuxBIOS documentation section.

I've gone over this before and eventually posted on Kerneltrap, and even when Slashdot reported on it nobody seems to have cared.

Games are more than pumping FPS.

(Ad yes Valve's babble about a "new programming strategy" to use multi-core CPUs is bullshit; it's simply easier to use threads to handle each object in the physics engine and each AI, and that's immensely helpful when you don't want to worry about scheduling making your game choppy due to too many threads on one CPU)

This is lame, I have been making the argument that FPS != game benchmark. Everyone always says "look dual core FPS is the same as single core, maybe 1 or 2 faster," and they don't even understand why it's 1 or 2 faster (because the few cycles used for AI and physics are out of the way...). It takes VALVE to come out and say it?

Yesterday I blew and made the same statements on kerneltrap. A little unscientific, but should cover the issue nicely.

Over 1gig of ram you get a performance hit (using highmem) and over 4gig that hit becomes worse (PAE), have a read of:
http://kerneltrap.org/node/2450
Also if you have enough swap to go over that tipping point, there will be a performance hit, albeit negligible since swap is slow enough already.
Plus the extra registers that were added to AMD64 can often improve performance significantly.

I must also say, that it is mostly thanks to the Alpha that such a large amount of open source software compiled cleanly right from the start on AMD64. Alpha was the first architecture that was pure 64bit, without any kind of 32bit mode, so people couldnt easily just run their apps in 32bit mode and leave them broken.

I was trying to give nvidia a piece of my mind, but their webform doesn't seem to work. So here are the email addresses I found:

    info@nvidia.com
    websupport@nvidia.com

for anyone lazy (like me), you might like to peruse this message:

Dear people of nVidia,

Since I care about my freedom and being in control of my own computer and its SECURITY, I choose to run free software only, but you make this very difficult. http://kerneltrap.org/node/7228 mentions a vulnerabillity in your driver which you have known about for about TWO YEARS. Things like this need to be fixed in ONE DAY. You have managed to completely lose my trust and respect. I will not be suckered any more into buying any product which is not properly supported, because it has superior performance. And properly supported means that the specifications of the hardware and a free software driver are available. I will not surrender my freedom to you or to anyone else anymore, ever.

I hope you will reconsider your actions and release your drivers as free software and make your hardware specifications available, such that current free software drivers can more fully support the features of your offerings, such as 3d acceleration(!) and dual outputs.

Sincerely,

[your name]

Well as I stated, it was a quote from the article, second link http://kerneltrap.org/node/7228

its the first comment on that page, I don't have an nvidia card on my Linux machine so I cannot verify it, but I figured since the current stable one has this hole, and the generic driver is lacking that here is another alternative that has 'reportedly' had the hole fixed

Well, you're mostly right.

See this: http://kerneltrap.org/node/7184

Still, you don't really know how much they're holding back. How many features are they not using in the open source driver?

But at least they have the security...

According to the first comment over on kerneltrap, this was fixed by NVidia last month in a beta release. However, the issue in question was not mentioned in the release notes.
http://kerneltrap.org/node/7228/
http://www.nvnews.net/vbulletin/showpost.php?s=878 67d1f473f5e912c412a23e19a8dc3&p=1027749&postcount= 11/
http://www.nzone.com/object/nzone_downloads_rel70b etadriver.html/

It's all about whether the binary driver is considered a derivative work.

See:

http://kerneltrap.org/node/1735

So, many binary drivers will conflict with the GPL.. The fact that they "help" Linux users in making more hardware compatible means that the GPL violations may be overlooked.. I think if Wii used binary kernel drivers with a Linux kernel, they would be in serious risk of litigation for violating the GPL.

http://kerneltrap.org/node/7184

Can you provide an example of a Firefox patch that reduced reliability.

Highly motivated people can often not devote as much time as they would like to OSS because they have to go to a regular job to pay for food etc.

There are a lot of key Linux developers who provide huge benefit to the community, but would like to make it pay so that they can make a fulltime job of it. Go look at what some people like Hans Reiser have to say http://kerneltrap.org/node/5654 "Doing GPL work is doing charity work in our current legal and economic framework. That should be and could be changed, but for now it is so. I have done my share of charity, and I would not have a problem doing proprietary work.", and http://www.namesys.com/ "For free software based on support revenues to be viable, people have to be more inclined to use our support service than they are to use the support services of persons who bundle our software with what they sell. Frankly, they are not, and this is why providing service on free software is failing as a business model for producing free software."

For my own part, I write OSS that saves people literally millions of dollars per year, yet I can only treat it as a hobby because it can't pay my bills.

Hopefully at some stage people start **paying** for stuff that is valuable to them. Unfortunately people grab what they can get for free.

Having good roads is very valuable, and you would not have those if they were not paid for. They are typically paid for by taxes because most people would not voluntarily dip into their pockets to pay for roads etc.

I think any methods that help get money into the hands of **key** OSS developers is a good thing.

Indeed, given the recent plight of NetBSD, it seems OpenBSD is poised to gain new support and momentum. Perhaps the potential demise of one BSD is simply to the benefit of another?

If only they provided Free and Open Source drivers for their wireless cards. Unfortunately, OpenBSD had to do that work.

Incorrect. No part of the Nvidia driver is licensed under the GPL (see /usr/share/doc/nvidia-*/copyright on a Debian distribution). The Linux kernel is licensed under the GPL, but Linus does not consider all binary-only kernel modules to be derived works (only some of them). See http://kerneltrap.org/node/1735.

Thus, our graphics drivers don't appear to be GPL violations.

Sure, but unfortunately EFI may be worse in some respects. Read this for more info. (Note: I'm a recent Mac convert and would love to be able to say that Apple has a perfect solution here...)

I totally agree. I commented about this earlier after reading the article. However after reading what someone else posted: http://kerneltrap.org/node/4484. I really get the fact that Stallman is perfectly happy with me not working in CS or programming if I need to make money from coding software. The above link needs to be spread around the net like wildfire. It goes to show how out of touch he really is. I have no intention of digging ditches the rest of my life. We all can't make money on the "lecture circuit" like you can Dick!

JA: What about the programmers...

Richard Stallman: What about them? The programmers writing non-free software? They are doing something antisocial. They should get some other job.

The fork was a good decision as Theo seems to be a good leader for OpenBSD, while NetBSD has none.
And Theo also also has more strict principles than Linus, in particular in the definition of "free". (See the kerneltrap interview).

Or to put it a third way, is there any situation where swapping is helpful, anymore?

Sure. Consider Andrew Morton's logic:

http://kerneltrap.org/node/3000

In your average program, most code never gets executed, and most data is never used. For a long-lived process, swapping out the unnecessary bits frees the memory for disk cache.

While you may improve overall performance, by minimizing the average completion time for operations, the downside is responsiveness. As a user, I don't care if Firefox reads cached images a few milliseconds faster (by reading from cache instead of disk) if I have to wait 3 seconds for Thunderbird to respond to my clicks (because it has to swap in) after I've been browsing for a while. Average speed be damned! :)

Having said that, I just set my swappiness to 100.

...unlike Linux, which uses it only when there's no other way (reactive)

There's an old discussion amongst various kernel developers about this issue which, even though it's a couple of years old, is almost certainly going to be more insightful than anything you'll read on slashdot. You'll note that there doesn't seem to be a ready consensus even amongst the folks who know this stuff best, so if you see anyone posting the "correct" answer, call bullshit.

My advice is that you should just do the same thing as some random poster on slashdot who says "these days I set up my swap like blah blah blah" without any explanation or justification.

You really should give credit where credit is due.

FreeBSD got the driver they use from OpenBSD.

OpenBSD folks have been campaigning against blobs, and specifically have been hounding the wireless folks to open up specs and documentation for a while now.

The FreeBSD folks... not so much.

Linux has had TCP window scaling for a long time. The recent "bugginess" with it came from a change to its default settings that caused issues with a non-compliant device on the Internet. Read about it at KernelTrap.

> And no, icc cannot reliably compile a runnable kernel.

Actually, people got icc to build the FreeBSD kernel back in 2003, albeit with some known issues back then which have since been resolved, from what I've heard on the mailing lists. See http://kerneltrap.org/node/974:

Compile FreeBSD with Intels C compiler (icc)

URL: http://www.leidinger.net/FreeBSD/

Contact: Alexander Leidinger [email blocked]

Since I ported icc to FreeBSD I wanted to build FreeBSD with icc. Now
with icc 7.1 (and some patches) it is possible. There are still some
bugs, e.g. NFS doesn't work with an icc compiled kernel, IP seems to
be fragile, and some advanced optimizations trigger an ICE (Intel is
working on it). At the moment I'm waiting for our admins to install
icc on the FreeBSD cluster (we got a commercial license from Intel, so
we are allowed to distribute binaries which are compiled with icc),
after that I will try to convince some people with more knowledge of
the IP and NFS parts of the kernel to debug the remaining problems.
When the icc compiled kernel seems to work mostly bugfree the userland
will get the porting focus. Interested people may try to do a build of
the ports tree with icc independently from the status of the porting
of the userland... if this happens at the FreeBSD cluster, we would
also be allowed to distribute the binaries.

Benefits include: another set of compiler errors (debugging help),
more portable source, and code which is better optimized for a P4 (gcc
has some drawbacks in this area)

Oops, sorry. Wrong link. I ment this one about OpenBSD's blob-free Intel PRO/Wireless 3945ABG Driver.

Now ask if it runs on OpenBSD. The guys who are fighting hard for open drivers from the wireless manufacturers.

There are many good resources on the web. The standard resource is The Linux Documentation Project, or http://www.tldp.org/. Another site, which is much better than it used to be, is http://www.linux.com/. http://www.linuxjournal.com/ has many great articles to guide you through a wide variety of small projects. A great newer site with helpful articles is http://www.howtoforge.com/. For help on the desktop side, http://www.desktoplinux.com/ has many articles you may find of use. Documentation and information about KDE is, of course, available at http://www.kde.org/ and it's affiliated sites (linked from their homepage). IBM is always putting up new articles at http://www-128.ibm.com/developerworks/linux/ that can provide usefull information for development work under Linux. You may also find the articles on http://www.debian.org/, http://www.gentoo.org/, and http://www.ubuntulinux.org/ usefull even though the articles were written for other distros.

If you can't find what you're looking for there, you can always head over to irc.freenode.net. The #suse and #opensuse channels will be of particular interest to you. You may find #kde helpful for KDE applications. ##linux is basically a catch-all channel; we'll generally be able to field just about any question you throw at us there. If we can't, we will point you in the right direction.

Keeping up with the FOSS news can also teach you quite a bit. You already know about Slashdot. http://osnews.com/ is another very nice resource. http://www.kerneltrap.org/ is a less frequently updated site which can provide you with more advanced information. Keeping an eye on http://www.freshmeat.net/ can help you get a better feel for the various software available for Linux. And of course, with gmail you can setup alerts for Linux, KDE, etc.

If you really want to learn more about Linux, there's no better way than distro hopping. Go to http://www.vmware.com/ and download their free VMWare Server 1.0 to allow you to try out various distros without having to wipe your hard drive. This does, however, require you have a decent amount of RAM (I'd recommend at least 1 GB). Go to http://www.distrowatch.com/ for a fairly complete list of the available Linux distros, sorted by popularity.

If all these links really don't solve your problems, take yourself over to your best local bookstore and buy a book or two. The drawback of doing this, however, is that most of them will be pretty much out of date by the time they hit the shelves. On the other hand, they will give you a great foundation upon which you can build (update yourself) easily by utilizing the online resources.

Also, never forget about http://www.google.com/linux!

Of course, that ignores the politics involved in gettings things into the kernel. Sigh. We'll do it all anyway, we just have to accept that it takes 2 years for the kernel folks to get used to something after they see it working.

... is starting to look a lot better every day.

Obviously though it is necessary to write new functions on occassion; for example when the new function is worse than the old function is under some circumstances.

That is exactly why it was done. More information about can be found at kerneltrap: here, and here. It was also previously on slashdot, although you would be best to skip that - it has more misinformation than the other kind.

In short, all the known ways of implementing zero-copy within the existing API's cause the most common usage cases of those API to be slower than they are now. Therefore, it made more sense to export this new API for the applications where speed is critical.

In the the first kernaltrap article, Linus also explains why splice is different from sendfile, contrary to the posts here claiming they are essentially the same.

Obviously though it is necessary to write new functions on occassion; for example when the new function is worse than the old function is under some circumstances.

That is exactly why it was done. More information about can be found at kerneltrap: here, and here. It was also previously on slashdot, although you would be best to skip that - it has more misinformation than the other kind.

In short, all the known ways of implementing zero-copy within the existing API's cause the most common usage cases of those API to be slower than they are now. Therefore, it made more sense to export this new API for the applications where speed is critical.

In the the first kernaltrap article, Linus also explains why splice is different from sendfile, contrary to the posts here claiming they are essentially the same.

Of course, OpenBSD is a much smaller market than the Linux market, which is probably part of why binary blobs just aren't availble for it at all -- the hardware developers just ignore OpenBSD entirely rather than throwing them a bone in the form of a binary blob.

No, it won't.

When Vista ships, everyone will be me, unless people go out and buy new computers specifically for Vista.

They will, or more appropriately they won't upgrade to Vista until they buy a new computer.

The majority of users don't buy all new hardware when a new OS comes out.

You are correct. The majority of users keep using the factory-installed OS until they buy a new computer regardless of new releases.

But... they are doing that. Vista is supposed to run with XP (and 2000) drivers.

Really? Then why is MS distributing this paper to XP driver writers about backward compatability issues? If you have evidence that MS has indicated that all XP drivers are supported then please enlighten me. Even if they have said so the cited paper (directed to driver developers) leaves some ambiguity.

You're a little... um... pessimistic about hardware providers.

Yes I am.

Most large providers do care about their customers...

Most large provider's customers are HP, Dell, Gateway, etc., not you and I.

It's the small vendors who typically don't.

If there's one person championing the openness of drivers it's Theo de Raadt, and he thinks otherwise.

"Richard Stallman thinks he's God in the open source movement?"

Richard Stallman does not think he's god in the open source movement. He belives the open source movement is misguided, and believes that people should not adopt open source licenses.

Typical of his views on the open source movement is
"The values they cite are the same ones Microsoft appeals to: narrowly practical values."
http://kerneltrap.org/node/4484

This actualy effects both the goalsmofr having a free operating system as well as having wide spread adoption. It isn't as easy as someone placing a non GPLed piece of software into the mix either.

First and probably foremost, It would apear that the confusion surounding the GPL and the constant misinterpretations could take your free software and close it real fast. Linus already touched on this a few years back It was my impresions that the whole Nvidia-ATI issue was settled then. Evedently, it has come back with just as much confusion as ever. Now how this effects Free software is tricky. Most of the developement on major OSS is sponcored by some for profit company. What will happen when all the money surrounding OSS is pulled because someone changes the interpretation of the GPL again and those companies feel they canno0t use the software to thier benefit. Sadly, this could be the case at some point in time or be enough of a threat to cause it to be an issue. It is just as bad as that time someone claimed you could retain a closed copyright on any documents produced using free fonts because the fonts gets embeded in the document and that automaticaly makes it GPLed.

Of course that issue turned out to be complete rubbish but, it might be enough cause that governments couldn't use them because of clasified information now being opensourced. Could you imagine the stict interpretations like this causing open document format to specdificaly not be GPL compatible because the idea behind it (in mass anyways) is that someone owns the content and doesn't want to be held hostage to some corperaqtion. And if open document was opensourced, the argument could be made that no one owns the content again?

Definatly clerifications need to be made. Little incedents like this shouldn't be poping up.

In 2003.

Beat that dead horse some more.

This is an issue that has been discussed before. See this Free Software Foundation FAQ and this Kernaltrap discussion, which includes Linus Torvalds' own statements. As I understand it, the rule is that if you combine GPL code with other code, you must release the result under the GPL. If the other code is proprietary, you can't release it under the GPL, with the result that you can't release the program at all. The issue is what is considered "combination". The crucial thing is that the combination must be such as to create a derivative work. Simply putting the two programs on the same CD does not create a derivative work. Creating a single binary, as when the kernel links to a library or driver, does create a derivative work. There is an exception for libraries that are a normal part of the system, but since the drivers in question are not normally distributed with the OS, I don't think that that exception applies.

The upshot is that the letter-writer appears to be correct. If you distribute a single binary in which the proprietary drivers are linked into the kernel, you are in violation of the GPL. You can work around this by including the drivers in the distribution as separate files and loading them dynamically.

The FSF is probably a good place to ask questions about how the GPL applies in cases like this.