Re:slashdot and cutting edge is about sourcecode!
on
Mozilla M12 Released
·
· Score: 1
No. The announcement can't wait until there are binaries. *ANYONE* can generate binaries from the source.
Why wait for binaries to make an announcement?
What platforms do you think we should wait until binaries exist for before something is announced? If there's no unixware binary or no intel solaris binary or no sparc linux binary, should we wait?
Why wait for a webmaster to update a website when the files are on ftp?
I'm suggesting not posting an announce of "Mozilla M12 Released" when the release isn't finished yet. While the source code is up, the full release includes binaries for several platforms. Finding bugs in this source release wouldn't help M12 binaries much if this is the final cut.
Believe it or not, there are many people who would rather download the binaries because they don't have the time to build and debug it themselves, but they still want to be involved and report bugs if they find any.
When an announcement comes from Mozilla.org that the release is ready, then the announcement should be posted. Posting it earlier only drives load to the FTP servers by people hoping the binaries will appear any second. (Note that ftp.mozilla.org is hovering around its maximum number of users now.)
Methinks it would help if large Open Source projects would send "press releases" to Slashdot and Freshmeat when ready, and if editors could refrain from posting premature announcements...
The important thing right now is to get as many developers as possible building the source. If you're a developer and you're just downloading the binaries and maybe sending in the odd bug report, you're kind of wasting your talent don't you think?
You know, I'd love to contribute code to Mozilla, but I'm currently bound by an Intellectual Property agreement that does not leave me free to work on Open Source projects at will. I'd like to see this changed, but you know how lawyers are...
As for getting developers to build the source, it's too late to be helpful for M12. If you want to provide valuable feedback for the M12 milestone (or any other), you should be building the source from CVS or nightly snapshots. After they post the final M12 source (as they appear to have), your build results are of limited value -- they would have to be fixed in M13, not in M12.
As such, what purpose is served by slamming the FTP servers to grab the sources, especially when most people want the binaries? Granted, it's better to build the source yourself and debug problems, but if you're looking for binaries, an early announce of M12 when only sources are available doesn't really help anyone.
And if you are building the sources and helping directly, chances are you would have noticed this without Slashdot's help.
Is it really helpful to post an announcement like this before it's entirely ready? Yes, the M12 source is up, but none of the binaries are yet, much less mirrored to other sites.
Couldn't this sort of announcement wait until the mozilla.org announcement is made? I don't imagine they'll delay an announcement unnecessarily, and driving traffic to their FTP server prematurely might not be appreciated...
What we need is FAIR-USE-COPYING for games. i.e. After 10 years, the game becomes public domain. That gives the game companies time to make money, and lets face it, if a game doesn't sell well in the first 10 years, how do they expect it to sell well after??
What you are suggesting here is that the copyright expire after 10 years; by definition, it falls into the public domain after copyright expires.
Someone made a good point about this, being that businesses plan things on a 3-5 year schedule; if they don't expect to turn a profit within that amount of time, they don't do it. Why, then, do they need 95-year copyright protection for things they intend to turn a profit in within 5 years?
Given that the actual intent of copyright (any patents) is to encourage more works to be produced by offering some limited-time protection to make it worthwhile, it would seem that a timeframe closer to 10 years might actually be reasonable from a public-policy perspective.
Unfortunately, many have become convinced that the true purpose of copyright (and patents) is the perpetual enrichment of those lucky enough to have valuable enough "intellectual property" be able to rest on their laurels instead of producing new works.
Disney has already made plenty of money from Mickey Mouse; does extending the copyright really encourage Disney to create new works to eventually enrich the public domain? No. Disney will consider new works just as any other business would -- will we make money on this over the next few years?
Clearly, copyright protections far exceed the bounds and purposes intended by the Constitution. They now serve to enrich the few at the expense of the many. It isn't right, but that's what happens when corporations can use their money to drive the political process to their own ends...
Yay, this makes me even more happy that I chose a soundcard by A3D, hoping to support competition rather than the market leader, when I bought my computer way back when. A year later, and now those who chose SB Live's have a opensource drivers, and what do I have? A $30 closed source (crippled and buggy) solution from Opensound, and Aureal support claiming they might have drivers out "towards the end of 1999" (though they also claim they will be "more open-source" whatever that means).
I got tired of having no sound under Linux for my $30 Aureal A3D card. So, when I was out buying Civ:CTP for Linux, I also picked up a $30 Ensoniq AudioPCI card, which works great under Linux. Problem solved!
Use ".tm" because "tm" is recognized as a trademark abbreviation. To avoid conflict with the country code, don't make it a top-level domain; make it a subdomain of the country where the trademark applies, such as "tm.us". For any international trademarks, "tm.int".
Within each "tm" domain, use subdomains for each trademark category defined, suitably abbreviated. Then, every company with a registered trademark would have undisputed rights to the trademark under the subdomain, but they'd have to prove ownership of the trademark first.
For the few trademarks (McDonalds?) that are viewed as transcending the category boundaries, they could receive domains directly under the appropriate "tm" domain, for free.
Then, offer no trademark protection in the ".com", ".org" and ".net" domains; everyone would know where to look for the real entity owning the trademark they're interested in.
A possible approach to limiting name-grabbing abuse of the ".com", ".org" and ".net" namespaces -- make a registrant's first domain name cheap (say, $10/year), and double the cost for each additional domain. This would cost the small guys less than $30/year (each) if they only have one or two domains (thus using the DNS responsibly), and those owning 3 or more domains would start paying more than they currently do. Abusers who grab up dozens of domains would really pay for abusing the DNS -- holding 20 domains would cost over $10,000,000/year! Compare this to a cost of $600/year -- which total will encourage a multimillion-dollar business to use the DNS responsibly? Which one will discourage domain-name speculators?
To help counter the rampant misinformaion about UDI, I'm pointing out two links from the UDI website as particularly valuable to get an idea why UDI is a good thing and what it's all about:
Note that the first link above is a PDF file, but it contains a good overview of UDI. The second link is a simple ASCII text file, so read it first if you have trouble reading PDF files. If you can read the PDF file, the entire contents of the text file is one of the sections in that PDF file.
(Disclaimer: I'm not affiliated with Project UDI.)
As I understand it, this would be implementation-dependent. Not to say that it would be entirely nonportable, but it would only be possible to program an assembly UDI driver if you were working in a known ABI binding context -- you should still have a C version for portability, since that's what the specification is designed for, but you could have a hand-optimized version for a particular platform ABI binding.
That is, you might highly hand-optimize a UDI driver in assembly for Pentium using the ELF load format. That's all well and good if you're using that platform, but you aren't doing a bit of good for someone running with a SPARC platform using a.out load format, for example. Thus, you should have a general-purpose C version of the driver for non-optimized platforms.
While a hand-optimized assembly driver could clearly function under a UDI environment, I'm not sure if it officially qualifies as a UDI-compliant driver if it's not in portable C code. Even so, it's clear that it could be made to work if enough is known about the particular platform and UDI environment implementation.
UDI encourages binary only drivers which is a Bad Thing. If other OSes want universal drivers, they need to implement Linux driver compatibility. It shouldn't be the other way around. UDI can only hurt linux.
You've got it backwards. UDI encourages binary compatibility where reasonable (e.g. same CPU, same load-file format, etc.) to avoid unnecessary recompilation of drivers. (Do you really think recompiling all your drivers for each Linux kernel release is a good thing? You should only need to recompile them if they were updated.)
Closed drivers are buggy and they always will be without the open source development model. It's hard enough to get specs for hardware now. Imagine if the hardware vendor had a UDI driver. What would motivate them to release specs then?
The same as always. Market pressure. Besides, they'll have an incentive to release the source to hit the largest possible market...
On the other hand: As you might recall, Linux is a multi-platform operating system and I would not consider an Intel-only driver a full blown driver, so given a GPL-covered Windows driver (could you only cite one such driver???) I would have to convert it to the Linux driver interface anyway to make it run on my working machine, which happens to be an Alpha.
UDI is a multi-platform source-level specification. If you had a GPL-covered UDI driver, it would run on any OS with the proper UDI environment support, regardless of the platform. They had a prototype implementation running with identical driver source recompiled for Intel Linux, SPARC Solaris, PowerPC AIX, PA-RISC HP-UX and Alpha Tru64 (Digital Unix), among others...
Binary compatibility is encouraged (where reasonable) to avoid unnecessary recompilation, not to give proprietary vendors any advantage over Open Source developers...
Is UDI only for x86 or was it designed for more than the x86? I realize that the module would have to be compiled for each hardware platform, but is the interface the same?
Yes. They had a prototype implementation where identical source code could be built for Intel Linux, SPARC Solaris, PA-RISC HP-UX, PowerPC AIX, Alpha Tru64 (Digital Unix) and other systems. No changes, just recompilation. This is a source-level specification; binary compatibility is only available in certain situations where it makes sense...
If the module has to only be compiled based on hardware platform, you would get the benefit of all Solaris (Sparc) drivers being available to alternative OS's.
This is correct. Also bear in mind that Sun is one of the partners in the UDI project.
It still would cut down on testing. Have you ever done testing for multiple systems? It can be painful.
Since UDI is intended to carefully define exactly how the driver interfaces with the kernel, it should be clean to debug; drivers shouldn't be making assumptions about kernel internals, and incompatibilities between particular kernel and driver versions should be virtually nonexistent...
P.S. I'm not affiliated with the UDI project; I'm just impressed with the excellent work they've done, and very interested in seeing it succeed so we don't have to live in a work dominated by Microsoft for the rest of my life. I find the lack of critical thinking and blind bashing going on here quite apalling; it strikes me as hypocritical for Linux advocates to jump to conclusions and bash UDI unnecessarily, after bashing Windows advocates for not giving Linux a fair shake....
Enough hysteria! Linux developers should be supporting UDI, tearing it down. This technology is Microsoft's worst nightmare! Think about it. Why is Windows used so much? "Regular people" use Windows because of driver support and application availability. But if you ask such "regular people" about whether they like using Windows, many of them describe all sorts of frustration with nonintuitive UI's, random crashes, and pointless reinstallations.
Windows retains its stranglehold primarily through network effects, and Microsoft depends on that fact for their very survival. Remove those supports and Microsoft will become very unsteady indeed when it can only compete on the basis of actual quality. If UDI is successful, it has the potential to remove fully half of the artificial support propping up Microsoft's array of shoddy products. Like Wine, UDI has the potential to level the playing field, which is good for everyone but Microsoft. Unlike Wine, with UDI, Microsoft didn't write the rules.
UDI was designed from the ground up, originally with Unix systems in mind. It is source-level API, and binary compatibility is a secondary concern. As far as I can see, the main reason to specify binary ABI bindings for UDI appears to be to discourage unnecessary recompilation. Should you really need to recompile your drivers every time you upgrade your kernel, or should the drivers just work with any kernel version? Should you really need to upgrade an otherwise-working kernel just because you need a new driver, or should you be able to compile just the new driver for your existing kernel and load it dynamically into the system without even rebooting? UDI can help decouple dependencies between kernel versions and driver versions and thereby enhance stability. This is a good thing.
Microsoft would not want to support UDI for exactly the reason Linux enthusiasts should support it -- UDI levels the playing field between different operating systems. For UDI to really take off, it would need to be supported under Windows as well as Unix. While Microsoft could implement if, they won't unless and until the market forces them to, much as the market forced Microsoft to support the Internet. (They tried to create their own Microsoft "standard" version, MSN, but that was a dismal failure.)
A third party will have to create a UDI environment implementation for Windows first. That will encourage hardware vendors to stop writing Windows-specific drivers and only write UDI drivers to hit Unix and Windows markets with a single implementation. Since UDI is a source-level specification, it would be in their best interest to release the source to their UDI drivers to penetrate a larger market with no additional effort. This would be good for the industry, but bad for Microsoft; they don't want it to happen.
The Open Source/Free Software community should make every effort to ensure that it does happen -- in particular, writing an Open Source UDI environment implementation for Windows would be very valuable to all users of alternative operating systems. Windows 95/98 is the critical target platform right now, but UDI environments for Windows NT, and even DOS and Windows 3.1 would also be useful, if they could be done.
Adding UDI support to Linux, FreeBSD and other systems should be a top priority. Porting existing drivers from Linux and FreeBSD to UDI should be the next priority, followed by the usual work on stability and performance. Ideally, using the native Linux driver interface should provide no advantage over the UDI interface, and thus the UDI drivers should be preferred. (This will take some time, but it should be the goal.)
It may sound like blasphemy to advocate abandoning the Linux driver interface for UDI, but it's not. I've seen comments that the Linux interface should become the de facto standard. At best, that just means replacing one de facto standard (Windows) with another (Linux). Of course, that can't even happen without displacing Windows by Linux entirely first, since making Windows run Linux drivers would probably be much harder than making Windows run UDI drivers.
UDI would be good for Linux. Kernel developers could concentrate on kernel features and stability without having to worry about the drivers. Driver developers could concentrate on driver features and stability without having to worry about the kernel. After the necessary learning curve and initial investment, it frees everyone to focus on the work they need to focus on without having to be distracted by compatibility issues.
Also, the kernel side of a driver interface only has to be implemented once, in the kernel. The driver side, on the other hand, has to be implemented many times. UDI places more of the burden in the UDI environment (the kernel side of the interface implementation), rather than in the driver itself. It makes more work to implement the kernel side, but it only needs to be done once; it's an investment returned many times over by the simplification of the driver side.
UDI drivers don't have to concern themselves with endianness issues, or with whether or not to disable interrupts, or with multiprocessor synchronization, or even with the possibility of running on an I/O processor rather than the host computer. All that sort of thing is handled by the environment, which means that UDI drivers should be easier to write than Linux or Windows drivers, because they can assumptions which are guaranteed by the specification. It should also make them less prone to bugs, since simpler code is easier to debug.
As for the concern that having sloppy drivers could hurt the stability of Linux, I must point out that this is an existing danger. Some drivers are more stable than others, and you're always better off using hardware with a well-supported driver than an obscure one. However UDI actually provides a solution to dealing with buggy drivers -- there is no assumption that UDI drivers will run in a privileged environment; there's no reason the kernel couldn't use memory protection techniques to protect itself from buggy drivers as it protects itself from buggy user programs. This leads to a valid potential concern about performance, that the context switch could be expensive. This is a classic performance vs. stability tradeoff.
However, it's easily solved -- have both privileged (fast and crashable) and non-privileged (slower but uncrashable) modes, and let the system administrator decide which mode to run each driver in. System administrators could then make their own decisions on the tradeoff between performance and stability, based on their own needs and experience. This could mean even greater stability than Linux already enjoys. Who can argue with that?
The concern about proprietary UDI drivers being released only as binary is a red herring. This is already possible; binary-only Linux device drivers can already be distributed. Since that only covers certain platforms, there's still a large segment of the market being ignored. If a hardware company makes a PCI card that could plug into an Intel Windows, Intel Linux, SPARC Solaris (newer, not sbus models) or Alpha Tru64 system, releasing a UDI driver as source could cover all those platforms with a single development effort. Narrowing the market unnecessarily by releasing only binary drivers could be done, but it isn't in the best interests of any proprietary company; they want to penetrate the largest market available.
UDI could change the largest market from "x86 Windows systems" to "any UDI-compliant platform", as long as Windows is supported. And then the proprietary companies would release source code despite themselves, solely due to selfish decisions to pursue the largest market. This would help to break Microsoft's stranglehold on the industry and provide much more timely hardware support for not only Linux, but also FreeBSD, NetBSD, BeOS and any other OS that ends up with a UDI environment.
UDI also opens the door for new operating systems to compete with established ones (yes, including Linux), without having to waste time implementing the device drivers necessary for acceptance. This will lead to more competition on OS features rather than simply driver support. Competition is good; it helps people focus and create higher-quality code, and encourages steady improvement. If the current duplication of effort for driver development is eliminated, we'll be more likely to see cool new OS features available sooner...
All this UDI bashing is counter-productive. Don't blindly accept the rumors flying around Slashdot. Look at the UDI website and see for yourself. UDI is not a Microsoft initiative. (Like I said, UDI is decidely not in Microsoft's interest because they want to maintain their monopoly.) UDI is not a sneaky Intel plot. (Intel is only one of many supported CPU types, and they appear to have joined the project more recently than most.) UDI is not designed to enable proprietary binary-only drivers, although it won't take special measures to block them either.
UDI is not tied to any particular platform; the model works with single-processor or multi-processor systems, on single-tasking or multi-tasking operating systems, on big-endian or little-endian systems, on the host CPU or on a dedicated I/O processor, on an Intel x86 or on a SPARC or PowerPC, etc. This is good technology, and very well-engineered, and we should applaud it. Yes, it's still new; it probably will be improved futher in the future, and performance is still an open question. Nevertheless, it's the right direction to be heading...
You are not mistaken. The UDI specification is a source-level API specification. While they do intend to provide binary-level ABI bindings, the source-level compatability is the only guarantee.
This hardly seems to encourage more binary drivers, since the source distributions will be usable on more systems, hence so will the hardware. This increases the size of the market, which is entirely in the interest of any vendor.
UDI is emphatically not x86-only. They've already demonstrated prototype implementations where a UDI driver was recompiled unchanged to run on Intel Linux, SPARC Solaris, PowerPC AIX, PA-RISC HP-UX and Alpha Tru64 systems, among others...
It's not an evil Microsoft or Intel plot to seed the world with binary drivers. UDI started as an attempt by multiple Unix vendors to achieve cross-platform device-driver compatibility to help them all get more driver support. It's a technical specification, not a political one. It would be inappropriate and limiting to insist on Open Source implementations; they're trying to achieve maximum portability, not a political purpose.
Key point here: UDI only guarantees source-level compatability -- this gives driver writers an incentive to release the source to support more platforms and thereby work a larger market. Yes, they intend to support binary compatibility where it makes sense -- if the object module format (e.g. ELF) and CPU architecture are compatible, for example.
Many people seem to get outraged about UDI before even educating themselves on what it really is. They listen to RMS's paranoid delusions that it's all a plot to entrench the proprietary vendors, without stopping to check the facts. Go read the overview information at the UDI website and find out what it really is. Have an informed view rather than forming a mob. Think for yourself.
UDI is impressive technology. They really thought it through. It would be a shame for it to get shot down for political reasons that aren't even well-grounded from a political perspective in the first place...
I'd have to second this. The design behind the new layout engine in Mozilla is incredible. It looks to be REALLY powerful, flexible, yet potentially relatively simple for a GUI system. Clearly, it's still a work-in-progress, but the design appears to be very clean. It's also based on GTK+, which is getting a lot of support.
I think it would be interesting to see if the Mozilla GUI could run on bare hardware (or more likely, GGI) as a replacement for X11. Okay, there's still a need for X11 compatibility, but there's probably better ways to do this stuff... (Berlin looks interesting too...)
The telco will slap you with a lawsuit so fast it'll make your head spin if you duplicat a phone book, or use it to build your own list for business purposes.
They may slap you with a lawsuit, but there's no certainty they will win it. In 1991, the Supreme Court ruled that the raw data in a white-pages phone book was not protected by copyright, only the way in which that data is presented.
The case was Feist Publications, Inc. v. Rural Telephone Service Co., Inc., and the Supreme Court said: "This case concerns the interaction of two well-established propositions. The first is that facts are not copyrightable; the other, that compilations of facts generally are." In the end, they decided that the white pages were insufficiently original to warrant copyright protection.
I have to wonder if the WHOIS database that NSI "owns" is actually original enough to be deserving of copyright protection, but that's not up to me to decide...
I submitted this as a story, but it probably won't be posted now. Here is the original Washington Post article all the other news sources are quoting...
I disagree. Microsoft can and quite possibly will create their own Linux distribution, if Linux gets to a point where it is clearly defeating Windows. (It's an open question of whether or not it will reach that point, but it could.)
What does Linux have to offer that BSD doesn't? Mindshare. Linux already has more mindshare than BSD, and it's growing. (This may be unfair to BSD folks, but that's the way it goes sometimes.) If the public perception shifts to Linux over Windows, I would fully expect Microsoft to "embrace and extend" by offering their own version of Linux (to tap into the mindshare), and adding proprietary features via binary-only kernel modules so that other Linux vendors couldn't compete. Quite possibly, Microsoft applications for Linux would then require those proprietary features to operate.
I think if and when we ever see "Microsoft Linux" or "Microsoft Office for Linux", that will be an implicit admission from Microsoft that Linux has won the war with Windows. No doubt Microsoft would try to spin it in such a way that many people would believe that they were always strong supporters of Linux. They might get away with it, too.
Don't underestimate Microsoft; they're very good at what they do best -- marketing, and crushing their competition. It's too bad they aren't as good at actually making stable products...
I've thought about things like this too. It seems like the most plausible implementation of a truly representative democracy. (How to get there from here is a big question.)
It might be useful to break out different decision areas to proxy to different people. On your pet issues, you could assign your vote to others who closely represent your views on those issues. For remaining issues, a default proxy could be assigned, or abstention could be the default for some people.
As for "bread and circuses", it's not clear how to resolve that. Sure, a supermajority can be required, but would that be enough? Hopefully, most people would proxy their votes to someone they personally know and trust and consider to be a thoughtful and responsible person. Those people, in turn, could further proxy those votes to people they trust to make good decisions...
Eventually, you end up with a few people wielding serious power, but with a difference from the current situation. When those decision-makers reach such heights of power, potentially voting for millions of people as a group, they are forced to abide by the trust placed in them. If they attempt to violate that trust, the next layer of proxy voters would recall their proxies and change the votes, to abide by the trust placed in them. If the trust was abused repeatedly, the proxies would be reassigned permanently.
This would ensure accountability throughout the system, and make it more difficult for a privileged minority to grant themselves even more privileges at the expense of the majority. Basically, it would be a practical implementation of grassroots politics.
The question remains -- how do you prevent the "tyranny of the majority"? If an issue arises which taps into the passions of the majority, even a supermajority could potentially override their proxies to force a foolish vote, even if the normal decision-makers (as determined by the chains of proxies) would be wiser than the majority. This could be "bread and circuses" or simple instances of the majority trampling the rights of a minority they don't care for.
Sendmail isn't the part that doesn't scale, it's POP3 when dealing with Sendmail files.
The Unix mailbox format certainly doesn't lend itself well to POP/IMAP usage, particularly when messages may be deleted singly. However, this isn't really sendmail's fault; it's following historical Unix practice.
The obvious solution here is to select a different mail spool format, with better POP/IMAP support. All you need to do is select (or create) a new Mail Delivery Agent (MDA) for sendmail to replace "mail.local" or "procmail" to deliver to the other format. Apart from that, sendmail should work unchanged, unaware of the differences in the mail spool.
This is a very simple situation. It's exactly analogous to both GCC and bison. Both programs are covered under the GPL, and both take input, which is used to generate output. As mentioned, the GPL doesn't even try to claim the output of a GPL-covered program is necessarily covered by the GPL.
Because GCC performs a translation job, the output is covered by the GPL only if the input file (the program you're compiling) was covered by the GPL. (I think there are some tiny routines that can get pulled in automatically by GCC from a library compiled by the system's native compiler, but as I recall, those were placed in the public domain.)
Bison is a different story; a key component of the output of bison is the parser, which is copied from a template file that bison uses. Because the template was under the GPL, the output was a derived work, therefore under the GPL. (The current release of bison now contains a special provision in that template to exempt bison output from the GPL.) Anyone could have used bison (any release) legally to generate proprietary output from a proprietary input file -- provided they rewrote the parser template and used it instead. Since yacc was available, nobody bothered...
So, the solution to original poster's situation is simple; extract all the code that needs to be exempt from the GPL and put it in a template file (or several) with a different license, or as public domain. Use GPL for the program code, but not the template. If you don't hardcode the template information into the GPL program, it doesn't have to infect it.
According to the mkswap(8) manpage that comes with RedHat 6.0, "The maximum useful size of a swap rea now depends on the architecture. It is roughly 2GB on i386, PPC, m68k, ARM, 1GB on sparc, 512MB on mips, 128GB on alpha and 3TB on sparc64." It notes that this is for the new swap area style, which it claims to be supported since 2.1.117. (I don't know if the support is in 2.0.37, but it could be.) It also notes that 8 swap areas are presently allocated, so it's not unlimited. (It can probably be changed fairly easily by recompiling the kernel with a different limit, if it's just a static array.)
All the guidelines for sizing your swap space based on your RAM size are misleading. On some old Unix systems (SunOS 4, I think), physical memory HAD to fit in swap (to do a core dump) and you usually wanted some extra. I think this is the origin of the "double the RAM size" recommendation for swap space. Under Linux (and I think Solaris and many other systems), the swap space is used for overflow for whatever doesn't fit in physical RAM. Your total Virtual Memory (VM) is the sum of your physical RAM and all the swap areas.
The best way to size your swap space is to decide how much total VM you want, then subtract your physical RAM. If you have 64 Meg of RAM, and you feel that's enough VM, nothing says you need to create a swap partition. If you want a gigabyte of VM, add enough swap to make up the difference. It all depends on what you want to do with the computer, and how much disk space you're willing to allocate.
Forget about RAM-to-swap ratios and just focus on total VM. Consider that an old Linux system with 16 Meg of RAM and 32 Meg of swap (double the RAM) had 48 Meg of total VM. Such a machine has less total VM than a newer machine with 64 Meg of RAM and no swap. Your limits will be determined by your total VM, not the ratio.
Ideally, you'd have enough RAM for your total VM needs and no swap -- it's the fastest. Realistically, you'll want far more than average occasionally, so it's best to have at least some swap. Since disk space keeps getting cheaper, allocating a few hundred megabytes doesn't usually hurt much...
Slashdot Mirror
No. The announcement can't wait until there are binaries. *ANYONE* can generate binaries from the source.
Why wait for binaries to make an announcement?
What platforms do you think we should wait until binaries exist for before something is announced? If there's no unixware binary or no intel solaris binary or no sparc linux binary, should we wait?
Why wait for a webmaster to update a website when the files are on ftp?
I'm suggesting not posting an announce of "Mozilla M12 Released" when the release isn't finished yet. While the source code is up, the full release includes binaries for several platforms. Finding bugs in this source release wouldn't help M12 binaries much if this is the final cut.
Believe it or not, there are many people who would rather download the binaries because they don't have the time to build and debug it themselves, but they still want to be involved and report bugs if they find any.
When an announcement comes from Mozilla.org that the release is ready, then the announcement should be posted. Posting it earlier only drives load to the FTP servers by people hoping the binaries will appear any second. (Note that ftp.mozilla.org is hovering around its maximum number of users now.)
Methinks it would help if large Open Source projects would send "press releases" to Slashdot and Freshmeat when ready, and if editors could refrain from posting premature announcements...
The important thing right now is to get as many developers as possible building the source. If you're a developer and you're just downloading the binaries and maybe sending in the odd bug report, you're kind of wasting your talent don't you think?
You know, I'd love to contribute code to Mozilla, but I'm currently bound by an Intellectual Property agreement that does not leave me free to work on Open Source projects at will. I'd like to see this changed, but you know how lawyers are...
As for getting developers to build the source, it's too late to be helpful for M12. If you want to provide valuable feedback for the M12 milestone (or any other), you should be building the source from CVS or nightly snapshots. After they post the final M12 source (as they appear to have), your build results are of limited value -- they would have to be fixed in M13, not in M12.
As such, what purpose is served by slamming the FTP servers to grab the sources, especially when most people want the binaries? Granted, it's better to build the source yourself and debug problems, but if you're looking for binaries, an early announce of M12 when only sources are available doesn't really help anyone.
And if you are building the sources and helping directly, chances are you would have noticed this without Slashdot's help.
Is it really helpful to post an announcement like this before it's entirely ready? Yes, the M12 source is up, but none of the binaries are yet, much less mirrored to other sites.
Couldn't this sort of announcement wait until the mozilla.org announcement is made? I don't imagine they'll delay an announcement unnecessarily, and driving traffic to their FTP server prematurely might not be appreciated...
What we need is FAIR-USE-COPYING for games. i.e. After 10 years, the game becomes public domain. That gives the game companies time to make money, and lets face it, if a game doesn't sell well in the first 10 years, how do they expect it to sell well after??
What you are suggesting here is that the copyright expire after 10 years; by definition, it falls into the public domain after copyright expires.
Someone made a good point about this, being that businesses plan things on a 3-5 year schedule; if they don't expect to turn a profit within that amount of time, they don't do it. Why, then, do they need 95-year copyright protection for things they intend to turn a profit in within 5 years?
Given that the actual intent of copyright (any patents) is to encourage more works to be produced by offering some limited-time protection to make it worthwhile, it would seem that a timeframe closer to 10 years might actually be reasonable from a public-policy perspective.
Unfortunately, many have become convinced that the true purpose of copyright (and patents) is the perpetual enrichment of those lucky enough to have valuable enough "intellectual property" be able to rest on their laurels instead of producing new works.
Disney has already made plenty of money from Mickey Mouse; does extending the copyright really encourage Disney to create new works to eventually enrich the public domain? No. Disney will consider new works just as any other business would -- will we make money on this over the next few years?
Clearly, copyright protections far exceed the bounds and purposes intended by the Constitution. They now serve to enrich the few at the expense of the many. It isn't right, but that's what happens when corporations can use their money to drive the political process to their own ends...
Yay, this makes me even more happy that I chose a soundcard by A3D, hoping to support competition rather than the market leader, when I bought my computer way back when. A year later, and now those who chose SB Live's have a opensource drivers, and what do I have? A $30 closed source (crippled and buggy) solution from Opensound, and Aureal support claiming they might have drivers out "towards the end of 1999" (though they also claim they will be "more open-source" whatever that means).
I got tired of having no sound under Linux for my $30 Aureal A3D card. So, when I was out buying Civ:CTP for Linux, I also picked up a $30 Ensoniq AudioPCI card, which works great under Linux. Problem solved!
Better idea:
Use ".tm" because "tm" is recognized as a trademark abbreviation. To avoid conflict with the country code, don't make it a top-level domain; make it a subdomain of the country where the trademark applies, such as "tm.us". For any international trademarks, "tm.int".
Within each "tm" domain, use subdomains for each trademark category defined, suitably abbreviated. Then, every company with a registered trademark would have undisputed rights to the trademark under the subdomain, but they'd have to prove ownership of the trademark first.
For the few trademarks (McDonalds?) that are viewed as transcending the category boundaries, they could receive domains directly under the appropriate "tm" domain, for free.
Then, offer no trademark protection in the ".com", ".org" and ".net" domains; everyone would know where to look for the real entity owning the trademark they're interested in.
A possible approach to limiting name-grabbing abuse of the ".com", ".org" and ".net" namespaces -- make a registrant's first domain name cheap (say, $10/year), and double the cost for each additional domain. This would cost the small guys less than $30/year (each) if they only have one or two domains (thus using the DNS responsibly), and those owning 3 or more domains would start paying more than they currently do. Abusers who grab up dozens of domains would really pay for abusing the DNS -- holding 20 domains would cost over $10,000,000/year! Compare this to a cost of $600/year -- which total will encourage a multimillion-dollar business to use the DNS responsibly? Which one will discourage domain-name speculators?
- Introduction to UDI (Technical White Paper)
- Functional Requirements (Simplified)
Note that the first link above is a PDF file, but it contains a good overview of UDI. The second link is a simple ASCII text file, so read it first if you have trouble reading PDF files. If you can read the PDF file, the entire contents of the text file is one of the sections in that PDF file.(Disclaimer: I'm not affiliated with Project UDI.)
As I understand it, this would be implementation-dependent. Not to say that it would be entirely nonportable, but it would only be possible to program an assembly UDI driver if you were working in a known ABI binding context -- you should still have a C version for portability, since that's what the specification is designed for, but you could have a hand-optimized version for a particular platform ABI binding.
That is, you might highly hand-optimize a UDI driver in assembly for Pentium using the ELF load format. That's all well and good if you're using that platform, but you aren't doing a bit of good for someone running with a SPARC platform using a.out load format, for example. Thus, you should have a general-purpose C version of the driver for non-optimized platforms.
While a hand-optimized assembly driver could clearly function under a UDI environment, I'm not sure if it officially qualifies as a UDI-compliant driver if it's not in portable C code. Even so, it's clear that it could be made to work if enough is known about the particular platform and UDI environment implementation.
UDI encourages binary only drivers which is a Bad Thing. If other OSes want universal drivers, they need to implement Linux driver compatibility. It shouldn't be the other way around. UDI can only hurt linux.
You've got it backwards. UDI encourages binary compatibility where reasonable (e.g. same CPU, same load-file format, etc.) to avoid unnecessary recompilation of drivers. (Do you really think recompiling all your drivers for each Linux kernel release is a good thing? You should only need to recompile them if they were updated.)
Closed drivers are buggy and they always will be without the open source development model. It's hard enough to get specs for hardware now. Imagine if the hardware vendor had a UDI driver. What would motivate them to release specs then?
The same as always. Market pressure. Besides, they'll have an incentive to release the source to hit the largest possible market...
On the other hand: As you might recall, Linux is a multi-platform operating system and I would not consider an Intel-only driver a full blown driver, so given a GPL-covered Windows driver (could you only cite one such driver???) I would have to convert it to the Linux driver interface anyway to make it run on my working machine, which happens to be an Alpha.
UDI is a multi-platform source-level specification. If you had a GPL-covered UDI driver, it would run on any OS with the proper UDI environment support, regardless of the platform. They had a prototype implementation running with identical driver source recompiled for Intel Linux, SPARC Solaris, PowerPC AIX, PA-RISC HP-UX and Alpha Tru64 (Digital Unix), among others...
Binary compatibility is encouraged (where reasonable) to avoid unnecessary recompilation, not to give proprietary vendors any advantage over Open Source developers...
Is UDI only for x86 or was it designed for more than the x86? I realize that the module would have to be compiled for each hardware platform, but is the interface the same?
Yes. They had a prototype implementation where identical source code could be built for Intel Linux, SPARC Solaris, PA-RISC HP-UX, PowerPC AIX, Alpha Tru64 (Digital Unix) and other systems. No changes, just recompilation. This is a source-level specification; binary compatibility is only available in certain situations where it makes sense...
If the module has to only be compiled based on hardware platform, you would get the benefit of all Solaris (Sparc) drivers being available to alternative OS's.
This is correct. Also bear in mind that Sun is one of the partners in the UDI project.
It still would cut down on testing. Have you ever done testing for multiple systems? It can be painful.
Since UDI is intended to carefully define exactly how the driver interfaces with the kernel, it should be clean to debug; drivers shouldn't be making assumptions about kernel internals, and incompatibilities between particular kernel and driver versions should be virtually nonexistent...
P.S. I'm not affiliated with the UDI project; I'm just impressed with the excellent work they've done, and very interested in seeing it succeed so we don't have to live in a work dominated by Microsoft for the rest of my life. I find the lack of critical thinking and blind bashing going on here quite apalling; it strikes me as hypocritical for Linux advocates to jump to conclusions and bash UDI unnecessarily, after bashing Windows advocates for not giving Linux a fair shake....
Enough hysteria! Linux developers should be supporting UDI, tearing it down. This technology is Microsoft's worst nightmare! Think about it. Why is Windows used so much? "Regular people" use Windows because of driver support and application availability. But if you ask such "regular people" about whether they like using Windows, many of them describe all sorts of frustration with nonintuitive UI's, random crashes, and pointless reinstallations.
Windows retains its stranglehold primarily through network effects, and Microsoft depends on that fact for their very survival. Remove those supports and Microsoft will become very unsteady indeed when it can only compete on the basis of actual quality. If UDI is successful, it has the potential to remove fully half of the artificial support propping up Microsoft's array of shoddy products. Like Wine, UDI has the potential to level the playing field, which is good for everyone but Microsoft. Unlike Wine, with UDI, Microsoft didn't write the rules.
UDI was designed from the ground up, originally with Unix systems in mind. It is source-level API, and binary compatibility is a secondary concern. As far as I can see, the main reason to specify binary ABI bindings for UDI appears to be to discourage unnecessary recompilation. Should you really need to recompile your drivers every time you upgrade your kernel, or should the drivers just work with any kernel version? Should you really need to upgrade an otherwise-working kernel just because you need a new driver, or should you be able to compile just the new driver for your existing kernel and load it dynamically into the system without even rebooting? UDI can help decouple dependencies between kernel versions and driver versions and thereby enhance stability. This is a good thing.
Microsoft would not want to support UDI for exactly the reason Linux enthusiasts should support it -- UDI levels the playing field between different operating systems. For UDI to really take off, it would need to be supported under Windows as well as Unix. While Microsoft could implement if, they won't unless and until the market forces them to, much as the market forced Microsoft to support the Internet. (They tried to create their own Microsoft "standard" version, MSN, but that was a dismal failure.)
A third party will have to create a UDI environment implementation for Windows first. That will encourage hardware vendors to stop writing Windows-specific drivers and only write UDI drivers to hit Unix and Windows markets with a single implementation. Since UDI is a source-level specification, it would be in their best interest to release the source to their UDI drivers to penetrate a larger market with no additional effort. This would be good for the industry, but bad for Microsoft; they don't want it to happen.
The Open Source/Free Software community should make every effort to ensure that it does happen -- in particular, writing an Open Source UDI environment implementation for Windows would be very valuable to all users of alternative operating systems. Windows 95/98 is the critical target platform right now, but UDI environments for Windows NT, and even DOS and Windows 3.1 would also be useful, if they could be done.
Adding UDI support to Linux, FreeBSD and other systems should be a top priority. Porting existing drivers from Linux and FreeBSD to UDI should be the next priority, followed by the usual work on stability and performance. Ideally, using the native Linux driver interface should provide no advantage over the UDI interface, and thus the UDI drivers should be preferred. (This will take some time, but it should be the goal.)
It may sound like blasphemy to advocate abandoning the Linux driver interface for UDI, but it's not. I've seen comments that the Linux interface should become the de facto standard. At best, that just means replacing one de facto standard (Windows) with another (Linux). Of course, that can't even happen without displacing Windows by Linux entirely first, since making Windows run Linux drivers would probably be much harder than making Windows run UDI drivers.
UDI would be good for Linux. Kernel developers could concentrate on kernel features and stability without having to worry about the drivers. Driver developers could concentrate on driver features and stability without having to worry about the kernel. After the necessary learning curve and initial investment, it frees everyone to focus on the work they need to focus on without having to be distracted by compatibility issues.
Also, the kernel side of a driver interface only has to be implemented once, in the kernel. The driver side, on the other hand, has to be implemented many times. UDI places more of the burden in the UDI environment (the kernel side of the interface implementation), rather than in the driver itself. It makes more work to implement the kernel side, but it only needs to be done once; it's an investment returned many times over by the simplification of the driver side.
UDI drivers don't have to concern themselves with endianness issues, or with whether or not to disable interrupts, or with multiprocessor synchronization, or even with the possibility of running on an I/O processor rather than the host computer. All that sort of thing is handled by the environment, which means that UDI drivers should be easier to write than Linux or Windows drivers, because they can assumptions which are guaranteed by the specification. It should also make them less prone to bugs, since simpler code is easier to debug.
As for the concern that having sloppy drivers could hurt the stability of Linux, I must point out that this is an existing danger. Some drivers are more stable than others, and you're always better off using hardware with a well-supported driver than an obscure one. However UDI actually provides a solution to dealing with buggy drivers -- there is no assumption that UDI drivers will run in a privileged environment; there's no reason the kernel couldn't use memory protection techniques to protect itself from buggy drivers as it protects itself from buggy user programs. This leads to a valid potential concern about performance, that the context switch could be expensive. This is a classic performance vs. stability tradeoff.
However, it's easily solved -- have both privileged (fast and crashable) and non-privileged (slower but uncrashable) modes, and let the system administrator decide which mode to run each driver in. System administrators could then make their own decisions on the tradeoff between performance and stability, based on their own needs and experience. This could mean even greater stability than Linux already enjoys. Who can argue with that?
The concern about proprietary UDI drivers being released only as binary is a red herring. This is already possible; binary-only Linux device drivers can already be distributed. Since that only covers certain platforms, there's still a large segment of the market being ignored. If a hardware company makes a PCI card that could plug into an Intel Windows, Intel Linux, SPARC Solaris (newer, not sbus models) or Alpha Tru64 system, releasing a UDI driver as source could cover all those platforms with a single development effort. Narrowing the market unnecessarily by releasing only binary drivers could be done, but it isn't in the best interests of any proprietary company; they want to penetrate the largest market available.
UDI could change the largest market from "x86 Windows systems" to "any UDI-compliant platform", as long as Windows is supported. And then the proprietary companies would release source code despite themselves, solely due to selfish decisions to pursue the largest market. This would help to break Microsoft's stranglehold on the industry and provide much more timely hardware support for not only Linux, but also FreeBSD, NetBSD, BeOS and any other OS that ends up with a UDI environment.
UDI also opens the door for new operating systems to compete with established ones (yes, including Linux), without having to waste time implementing the device drivers necessary for acceptance. This will lead to more competition on OS features rather than simply driver support. Competition is good; it helps people focus and create higher-quality code, and encourages steady improvement. If the current duplication of effort for driver development is eliminated, we'll be more likely to see cool new OS features available sooner...
All this UDI bashing is counter-productive. Don't blindly accept the rumors flying around Slashdot. Look at the UDI website and see for yourself. UDI is not a Microsoft initiative. (Like I said, UDI is decidely not in Microsoft's interest because they want to maintain their monopoly.) UDI is not a sneaky Intel plot. (Intel is only one of many supported CPU types, and they appear to have joined the project more recently than most.) UDI is not designed to enable proprietary binary-only drivers, although it won't take special measures to block them either.
UDI is not tied to any particular platform; the model works with single-processor or multi-processor systems, on single-tasking or multi-tasking operating systems, on big-endian or little-endian systems, on the host CPU or on a dedicated I/O processor, on an Intel x86 or on a SPARC or PowerPC, etc. This is good technology, and very well-engineered, and we should applaud it. Yes, it's still new; it probably will be improved futher in the future, and performance is still an open question. Nevertheless, it's the right direction to be heading...
You are not mistaken. The UDI specification is a source-level API specification. While they do intend to provide binary-level ABI bindings, the source-level compatability is the only guarantee.
This hardly seems to encourage more binary drivers, since the source distributions will be usable on more systems, hence so will the hardware. This increases the size of the market, which is entirely in the interest of any vendor.
UDI is emphatically not x86-only. They've already demonstrated prototype implementations where a UDI driver was recompiled unchanged to run on Intel Linux, SPARC Solaris, PowerPC AIX, PA-RISC HP-UX and Alpha Tru64 systems, among others...
It's not an evil Microsoft or Intel plot to seed the world with binary drivers. UDI started as an attempt by multiple Unix vendors to achieve cross-platform device-driver compatibility to help them all get more driver support. It's a technical specification, not a political one. It would be inappropriate and limiting to insist on Open Source implementations; they're trying to achieve maximum portability, not a political purpose.
Key point here: UDI only guarantees source-level compatability -- this gives driver writers an incentive to release the source to support more platforms and thereby work a larger market. Yes, they intend to support binary compatibility where it makes sense -- if the object module format (e.g. ELF) and CPU architecture are compatible, for example.
Many people seem to get outraged about UDI before even educating themselves on what it really is. They listen to RMS's paranoid delusions that it's all a plot to entrench the proprietary vendors, without stopping to check the facts. Go read the overview information at the UDI website and find out what it really is. Have an informed view rather than forming a mob. Think for yourself.
UDI is impressive technology. They really thought it through. It would be a shame for it to get shot down for political reasons that aren't even well-grounded from a political perspective in the first place...
I'd have to second this. The design behind the new layout engine in Mozilla is incredible. It looks to be REALLY powerful, flexible, yet potentially relatively simple for a GUI system. Clearly, it's still a work-in-progress, but the design appears to be very clean. It's also based on GTK+, which is getting a lot of support.
I think it would be interesting to see if the Mozilla GUI could run on bare hardware (or more likely, GGI) as a replacement for X11. Okay, there's still a need for X11 compatibility, but there's probably better ways to do this stuff... (Berlin looks interesting too...)
The problem here is that you're dead wrong.
The telco will slap you with a lawsuit so fast it'll make your head spin if you duplicat a phone book, or use it to build your own list for business purposes.
They may slap you with a lawsuit, but there's no certainty they will win it. In 1991, the Supreme Court ruled that the raw data in a white-pages phone book was not protected by copyright, only the way in which that data is presented.
The case was Feist Publications, Inc. v. Rural Telephone Service Co., Inc., and the Supreme Court said: "This case concerns the interaction of two well-established propositions. The first is that facts are not copyrightable; the other, that compilations of facts generally are." In the end, they decided that the white pages were insufficiently original to warrant copyright protection.
I have to wonder if the WHOIS database that NSI "owns" is actually original enough to be deserving of copyright protection, but that's not up to me to decide...
I submitted this as a story, but it probably won't be posted now. Here is the original Washington Post article all the other news sources are quoting...
Unfortunately, many people view that as a valid argument. (And one day they wake up to find that all their rights have vanished...)
I disagree. Microsoft can and quite possibly will create their own Linux distribution, if Linux gets to a point where it is clearly defeating Windows. (It's an open question of whether or not it will reach that point, but it could.)
What does Linux have to offer that BSD doesn't? Mindshare. Linux already has more mindshare than BSD, and it's growing. (This may be unfair to BSD folks, but that's the way it goes sometimes.) If the public perception shifts to Linux over Windows, I would fully expect Microsoft to "embrace and extend" by offering their own version of Linux (to tap into the mindshare), and adding proprietary features via binary-only kernel modules so that other Linux vendors couldn't compete. Quite possibly, Microsoft applications for Linux would then require those proprietary features to operate.
I think if and when we ever see "Microsoft Linux" or "Microsoft Office for Linux", that will be an implicit admission from Microsoft that Linux has won the war with Windows. No doubt Microsoft would try to spin it in such a way that many people would believe that they were always strong supporters of Linux. They might get away with it, too.
Don't underestimate Microsoft; they're very good at what they do best -- marketing, and crushing their competition. It's too bad they aren't as good at actually making stable products...
I've thought about things like this too. It seems like the most plausible implementation of a truly representative democracy. (How to get there from here is a big question.)
It might be useful to break out different decision areas to proxy to different people. On your pet issues, you could assign your vote to others who closely represent your views on those issues. For remaining issues, a default proxy could be assigned, or abstention could be the default for some people.
As for "bread and circuses", it's not clear how to resolve that. Sure, a supermajority can be required, but would that be enough? Hopefully, most people would proxy their votes to someone they personally know and trust and consider to be a thoughtful and responsible person. Those people, in turn, could further proxy those votes to people they trust to make good decisions...
Eventually, you end up with a few people wielding serious power, but with a difference from the current situation. When those decision-makers reach such heights of power, potentially voting for millions of people as a group, they are forced to abide by the trust placed in them. If they attempt to violate that trust, the next layer of proxy voters would recall their proxies and change the votes, to abide by the trust placed in them. If the trust was abused repeatedly, the proxies would be reassigned permanently.
This would ensure accountability throughout the system, and make it more difficult for a privileged minority to grant themselves even more privileges at the expense of the majority. Basically, it would be a practical implementation of grassroots politics.
The question remains -- how do you prevent the "tyranny of the majority"? If an issue arises which taps into the passions of the majority, even a supermajority could potentially override their proxies to force a foolish vote, even if the normal decision-makers (as determined by the chains of proxies) would be wiser than the majority. This could be "bread and circuses" or simple instances of the majority trampling the rights of a minority they don't care for.
How could this be effectively prevented?
Sendmail isn't the part that doesn't scale, it's POP3 when dealing with Sendmail files.
The Unix mailbox format certainly doesn't lend itself well to POP/IMAP usage, particularly when messages may be deleted singly. However, this isn't really sendmail's fault; it's following historical Unix practice.
The obvious solution here is to select a different mail spool format, with better POP/IMAP support. All you need to do is select (or create) a new Mail Delivery Agent (MDA) for sendmail to replace "mail.local" or "procmail" to deliver to the other format. Apart from that, sendmail should work unchanged, unaware of the differences in the mail spool.
Hey, if anyone got this "spam" and wants to pass, send it to me. I'd love to get in on this...
Disclaimer: I am not a lawyer.
This is a very simple situation. It's exactly analogous to both GCC and bison. Both programs are covered under the GPL, and both take input, which is used to generate output. As mentioned, the GPL doesn't even try to claim the output of a GPL-covered program is necessarily covered by the GPL.
Because GCC performs a translation job, the output is covered by the GPL only if the input file (the program you're compiling) was covered by the GPL. (I think there are some tiny routines that can get pulled in automatically by GCC from a library compiled by the system's native compiler, but as I recall, those were placed in the public domain.)
Bison is a different story; a key component of the output of bison is the parser, which is copied from a template file that bison uses. Because the template was under the GPL, the output was a derived work, therefore under the GPL. (The current release of bison now contains a special provision in that template to exempt bison output from the GPL.) Anyone could have used bison (any release) legally to generate proprietary output from a proprietary input file -- provided they rewrote the parser template and used it instead. Since yacc was available, nobody bothered...
So, the solution to original poster's situation is simple; extract all the code that needs to be exempt from the GPL and put it in a template file (or several) with a different license, or as public domain. Use GPL for the program code, but not the template. If you don't hardcode the template information into the GPL program, it doesn't have to infect it.
According to the mkswap(8) manpage that comes with RedHat 6.0, "The maximum useful size of a swap rea now depends on the architecture. It is roughly 2GB on i386, PPC, m68k, ARM, 1GB on sparc, 512MB on mips, 128GB on alpha and 3TB on sparc64." It notes that this is for the new swap area style, which it claims to be supported since 2.1.117. (I don't know if the support is in 2.0.37, but it could be.) It also notes that 8 swap areas are presently allocated, so it's not unlimited. (It can probably be changed fairly easily by recompiling the kernel with a different limit, if it's just a static array.)
All the guidelines for sizing your swap space based on your RAM size are misleading. On some old Unix systems (SunOS 4, I think), physical memory HAD to fit in swap (to do a core dump) and you usually wanted some extra. I think this is the origin of the "double the RAM size" recommendation for swap space. Under Linux (and I think Solaris and many other systems), the swap space is used for overflow for whatever doesn't fit in physical RAM. Your total Virtual Memory (VM) is the sum of your physical RAM and all the swap areas.
The best way to size your swap space is to decide how much total VM you want, then subtract your physical RAM. If you have 64 Meg of RAM, and you feel that's enough VM, nothing says you need to create a swap partition. If you want a gigabyte of VM, add enough swap to make up the difference. It all depends on what you want to do with the computer, and how much disk space you're willing to allocate.
Forget about RAM-to-swap ratios and just focus on total VM. Consider that an old Linux system with 16 Meg of RAM and 32 Meg of swap (double the RAM) had 48 Meg of total VM. Such a machine has less total VM than a newer machine with 64 Meg of RAM and no swap. Your limits will be determined by your total VM, not the ratio.
Ideally, you'd have enough RAM for your total VM needs and no swap -- it's the fastest. Realistically, you'll want far more than average occasionally, so it's best to have at least some swap. Since disk space keeps getting cheaper, allocating a few hundred megabytes doesn't usually hurt much...