Slashdot Mirror

1. I didn't live on campus last quarter; rather, I found out about the opensource group when they made headlines earlier this year. I then visited them at the activities fair.

2. I agree that no single-user development IDE I know of matches Microsoft's Visual Studio. It's great in that it looks up possible function parameters, but there are a number of things about it I find annoying as well (at least as of VS 6).

3. The opensource group is thinking about doing a project themselves, but where that is a good guess. Given that OSU is a big IP school, and the club is funded by OSU, it becomes a question as to who owns the resulting code.

4. NTsig also likely gets some OSU funding, and as you can guess, an awful lot from Microsoft (if NTsig is like some other school's, I wouldn't be surprised if certain NTsig members were paid, especially with a Columbus MS office). It's a bit of an apples and oranges comparison; one has minimal support funding, the other gets tons (although not as much as the religious groups; at least one goes through over a million dollars per year!).

Any development MS software or the Xbox costs more if it was not donated than what the opensource group gets funded to do in a year. With nearly weekly meetings, we have to ration when we get pizza, etc., and when we don't.

5. I can tell you a group opensource software install day is planned for Saturday, January 18th. That is, unless someone changed it behind my back :)

6. Yes, the campus email system can seem funky. Sometimes, mail clears quickly, but sometimes it does not.

As a grad student (with quota on the ECE mail system), I have the OSU EE mail server forward to the ECE department's one so I can use IMAP and access it in various places. This past weekend, several of us noticed we didn't get any messages since Friday. I sent myself an email directly to the main OSU mail system Sunday morning, and didn't get it for over 24 hours (although the timestamps suggested otherwise). Why this happened is anyone's question.

As for things like DirectX and user interface, I'll let others argue about whether SDL/OpenGL is a good DirectX equivalent, or whether KDE 3 and GNOME 2 are better than the Windows XP interface. It really depends on exactly how you use your system. For my needs, Linux is far better, but I'm sure you can come up with areas where it's lacking.

The "rant" was the result of me being extremely pissed. And I believe justifiably so. There was something in the kernel that Andre considered a "defect." He had a simple piece of code to fix it. The kernel people rejected this, because "in theory, someone can get around this, so there's no point plugging a hole which someone can reopen."

In theory? This was like setting a policy that if you sell a gun to an ex-con, it must be sold with the safety catch set. Sure, criminals can "in theory" turn off the safety themselves, but hey, it's better than nothing, right? At least "by default" they can't go out and start shooting people, right?

...Wait. Did you just call Andre's taskfile patch "simple"? Maybe you're one of those people who consider ACPI parsing "simple" too? Have you even read the patch, or was this just hearsay?

For those of you who weren't following along back then, Andre wanted to provide an ioctl-based way to run vendor-specific, often undocumented hard disk commands. This would be things like "make disk read-only" or "unlock extra 10 GB of space the firmware rounded down so they could sell those excess 40GB drives as 30GB" or such. Being vendor-specific and often undocumented commands, the applications that used them might be buggy and, if buggy enough, might be able to turn a hard disk into a paperweight.

The taskfile patch was intended to provide sanity checking in the kernel to guard against buggy applications. Of course, Andre being Andre, he didn't put it that way. By the time he was done yelling, it sounded as though EVIL HACKERS WILL DESTROY YOUR HARD DISKS IN THE BLINK OF AN EYE AND IT'LL BE ALL LINUX'S FAULT. Never mind that the EVIL HACKER already needs to crack root before he gets the necessary raw hard disk access. Never mind that the taskfile patch would not prevent the EVIL HACKER from bypassing the ioctl interface and bit-banging the ATA chip directly. Never mind that, as root, there are a lot of horrible things an EVIL HACKER could do to your system, much more insidious and EVIL than crashing a hard drive, like installing backdoors and making your system fail in subtle ways that you wouldn't notice for a month. Never mind that those same EVIL HACKERS have been able to destroy these same hard disks in any version of Linux or Windows since the beginning of time (well, the beginning of ATA hard disks with these command sets) and yet somehow, remarkably, we haven't yet heard of it being done.

And never mind the whole problem that if a buggy application can destroy your disk, so can a buggy taskfile patch. (Andre tends to exude an abnormally high level of confidence in the quality of his implementations.)

In short, at the risk of sounding like I know what I'm talking about, which I don't really, it was a stupid idea. At least as initially presented on the mailing list. Some time later, the startling revelation came out that the taskfile patch actually had some other uses besides the one listed above (protecting against EVIL HACKERS DESTROYING YOUR HARD DISKS AS YOU SLEEP). And then, marvel of marvels, Linus was suddenly a lot more sympathetic to the patch.

I made some remark about how it would boost user morale if the patch were in place, regardless of any real technical merit. I made some statement to the effect of, "You guys should care more about what the users want, even if you think you know better than them."

And that, at the risk of sounding like one of your alleged arrogant pricks on linux-kernel, is idiotic too. Hard to explain what's so utterly wrong with your statement - I guess it's just one of those things - if you have to ask, you'll never know. (Now how's that for elitist?...)

What is Bell's Inequality?...



Cheer and seasons greetings!
oo__ don@saklad.org

Weblog Guide to Problematical Library Use
Updates
http://GuideToProblematicalLibraryUse.WebLogs.com
http://zork.net/~dsaklad
Stories
http://GuideToProblematicalLibraryUse.WebLogs.com/ stories
Forum
http://www.quicktopic.com/18/H/LvNZqHdLNB8

I got your Mouse-O-Matic(TM) right here.

To all of those worried about LVM: 2.6 will include a LVM implementation. The EVMS won't make it though.

The story is that 2.4 included LVM1 (I am running it right now on my RH8 box) which had some restrictions and were generally regarded as a kludge. For the 2.6 kernel two competing replacements arised: LVM2 and EVMS. LVM2 is basicly a rewrite of LVM1 while EVMS is an entirely different beast aimed at the BIG IRON in the datacenters. After some (heated) discussion on LKML Linus decided to include LVM2 and scrap EVMS.

The reaction from the EVMS team (sponsered by IBM) was noble: They decided to remove their kernel-land code and rewrite their user-land utilities to use the winning LVM2 kernel interface and create a win-win situation for everyone. Kernel traffic covered the story here and Linux Weekly News made a mention of it here.

I suggest keeping tabs on LWN's weekly kernel page for good explanations of what's going on...you can also read Kernel Traffic, which, although it is usually fairly technical, tends to give you the gist of what is going on in the world of the kernel devs. Good luck-

Sigh, I'll do your web searching for you.

Basically, while Linus was incommunicado sailing across the ocean, someone got jumpy and suggested 3.0 should be the next step.

It might be more likely that it proceeds through 2.10 and higher before going to 3, though. Just to confuse the people who think version numbers are floating-point.

Kernel Traffic is an excellent site that puts out 'issues' summarizing the major topics on linux-kernel. It's quite handy. There are also a few 'Kernel Cousins' covering other projects, including Wine.

I see no real reason to call it 3.0.

The order-of-magnitude threading improvements might just come closest to being a "new thing", but yeah, I still consider it 2.6.x. We don't have new architectures or other really fundamental stuff. In many ways the jump from 2.2 -> 2.4 was bigger than the 2.4 -> 2.6 thing will be, I suspect.

But hey, it's just a number. I don't feel that strongly either way. I think version number inflation (can anybody say "distribution makers"?) is a bit silly, and the way the kernel numbering works there is no reason to bump the major number for regular releases.

Nope. In this lkml thread, Linus says:

We've never had that as any criteria for major numbers in the kernel. Binary compatibility has _never_ been broken as a release policy, only as a "that code is old, and we've given people 5 years to migrate to the new system calls, the old ones are TOAST".

The only policy for major numbers has always been "major capability changes". 1.0 was "networking is stable and generally usable" (by the standards of that time), while 2.0 was "SMP and true multi-architecture support". My planned point for 3.0 was NuMA support, but while we actually have some of that, the hardware just isn't relevant enough to matter.

I *sooooo* hope the Hans gets off his butt and gets ReiserFS 4 in this one. If you follow the LKML closely (or just read the Kernel Traffic, http://kt.zork.net/kernel-traffic/latest.html) then you may have heard he's sweating a bit on getting it in.

Reiser4 may just revolutionize the way the some people do stuff. I mean, next system I want to be able to do:

# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
jim: x:100:100:jim:/home/jim:/bin/bash
# cat /etc/passwd/jim/uid
100
# echo /bin/ksh > /etc/passwd/jim/shell
# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
jim: x:100:100:jim:/home/jim:/bin/ksh

All that *and* have transactional data commits with a very small performance hit!

(ReiserFS Trolls: Go ahead, bring it on!)

Our Boston Public Library departments censor their very own documents like curatorial reports and consultants' studies reporting on collections for the purpose of long range development. BPLers have been for the most part adamant in violating the spirit of state FOI freedom of information and sunshine open meeting principles of intellectual freedom. BPL President Bernie Margolis delegated Assistant Director Ruth Kowal to provide accessibility but instead of removing red tape hurtles, additional punishing fees are extorted.

Our cities' public libraries should involve greater public participation in long range planning beginning with ensuring access to whatever legitimately public documentation there is on the very same institution.

See also
Weblog guide to problematical Boston Public Library use
Updates
http://zork.net/~dsaklad
Contents
http://GuideToProblematicalLibraryUse.WebLogs.com/ stories

Guide to problematical Boston Public Library use
Contents
href="http://GuideToProblematicalLibraryUse.WebLog s.com/stories
Updates
http://zork.net/~dsaklad

Something should be done about the violation of professional conduct by Boston Public Library President Bernie Margolis and his delegated officers of our public library including BPL Government Documents Department Reference Desk Curator Librarian Gail Fithian. Don Saklad dsaklad@zurich.ai.mit.edu Weblog guide to problematical Boston Public Library use http://zork.net/~dsaklad

This is the 139th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

• OS Sucks-Rules-O-Meter
• Editors Sucks-Rules-o-Meter
• Vegetarion Sucks-Rules-O-Meter
• What [Programming] Languages Rule (alternative)
• Linux Distribution Comparison

As I understand it, Linus does not like to refer to GNU when talking about Linux because he does not share the belief of RMS and the FSF that software does have to/should be "ethically correct"-

Quoting:
Besides, as the whole notion of "free software" has very little to do with the kernel, please just link to some open source site. One of the more neutral ones is "http://www.debian.org/social_contract.html", for example."

There was no real need to change the IDE code, but some people felt it was a mess and needed to be cleaned up. Unfortunately, it broke badly in the process, so the 2.4 IDE was ported to 2.5, putting things back pretty much as they were. Kernel Traffic is a good source of information about all this stuff. Of course, this is a vast oversimplification, and some of the activity was due to your standard mailing list flame war.

Don't give me the old "competition" argument either. There is only one Linux kernel, which seems to progress just fine without another competing project nipping at its feet and instigating flamewars.

You missed the VM system flamewars? The scheduler fights? The CML2 flamewars starring ESR? The kernel developers are by no means an egoless hive-mind, noiselessly producing good code. Read kernel-traffic for a little taste, or delve into the linux-kernel list raw & unfiltered for more than you evidently expect in the way of competition.

If you want to look for "Not Invented Here" mentalities and competition between kernel projects in the free-software world, consider also Linux vs. BSD. As I understand it, there's no reason that OpenBSD's pf firewall module -- which has some serious advantages over Linux's netfilter -- could not be integrated with the Linux network stack. It hasn't been, though, and I don't imagine it will be.

Kernels can be fighty places, too.

There is some very primative discussion of it here .

A futex is a mutual-exclusion primitive that's based around file and file operations rather than some heavier mechanism. The idea is that the kernel doesn't keep track of all the folks locking the file and so on, with all the extra separate bookkeeping to handle when processes exit and so on. Futexes live mostly in user-space, making them very fast.

I don't pretend to know a fraction of the details--only that I've heard of them before and what their benefits are, roughly. Read more here.

Talking of vi and patches...

No one's as manly as Al Viro

I'm the editor of Linux Journal and vice-president of the Silicon Valley Linux Users Group.

# Why should we burn all GIFs?

The Internet is a good thing because you don't need the permission of any one entity to publish. If you choose a patented format, you are throwing away the advantage of publishing on the Internet in the first place.

Many commonly used image editing programs come with a GIF license. However, GIF licenses on shrink-wrap software do not apply to GIFs that you may generate on the fly -- every site that does a dynamic map or chart in GIF format has to get a separate license.

# How do you burn something that is not tangible?

You print it out, and if you're holding your event in a place that prohibits public fires, you draw flames on it with a marker. It's not the burning that's important, it's freeing yourself from needing a license to publish.

# Greplaw still uses GIFs. What should we do instead?

Use PNG or JPEG images, depending on which gives you the best quality and image size. Almost all browsers in use today support both.

# Software patentability is entering Europe and European strong author's rights are entering the US. Why is this is a problem?

I'm not familiar with the strong author's rights issue.

Software patents are a big problem, though.

Best to start from first principles, since people argue the same issue from different points of view and never get anywhere. I'm going to be US-centric and look at our Constitution, which I think soundly expresses the point of view that patents are not a property right or a natural right.

Copyrights and patents appear in the Constitution in Article 1, Section 8, along with other miscellaneous economic powers of Congress. They're right next to "Post offices and post roads".

If patents are not a natural right or a property right, what are they? As you might guess by the post office and road connection, they're a government program to promote economic growth. Patents are intended to do two things: promote R&D investment by the private sector; and encourage the private sector to publish inventions. The Constitution makes this explicit in its stated reason for copyrights and patents: "to promote the progress of science and useful arts."

Patents reward these two economically desirable behaviors (doing research and publishing) with a temporary government-granted monopoly on a particular invention. Congress has full discretion on what kinds of content can get a patent and on how long a patent can last. (If patents were a "right" the Constitution would require them -- as it is, the Constitution only allows them.)

So, how should Congress decide which kinds of content get a patent and which don't? You have to strike a balance between, on one hand, the economic benefit of any R&D motivated by the prospect of a patent that would not have happened otherwise, and on the other hand, the transaction costs that are an inevitable result of the patent's existence.

You have to draw the line of what gets a patent and what doesn't somewhere. If you allow the patenting of rhyming words, sports plays, or musical notes, day-to-day life becomes an impossible mess of patent cross-licensing. And, as for these areas, there is no economic evidence that software patents help the economy or even encourage R&D. They may do the opposite -- see the Bessen and Maskin paper (PDF-format).

Software is a good thing because in software, a small investment can create and manage great complexity. When you impose the same transaction costs on software as on hardware, much useful software that could otherwise have been created does not exist. We are seeing this today in the field of video compression. The MPEG patent licensing mess is excluding everyone except for large, well-funded corporations from creating innovative new video-related software.

There may be increased R&D investment in a few areas, such as video compression, due to the prospect of a lucrative patent, but this economic gain is swamped by the loss of productive software later.

As a software patent opponent, I argue simply that patentability creep should be rolled back. The patent office should again exclude algorithms and business methods, as it already excludes ordinary mathematical theorems and their proofs. Forming a "GPL patent pool" might help to cut some of the transaction costs where GPL-covered software is concerned but cannot hope to ameliorate patents' harm to developers who use other licenses.

# Why should a lawyer be interested in Linux?

Why should a lawyer be interested in Cat 5 cable, or ATX power supplies, or USB keyboards? Linux is a generic, commodity item that does what you want it to do, as part of a larger system that you control.

# How will free software change society?

Free software won't so much change society as it will bring the computer business more in line with the rest of the economy. If you went shopping for any non-computer product, and got offered an End User License Agreement like those offered in the computer business, you'd laugh and walk out. Free software gives the customer the same rights of inspection and control that he or she has when buying non-computer products such as furniture (you can cut a hole for your cables in your desk) or cars (you can change your own oil.)

If you want to read a novel where software-like licensing is applied to a regular product with ludicrous results, read "Secrets of the Wholly Grill: A Novel about Cravings, Barbecue, and Software" by Lawrence G Townsend.

# Many countries consider public procurement policies where free software should be encouraged or even mandated. What is your take on a "Peru law"?

Governments have a responsibility to their citizens not to enter into unfair contracts. Most or all proprietary software licenses are unfair contracts, and subject the customer to lock-in and limit the customer's ability to fix problems.

Microsoft's lobbying against fair software purchase laws has been weak. They don't even put an End User License Agreement on their web site. If even the people who wrote it are ashamed of it, why should anyone else be willing to accept it?

# After September 11, 2001 you wrote an open letter to Michael Eisner, head of Disney, urging him not to go to Washington, D.C. to lobby for the SSSCA. Why did you do that?

I am on a mailing list based on a Linux server across the street from the World Trade Center. On September 11th, the traffic was about who's where, is everyone all right, which hospitals are open for blood donations, is a particular subway station open, what's going on. Stuff you can't get from TV. We can't let the media corporations seize control of hardware, lock out free software, and turn the net into a one-way medium like TV. Unless printing and postage get real cheap real fast, free speech in the USA needs the net.

# If major companies like IBM and Sun discontinue their support of free software, what will the effects be on the current movement?

Remember the question, "If the Linux startups fail, what will happen to free software?" There's enough customer pull that if customers can't get free software products and services from IBM and Sun, they'll get it someplace else.

# Declan McCullagh of News.com has stated: 'Trust me, a few--even a few thousand--peeved e-mail messages won't change vote totals that lopsided', hence geeks should focus on code, not on government. Do you agree?

Email spam was a "geek" issue until recently, and now, as it affects more and more people, the organizations that begain calling politicians' attention to it are involved in the mainstream political process. If you learn and understand the political process now, and begin making contacts, you will better be able to use the support you get as the anti-Net crackdown affects more and more people.

Declan is half-right in that focusing on code is good too. By all means, develop something that's questionable DMCA-wise but that everybody wants to use. You will motivate more people to be interested in DMCA reform.

# Finally - what is Pigdog and why?

Pigdog.org is the leading Internet news and content site. I am not an employee, just a satisfied reader.

Don Marti was interviewed by Mikael Pawlo.

Status of Tux2?

" given that WINE is a virtual machine, according to its circular acronym ("WINE Is Not an Emulator")"

The maintainer of WINE refers to it as an emulator.

It is indeed an emulator. Even the kernel cousin for it refers to it as an emulator.

If you do not agree to the terms of this EULA, PC Manufacturer and Microsoft are unwilling to license the SOFTWARE PRODUCT to you. In such event, you may not use or copy the SOFTWARE PRODUCT, and you should promptly contact PC Manufacturer for instructions on return of the unused products(s) for a refund.

The reason stack protection stuff isn't being widely used isn't because it's got an obscure name or something simple like that. It's because not everyone can agree whether it's effective or just lures people into a false sense of security. There have been a couple of "discussions" of this on the Linux Kernel Mailing List and the end result is always a stalemate.

dan

http://kt.zork.net/kernel-traffic/

They are out of money for professional writers. However, why not continue in another form?

LWN was run voluntarily at first. Can it continue in this fashion? I mean, I like reading the excellent editorials, but I can also live with fewer of them. Say, the amount one person would willingly write in their spare time and contribute to the community.

Paying jobs are nice to have, I know. But LWN could continue as a hobby, like Kernel Traffic exists today. As long as you have hosting which provides bandwidth and the archives, everything can continue.

If all else fails, at least let other people mirror your archives. This way the great work LWN has contributed to the community will not go away. I only wish my financial situation were better, so I could give back some money to make up for all the times I've read LWN since 1998 (I've been reading every weeklf edition since 1999) until present and found the content to be useful.

Kernel Traffic
KernelTrap

Linus used to refuse the non-executable stack patch. Scattered discussions make it seem he's opening to it. I see his point that it doesn't prevent all smashes, but it makes it harder. You might as well take what you can get.

Solaris has had this ability since 2.6, but you an bypass this. I'm not so sure you could do this with a remote exploit tho, it seems you may need soem code running locally, so it would help agaisnt remote exploits, but not local.

People

Richard Stallman -
Eric S. Raymond -
Larry Wall

Linux Programming

Unix

Programming Methodologies

C Programming

C++ Programming

Perl Programming

Network Programming

Open Source

Debian 3.0 Woody comes with KDE 2 and XFree86 4.1 while 3 and 4.2 are out respectively.

Big deal. Pretty soon, both the XFree86 and the KDE 3 situations will be rectified. So we've had to wait a bit longer. It's well worth it in my opinion since Debian makes installation and upgrade of all this software incredibly easy compared to ANY other operating system. If you want to go out and use something inferior, that's your own business. Eventually Debian gets current and once it leaps these major release hurdles, they stay current.

This is a bit sad, seeing that even CygWin and FreeBSD have more up-to-date versions in their releases. Just think of how much effort it took Cygwin to port the packages to Windows before packaging them, for example -- yet despite this their releases are far more timely.

The *BSD ports system is basically a nice way of organizing sources for programs. Very little effort is needed to add something to the system (this includes figuring out deps). So, it's not that big of a deal to see Debian lag behind BSD. Try again.

As for Cygwin, I'm trying to imagine how hard it is. Well, it just isn't. In the past few days, I've installed a lot of programs from source on Cygwin at work. None of them ever complained about not being in a real "unix" environment. Your statement clearly indicates that you've missed the whole point of Cygwin. Cygwin is designed such that it is not supposed to be hard to make packages of "unix" software for it. Duh.

The Debian packagers claim that there is a lot of intricacy involved in the packaging, and i'm sure there is, but I don't buy that people should have to use older software with known bugs, several months after the upstream authors have released their software.

Yes, it is infact intricate. Debian supports 11 platforms. Some are little endian, other big. Some are CISC, others MIPS. Some software (serpent cipher for example) only work on machines with certain endianness. As a result, this makes a dependency nightmare for the package maintainers. I'd like to see anyone else take on the job the Debian people have assumed and do 10% the quality of work.

As for using older software... well, fine, don't buy it then. It's well known in the IT world that you stick with the tried and true until the bleeding edge stops bleeding. A lot of shops know better than to jump right onto the latest version bandwagon because doing so destroys a potential resource of great value: watching other people fail in doing so. Knowing what your problems are when using software is better than using software and not knowing what problems you'll have. Again, duh.

I've been using XFS for all my systems since the beggining of this year and I've personally had zero problems with XFS. I have heard some complaints from other people but when I asked them what they didn't like the complaint was that there were null bytes in files after a crash. Unfortunatly for them this is the intended behavior by XFS in some situations.

I think the most common kernel with XFS is 2.4.18 which is known to have some swapping problems.

So as long as the RedHat 7.3 kernel doesn't have that swapping problem I'd say go for it. Be sure to install the xfsdump package if it isn't already and run the xfs_fsr command weekly from a cron job to keep performance high.

It's quite common nowadays; which is rather unfortunate, given the poor state of Linux APCI support.

And regarding ACPI superiority - APCI is more powerful, but it's also more complicated. It's not just for power management but for general device configuration and initilization as well. Additionally, it includes its own interpreted language, AML, which lets companies write their own custom routines. As you can imagine, having to implement the AML interpreter is a somewhat large task and may be a potential secure risk. There's an overview about this at Kernel Traffic from awhile ago

APM is about standard power-saving commands, whereas ACPI lets the manufacture program

I believe Alan Cox, for one, is opposed to it in its current form. See here and here.

Go to kt.zork.net and follow the updates on building a Hurd version of Debian... I believe there's been stuff on there about ISOs.

One of bitkeeper's nice features is to keep track of a set of patches (You can apply or undo a group of patches)
If you want to know more about it Jeff Garzik posted a BK kernel hacking HOWTO

Without Linus's kernel, the "Gnu system" would be completely irrelevant today.

That simply isn't true. Indeed, your next sentence admits as much

The BSDs would still have gotten out of the legal wrangling with AT&T before the HURD was done, and FreeBSD would have taken the mindshare that Linux got.

Which would have been fine. The reason I ended up using GNU/Linux instead of BSD was because of that legal wrangling ... at the time, FreeBSD was the first free operating system I found, and while there were a lot of GNU tools in use on Sun and other BSD systems, Linux was relatively unknown. The legal issues forced myself and others to look further, and Linus' kernel was the only other offering at the time.

However, had BSD won the mindshare the GNU/Linux has, it wouldn't have hurt the FSF at all. As others have noted, much of the GNU stuff is being used in the BSD world today because it is good software. Contrary to popular myth, BSD and the FSF/GPL are not all that adversarial. Their disagreement is more one of strategy not philosophy. Indeed, the FSF specifically endorsed using the BSD license with the ogg-vorbis stuff, specifically because it was a more strategic license for getting the standard more widely adopted in embedded systems.

And, unlike Linus' recent comments on the LKML saying in effect "take any references to the FSF out of the FAQ, none of our documentation should point people to the FSF at all", the BSD folks seem happy to coexist with the FSF and even mention them on occasion, despite having no affiliation. In other words, the FSF would be just as big a player had BSD won the majority of the mindshare as it is with Linux having won it, only to have some of its leadership actively trying to steer people away from the FSF and the message they are trying to convey.

I must admit I lost most of my respect for Linus when he made that comment. He claims not to want to be political, but then he takes very political stances on questions like that, actively steering people away from the one organization to which he owes his fame and much of his career. Being anti-FSF is as political a stance to take as being pro-FSF, and deliberately trying to silence the voice of those who have contributed 90% of what makes Linux a UNIX-like operating system is not only profoundly political, it is indefensibly political against the very people to whome the community owes so much.

It is ironic that, as someone who has been using GNU/Linux since the 0.48x days (and who was as unfuriated as the rest with RMS's lignux nonsense) that I have come full circle to understand and respect RMS's point of view, and that now the behavior of Linus and some others, whome I've held in high regard for over a decade, is such that they have become in some respects as offensive to me as RMS once was.

I will continue to use the operating system, and to contribute in my way, because I believe in free software and have profited greatly from it, but while I am quite critical of RMS, I am utterly disillusioned with Linus' rather hypocritical stances on these issues and the profoundly arrogant ingratitude he seems to be displaying of late.

I don't read the kernel mailing list. Could someone who does tell us what we have to look forward to in the 2.4 line?

hmm, neither do I, but I occasionally drop by at Kernel Traffic.
From there, I got to this patch which seems to bring some of the future features to the power-using, look-what-my-kernel-does, plus-three-frames-in-quake3 crowd.
Enjoy, I had no problems with that, although I don't leave my PC on overnight, so I can't come up with any uptime numbers.

After reading some of the other posts in this article, I noticed someone mentioned Kernel Traffic. A quick Google search turned up:

kt.zork.net

And following some links from there got me to:

marc.theaimsgroup.com/?l=linux-ultrasparc&r=1&w=2

This should keep my occupied for a while, but are there any other sites that anyone can recommend?

However, changing the license in this way was at least impolite. Possibly there were discussions that I didn't notice, but if so, then nobody's brought them up since. I think it likely that any discussions were basically "private". So neither side had justified their position to the public, except via PR releases.

There certainly was discussion on changing the Wine license - and lots of it - on the wine development lists - and the topic appeared in KC Wine as far back as December of 1999.

That's not to say the change was right or wrong, just that it was discussed and held for open vote among the Wine developers.

It's also interesting to note that in his initial (lengthy) message on the subject, Gavriel from Transgaming had this to say on the LGPL:

Using the LGPL may limit the abilities of those who need to work on code that cannot legally have source revealed.

One of the other non-DirectX things that we have spent significant amount of effort on is copy protection. We have extended Wine to support both SafeDisc and SecuRom protected programs. For the moment, our work on this code is not even in our AFPLed tree. Until we have a chance to make a legal determination on whether or not releasing the source code would violate the US DCMA, we have little choice but to keep it secret.

If Wine was LGPLed, we might not have the option to distribute this code at all, which would thus severly limit the utility of our entire endeavour. It's not hard to imagine other commercial efforts where similar issues might occur.

With all that, speaking on behalf of CodeWeavers, I would neither call for nor oppose a switch to the LGPL. Since that change would impact me and my customers somewhat slowly, I think I could make the necessary adjustments in time. The most important thing is for us to continue to have a vital and thriving Wine community. Finally, speaking strictly on a personal basis, and with no corporate considerations whatsoever, I would welcome a change to the LGPL; I have always preferred it to BSD style licenses (and to the GPL, for that matter); with LGPL projects, I feel more certain that I know exactly where I stand and how my code will be used.

Not that facts have ever changed the course of a /. debate, but I figured I'd throw some onto the table...

In the interest of full disclosure, I've got licences for both Codeweavers Crossover products (plugin and office) and am a Transgaming subscriber - I'm supporting both companies - but, more importantly, I'm hoping eventually to replace the three (!) different wine installations on my machine with a single install - something that won't be possible 'till all the children in this particular playground start to get along.

However, changing the license in this way was at least impolite. Possibly there were discussions that I didn't notice, but if so, then nobody's brought them up since. I think it likely that any discussions were basically "private". So neither side had justified their position to the public, except via PR releases.

There certainly was discussion on changing the Wine license - and lots of it - on the wine development lists - and the topic appeared in KC Wine as far back as December of 1999.

That's not to say the change was right or wrong, just that it was discussed and held for open vote among the Wine developers.

It's also interesting to note that in his initial (lengthy) message on the subject, Gavriel from Transgaming had this to say on the LGPL:

Using the LGPL may limit the abilities of those who need to work on code that cannot legally have source revealed.

One of the other non-DirectX things that we have spent significant amount of effort on is copy protection. We have extended Wine to support both SafeDisc and SecuRom protected programs. For the moment, our work on this code is not even in our AFPLed tree. Until we have a chance to make a legal determination on whether or not releasing the source code would violate the US DCMA, we have little choice but to keep it secret.

If Wine was LGPLed, we might not have the option to distribute this code at all, which would thus severly limit the utility of our entire endeavour. It's not hard to imagine other commercial efforts where similar issues might occur.

With all that, speaking on behalf of CodeWeavers, I would neither call for nor oppose a switch to the LGPL. Since that change would impact me and my customers somewhat slowly, I think I could make the necessary adjustments in time. The most important thing is for us to continue to have a vital and thriving Wine community. Finally, speaking strictly on a personal basis, and with no corporate considerations whatsoever, I would welcome a change to the LGPL; I have always preferred it to BSD style licenses (and to the GPL, for that matter); with LGPL projects, I feel more certain that I know exactly where I stand and how my code will be used.

Not that facts have ever changed the course of a /. debate, but I figured I'd throw some onto the table...

In the interest of full disclosure, I've got licences for both Codeweavers Crossover products (plugin and office) and am a Transgaming subscriber - I'm supporting both companies - but, more importantly, I'm hoping eventually to replace the three (!) different wine installations on my machine with a single install - something that won't be possible 'till all the children in this particular playground start to get along.

However, changing the license in this way was at least impolite. Possibly there were discussions that I didn't notice, but if so, then nobody's brought them up since. I think it likely that any discussions were basically "private". So neither side had justified their position to the public, except via PR releases.

There certainly was discussion on changing the Wine license - and lots of it - on the wine development lists - and the topic appeared in KC Wine as far back as December of 1999.

That's not to say the change was right or wrong, just that it was discussed and held for open vote among the Wine developers.

It's also interesting to note that in his initial (lengthy) message on the subject, Gavriel from Transgaming had this to say on the LGPL:

Using the LGPL may limit the abilities of those who need to work on code that cannot legally have source revealed.

One of the other non-DirectX things that we have spent significant amount of effort on is copy protection. We have extended Wine to support both SafeDisc and SecuRom protected programs. For the moment, our work on this code is not even in our AFPLed tree. Until we have a chance to make a legal determination on whether or not releasing the source code would violate the US DCMA, we have little choice but to keep it secret.

If Wine was LGPLed, we might not have the option to distribute this code at all, which would thus severly limit the utility of our entire endeavour. It's not hard to imagine other commercial efforts where similar issues might occur.

With all that, speaking on behalf of CodeWeavers, I would neither call for nor oppose a switch to the LGPL. Since that change would impact me and my customers somewhat slowly, I think I could make the necessary adjustments in time. The most important thing is for us to continue to have a vital and thriving Wine community. Finally, speaking strictly on a personal basis, and with no corporate considerations whatsoever, I would welcome a change to the LGPL; I have always preferred it to BSD style licenses (and to the GPL, for that matter); with LGPL projects, I feel more certain that I know exactly where I stand and how my code will be used.

Not that facts have ever changed the course of a /. debate, but I figured I'd throw some onto the table...

In the interest of full disclosure, I've got licences for both Codeweavers Crossover products (plugin and office) and am a Transgaming subscriber - I'm supporting both companies - but, more importantly, I'm hoping eventually to replace the three (!) different wine installations on my machine with a single install - something that won't be possible 'till all the children in this particular playground start to get along.

However, changing the license in this way was at least impolite. Possibly there were discussions that I didn't notice, but if so, then nobody's brought them up since. I think it likely that any discussions were basically "private". So neither side had justified their position to the public, except via PR releases.

There certainly was discussion on changing the Wine license - and lots of it - on the wine development lists - and the topic appeared in KC Wine as far back as December of 1999.

That's not to say the change was right or wrong, just that it was discussed and held for open vote among the Wine developers.

It's also interesting to note that in his initial (lengthy) message on the subject, Gavriel from Transgaming had this to say on the LGPL:

Using the LGPL may limit the abilities of those who need to work on code that cannot legally have source revealed.

One of the other non-DirectX things that we have spent significant amount of effort on is copy protection. We have extended Wine to support both SafeDisc and SecuRom protected programs. For the moment, our work on this code is not even in our AFPLed tree. Until we have a chance to make a legal determination on whether or not releasing the source code would violate the US DCMA, we have little choice but to keep it secret.

If Wine was LGPLed, we might not have the option to distribute this code at all, which would thus severly limit the utility of our entire endeavour. It's not hard to imagine other commercial efforts where similar issues might occur.

With all that, speaking on behalf of CodeWeavers, I would neither call for nor oppose a switch to the LGPL. Since that change would impact me and my customers somewhat slowly, I think I could make the necessary adjustments in time. The most important thing is for us to continue to have a vital and thriving Wine community. Finally, speaking strictly on a personal basis, and with no corporate considerations whatsoever, I would welcome a change to the LGPL; I have always preferred it to BSD style licenses (and to the GPL, for that matter); with LGPL projects, I feel more certain that I know exactly where I stand and how my code will be used.

Not that facts have ever changed the course of a /. debate, but I figured I'd throw some onto the table...

In the interest of full disclosure, I've got licences for both Codeweavers Crossover products (plugin and office) and am a Transgaming subscriber - I'm supporting both companies - but, more importantly, I'm hoping eventually to replace the three (!) different wine installations on my machine with a single install - something that won't be possible 'till all the children in this particular playground start to get along.

You refer to Linus' recent remarks on the kernel dev mailing list. These comments were made in the context of a discussion about whether or not the kernel HOWTO should quote the FSF.

Here are some more Linus quotes, all from http://www.webreview.com/1998/04_10/developers/04_ 10_98_4.shtml:

--

Making Linux GPL'd was definitely the best thing I ever did.

--

I'm generally a very pragmatic person: that which works, works. When it comes to software, I much prefer free software, because I have very seldom seen a program that has worked well enough for my needs, and having sources available can be a life-saver.

So in that sense I am an avid promoter of free software, and GPL'd stuff in particular (because once it's GPL'd I know it's going to stay free, so I don't have to worry about future releases).

However, that doesn't mean that I'm opposed to commercial software. Commercial software development has some advantages too -- the money-making aspects introduces some new incentives that aren't there for most free software. And those incentives often make for a more polished product.

--

The impression I get from all of this is that Linus prefers the GPL for pragmatic reasons, not ideological reasons. I can't speak for Linus, but I don't get the impression that he has an axe to grind w.r. RMS. RMS created the GPL, for ideological reasons. Linus uses the GPL for practical reasons. It's a win-win: good for RMS and good for Linus.

So I basically agree with the sentiments of the original poster here, but I would take exception with this statement:

There is very little need for evangelism

You may know RMS's story, but others still don't. I think it's fine that Linus doesn't want to walk this road. But that doesn't obviate the need for idealists. You don't have to agree with them. You don't even have to listen. But some people do listen - like Linus many years ago. And we are better off because of it.

RMS used to be a coder. Now he is largely a politician. There's a place for code. There is also a place for politics.

Who afraid of big bad RMS? Who's afraid of people who want other people to be silent?

Based on this lkml thread it sounds like you are against binary only kernel modules (e.g. the National Instruments GPIB driver). What is your stance on the legality, morality, and practicality of binary only kernel modules? Specifically, is a binary only kernel module a violation of the GPL or DMCA, and if so, why? Isn't a binary kernel module driver better than no driver at all?

Access: Postgresql or mysql should more than meet your needs. There are nice GUI tools available for both.

Your ideas of adding metadatas to file, accessed by reading the file like a directory, has already been discussed on the Linux kernel mailing list; I found this summary in kernel traffic, but I don't know if it ever evolved since then.

The thread also discusses the compatibility with existing apps.