Netscape 6 Preview Release 1 is a pre-release version of the next generation browser from Netscape. Given its pre-release status, Netscape recommends that you install this software only if you regularly test pre-release products and that you back up your system prior to installation. Downloading this verison assumes you've read the licensing agreement and understand the potential issues associated with using pre-release products.
The codebase was taken from Netscape on March 31, 1998. People struggled with the old code for months trying to achieve the desired results. On October 26, 1998, Brendan Eich announced that the old code would be mothballed and development would proceed with a completely new architecture. I'm not an expert on the Mozilla codebase, but my impression that most of the code has been replaced, and very little remains of the original Netscape 5.0 codebase.
I'd say Mozilla has come a long way. In just a year and a half, the browser has been almost completely rewritten to be cross-platform and standards-compliant like no other browser. That's quite an accomplishment, whether or not a final release is imminent.
I submitted the article on March 31, 2000. It wasn't posted until April 1. I probably should have put the date in parens after "today" for this very reason, but it is why I mentioned the March 31, 1998 date explicitly. (Really, I'm surprised nobody submitted it much earlier.)
According to the PBS schedule for the DirecTV feed (and other satellite feeds?), "Code Rush" is being broadcast at 10:00 PM on Friday, March 31 instead of 10:00 PM on Thursday, March 30...
Even if this does become law (and let's not let it) it still cannot apply to licenses granted before it becomes law, not in the U.S. at least. The US Constitution has some very plain language in it about
ex post facto laws.
Makes you wonder about the Sonny Bono Copyright Term Extension Act retroactively extending copyrights for existing works, doesn't it?
I don't believe it in the least. I think that people have a choice. Either become a cripple and raise the infant mortality rate or have a few minor cases of problems. The greater good is in effect.
(This is off-topic, but I'm sick of this crap.)
My daughter is dead because of this idea that bureaucrats should mandate vaccines for the "greater good". She was 9 weeks old after being born two months early; she weighed 6 pounds and received 6 vaccines at her 2-month "well-baby" visit. One of those vaccines (Rotavirus) was not tested on premature infants, approved by the CDC despite that fact (and before FDA approval) and mandated as yet another wonderful vaccine to save our children from the nuisance of ever getting sick. It was later removed from the vaccine schedule and then removed from the market entirely due to unforeseen reactions that were acknowledged (for once) by the CDC and the manufacturer.
My daughter was perfectly healthy when she went to the doctor's office, and she was dead 14 hours later. How did this server the greater good? We, the parents, didn't feel it was safe for her to receive these vaccines, but the doctor insisted he/she knew better than we did. (If we had known that Rotavirus was primarily a risk for bottle-fed children in daycare, that it was new and little tested, and that it was a genetically-engineered vaccine made from monkey tissue, we never would have allowed it; my wife was staying home and breastfeeding anyhow.)
What's the opinion of all these "experts" now? Oh, it was SIDS and couldn't be prevented. Bullshit! She was fine until her immature immune system was bombarded by half a dozen pathogens at once. Since the medical community and the pharmaceutical industry have a vested interest in the status quo, we shouldn't be so surprised that so many "unexplainable" SIDS cases peak from 2-6 months of age when routine vaccinations occur at 2, 4 and 6 months of age...
Don't believe everything you hear. Everyone paints such a rosy picture of how vaccines are a triumph of the modern age and our saviors from the ravages of disease, but little serious research goes into the possible dangers of the vaccines themselves. Is it really worth the risk of unknown vaccine reactions to avoid the known mild effects of a disease such as Chicken Pox? (Of course, they relabel familiar diseases to make them sound scary and unfamiliar -- you'll just be told that your child "could die" if they don't get the "Varicella" vaccine. They don't mention that your child could also die from the vaccine itself, that it could weaken their immune system, etc.)
ObTopical: I agree that anti-gravity research may be useful, if only for serendipitous discoveries that may result. On the other hand, funding such speculative research may be an unwise investment if it's with the expectation of a marketable invention rather than basic research...
Okay, I wrote a long, detailed article on this topic, but Netscape crashed on me just when I was about ready to post it after an hour of composing it. Sigh. (I'll try to keep it shorter this time.)
We were trying to make a scalable, reliable, efficient and nearly fault-tolerant mail platform based on a strategy of cheap servers clustered around more expensive (but stable) NetApp filers. The inspiration for this architecture came from the following excellent Earthlink papers:
We wanted to use Maildir format to avoid NFS locking issues on the shared mail spool. (The locking problems seemed to be the main trouble that Earthlink had, using Unix mailbox format.) At the insistence of a new hire, we tried using qmail instead of sendmail as the MTA. (My preference was sendmail, since I know it well; qmail was interesting but an unknown quantity, and we were under a tight deadline.)
Unfortunately, in our attempts to move to the intended server architecture, we ran into a number of assumptions in qmail which are hardcoded and scattered through the "modular" qmail code:
qmail assumes that all users have an entry in/etc/passwd (we needed user information to come from a database, not/etc/passwd)
qmail assumes that each user has a home directory which contains a ".qmail" file to control delivery (we wanted all users to be in Maildir format, and we wanted forwarding information to come from the same database, not from a ".qmail" file)
qmail assumes each user has a unique UID number (calls getpwuid())
qmail assumes its queue directory is local and plays games with the inode numbers (we wanted to experiment with an NFS-mounted queue for fault-tolerance, although the performance tradeoff may have proven unacceptable)
qmail assumes there is only one queue runner, so of course no locking is done on the queue (we wanted to experiment with a shared queue so multiple servers could drain a single queue in parallel and distribute load better)
After fighting with qmail for several weeks, we ended up tossing all that work and starting over with sendmail when the new hire abruptly quit the company. In three days, we had most of the code written and working in sendmail that we fought with qmail for weeks trying to get it to do what we wanted.
In my experience, the core qmail code is nearly incomprehensible, totally unmaintainable, and the much tauted "security" seems to be mostly through obscurity. The code is filled with idioms unique to qmail, and riddled with cross-dependencies between the ridiculous number of separate source files (many of which are one line long). While it may be easy to extend in certain ways envisioned by the author, modifying the core code can be a nightmare.
Sendmail, on the other hand, is very clean. The code is well-modularized with clear interfaces. (I added a new map type to the sendmail source easily, in less than a day with very few lines of the original source modified.) The MDA functions are clearly separated from MTA functions, and the MTA doesn't make unwarranted assumptions. (It often doesn't even make warranted assumptions, but that's a different topic of discussion.) Making a Maildir version of "mail.local" was a breeze. Even modifying the arcane "sendmail.cf" file wasn't nearly as as hard as trying to work with the qmail source code!
In summary, qmail has a niche it fills well -- small, simple user communities on a single server. If you have more than about 5,000 users, you may start finding that the single server no longer can handle the load, and that's when you'll start to stumble across qmail's limitations. If you want to run a serious mail platform under heavy load, sendmail is a better choice.
*or* you can make a word processor which is good (better than ms word) and runs under both windows/mac and linux.
This is the idea behind AbiWord -- a cross-platform open-source word processor that uses an XML-based format as its native file format. The current version runs on Windows, Linux, BeOS, Solaris and other Unix systems. A MacOS port is said to be underway. Don't get me wrong, the features are not there yet, but I think it's a good direction...
The abstract for this patent (titled "Adding real-time support to general purpose operating systems") is:
A general purpose computer operating system is run using a real time operating system. A real time operating system is provided for running real time tasks. A general purpose operating system is provided as one of the real time tasks. The general purpose operating system is preempted as needed for the real time tasks and is prevented from blocking preemption of the non-real time tasks.
Reading the details of the patent, it appears to be real-time code implemented as a wrapper around the general-purpose OS, tricking the OS into thinking the real-time stuff isn't really there.
Although this isn't quite the same approach, the classic Amiga OS achieves the same goal in a cleaner, simpler fashion. The Amiga had real-time priorities associated with each task (analogous to a process in Unix), and a lower-priority task could never preempt a higher-priority task. However, tasks with the same priority would preempt each other with standard round-robin preemptive multitasking. Most user tasks would run at the default priority, in the middle of the range.
It was a very elegant solution, integrated cleanly into the operating system instead of hacked around it. The downside, of course, is that you have to be very careful programming high-priority tasks, since they can starve lower-priority tasks completely with an endless loop...
To illustrate the value of this system, consider the amazing responsiveness the Amiga's GUI had, despite running on an 8 MHz 68000. This was partly due to the fact that the tasks handling the GUI functions ran (by default) at a higher real-time priority, thus weren't slowed by CPU-hungry user tasks. (Also, since the Amiga didn't have virtual memory, paging couldn't slow down the system either...)
Although this isn't the same approach, I'm not entirely convinced this patent is sufficiently novel to deserve a patent. If you give an engineer the task of retrofitting real-time support onto an existing OS with minimum impact, this seems like the obvious solution. (There might also be prior art in implementations of virtual machines...)
There is one sound security practice thats simple, and would clamp down on much of this. I would just love to be able to have everyone (ISP's included) only let packets out from their networks that origionate from their networks. It was as true 5 years ago as it is now -- be a good net admin and clamp down on spoofing!
If anything, ISP's should be more proactive about this, and block bogus IP addresses coming from their customers. Then if a site fails to block the spoofed packets, the ISP would drop them anyhow, and the network as a whole would be protected just as well.
This would be the ideal. Unfortunately, it's probably easier said than done. (Handling one large static block would be easy, but dynamic routing with BGP suddenly makes it more complex...)
Oh well, looks promising. Anyone know if there's an ActiveX wrapper for mozilla yet (IE has had that since IE3)....which is why so many apps have integrated HTML (WinAmp, Neoplanet, Office, and other 3rd party ones I can't remember:)).
Will it really be so hard for Netscape to reclaim the browser market from Microsoft if Mozilla can replace IE easily, is more powerful, and supports web standards better? I guess we'll see...
space.com article: "More Moons Around Earth? ..."
on
Earth's Second Moon
·
· Score: 1
Kudos to Transmeta. They have brilliantly executed a cunning strategy, and are poised to capture the mobile computing market. Intel can't leverage their current technology to compete with this; it isn't like their competition with AMD at all. Transmeta probably has several years to establish themselves in their chosen market before a serious competitor (even Intel) has a chance to catch up with them. (Battery life is a topic near and dear to the heart of any laptop user!)
But I've been thinking about some of the other potential Crusoe has. The possibilities are mind-boggling, and I can only hope Transmeta recognizes them and will exploit them soon...
Consider that with roughly 25% of the transistor count of a Pentium III, their Code Morphing software is able to give them roughly the performance of a 500-MHz Pentium III with a 700-MHz Crusoe chip. This chip executes VLIW "molecules", currently composed of up to 4 "atoms"; it has 4 functional units in the chip, and can do 4 operations per clock cycle.
Now consider what they could do with 100% of the transistor count of a Pentium III. Perhaps 16 functional units executing in parallel, with the effective performance of a 2-GHz Pentium III from a 700-MHz chip? (It may not have the low-power benefits anymore, but it would attract all the power users searching for the fastest chip.)
Even if the gains aren't quite so linear, it seems clear that more parallelism is possible, which could easily lead to speed jumps that Intel might not be able to match, given the extra complexity inherent in out-of-order execution on a superscalar chip like the Pentium III. (And would it really be a problem if that extra parallelism required 1024-bit VLIW instruction words?)
Worse for Intel is the potential for Transmeta to adapt the Code Morphing system to work across multiple Crusoe CPU chips for a single x86 instruction stream. This could lead to an enormous performance increase, possibly at a fairly low cost as well, throwing an amount of silicon at the processing that wouldn't otherwise be manageable on a single die with current fabrication processes.
Crusoe chips could be made to emulate multiple CPUs instead of a single one. This could be used to simulate an SMP arrangement, either on a single Crusoe CPU for testing, or on many Crusoe CPUs to combat the diminishing returns from trying to spread a single x86 stream across too many chips.
An idealized "native" instruction set (let's call it the "Crusoe instruction set") should be created for Crusoe. This should be a CISC instruction set, not RISC or VLIW. It should be a clean architecture, more like M68K than x86. Many registers should be available (256? 1024?), and opcodes should exist to support compilers and hand-coded assembly (such as low-level OS or BIOS code). There should also be opcodes and flags to access special hardware features of the Crusoe chip. It should be possible to map almost any RISC or CISC instruction (or flag) directly into the Crusoe instruction set. Like the PowerPC, it should be able to handle big-endian and little-endian data with equal ease.
The Crusoe instruction set could be used for new Crusoe-specific applications, without restricting future architectural changes in the underlying VLIW instruction set or the Code Morphing software itself.
Higher-level translation software (implemented in the Crusoe instruction set) could then directly translate almost any instruction set into the Crusoe instruction set, which the Code Morphing software would then execute as efficiently as possible on the actual hardware in use. This would allow Crusoe to emulate many different CPUs without requiring a rewrite per emulated CPU for each architectural change to the VLIW instruction set or the Code Morphing software.
Perhaps x86 instructions could be translated to the Crusoe instruction set, but that might be slower. For the x86 market, every ounce of speed still matters, so this may not be worthwhile.
A host OS could be written in the Crusoe instruction set, which would create full Virtual Machine (VM) environments, possibly with diverse requirements. (Project UDI might be helpful here.) Just imagine one Crusoe CPU (or a group; only the Code Morphing software would necessarily know) running virtual machines simultaneously for all of the following: Mac (68K), Mac (PowerPC), Windows NT (x86), Windows 95 (x86), Linux (x86) and Solaris (SPARC). (Of course, the host OS would want to create a Crusoe-instruction-set virtual CPU per virtual machine...)
Given a GCC backend to generate output in the Crusoe instruction set, a "native" Linux build would be trivial. (This might be more efficient than x86 Linux, although with a loss in binary compatibility.)
On a side note, I hope Transmeta doesn't go public. Then they'll be beholden to the whims of investors who care only about short-term returns, even if long-term interests suffer. They've already got some serious funding behind them, and they have a good chance to make a killing in the market to recoup the money they've invested. What would they really gain from an IPO?
Stopping the auctioning of Linux domain names is good, but stopping LinuxOne's IPO would be even better. LinuxOne is a blatent scam, designed to bilk lazy investors out of millions of dollars.
Investors who do their homework will know not to invest in LinuxOne's IPO, but someone is bound to fall for it, and if they do, they will be badly burned by it. This scam can't be good for the reuptation of Linux in general, despite the lack of respect LinuxOne has in the community.
If Linus refuses permission for LinuxOne to use the Linux trademark, can't that be used to stop to IPO, or at least to force them to use a different name and a ticker symbol other than "LINX"?
Stopping LinuxOne's scam would be a true public service...
My objection against make is not it's complicated syntax (which is only complicated because different levels of parsing - make's and sh's - intermix and regular expressions need a bit familiarity), but that it is slow.
There's more to make's apparent "slowness" than meets the eye. Peter Miller has written an excellent analysis in his paper, "Recursive Make Considered Harmful" -- his argument is that make has been misused for years, and we need to rethink how we use it. Instead of recursive invocations of make, we need to use the features of modern make implementations (e.g. GNU make) to make whole-project Makefiles that can do the job make exists to do.
Because Unix projects were once small enough to fit in a single directory comfortably, people got used to the idea of "one directory, one Makefile". When projects began to require many directories to organize the source files, many Makefiles and recursive invocations of make became the norm. This turns out to be extremely inefficient and prone to error, for a variety of reasons detailed in the paper. Instead, he advocates using many fragments of a single Makefile (one fragment per directory) and including those with make's include directive. (Hence the need for a modern make.) The paper also contains a section about writing efficient Makefiles, with techniques to significantly improve processing speed even with traditional recursive make techniques.
Common objections to this technique are also addressed:
4.1. A Single Makefile Is Too Big
4.2. A Single Makefile Is Unmaintainable
4.3. It's Too Hard To Write The Rules
4.4. I Only Want To Build My Little Bit
4.5. The Build Will Take Too Long
4.6. You'll Run Out Of Memory
While these techniques don't seem to have caught on much yet, there are some real-world projects (e.g. XEmacs) that seem to be doing so successfully...
Take the time to read the paper; it looks to be worthwhile...
The head of the FAA is doing a publicity stunt to demonstrate her faith in the Y2K rollover -- flying into San Francisco at 7 minutes past midnight. However, given that air-traffic control systems operate on GMT, what does it say about her "faith" in landing 8 hours after the critical time? (It sure leaves her plenty of time not to board that plane, "just in case"...)
Especially when it comes to aim-bots, it's difficult to guarantee that a player isn't cheating. Statistical analysis might be useful for finding suspicious patterns, but any detection can be spoofed, and truly skilled players might look like aim-bots. (However, a real player might have more realistic hit accuracy and standard deviations -- if the accuracy is too consistent, this may be suspicious.)
The real solution, of course, is community. If honest players refuse to play with cheaters, then the cheaters can't ruin the game. Authentication of players would be necessary, and a community could have procedures to eject cheaters when identified. Calculated statistics from the server could help to identify suspects, and leave it to the community to ascertain whether the suspect is a cheater or a highly-skilled player.
Chances are that highly-skilled players won't be easily ejected as cheaters, and there's always the possibility of such a player proving his/her skill by playing in the physical presence of a trusted community member using a trusted client...
At the risk of being redundant, I think it's important for everyone here to realize that the USPTO is reviewing this patent, not because a bunch of open source geeks (no offense intended, I consider myself a geek) made a fuss about patent reform, but because a bunch of big companies that make generous campain contributions to key lawmakers would stand to suffer because of the existence of this patent. I doubt those same companies will support any patent reform that challenges their own bottom lines.
Sure, we've won this battle, but for the wrong reasons. And, I'm sorry to say, this doesn't bring us all that much closer to winning the war.
I agree that the USPTO couldn't care less about Open Source geeks, and no doubt this "review" is taking place because many powerful companies started leaning heavily on lawmakers, enough that the USPTO is more afraid of not reviewing the patent. With that much pressure on them, there's good reason to hope the patent will be overturned; nothing else would satisfy those who are pressuring the lawmakers to pressure the USPTO.
However, despite the fact that this review is obviously political in nature, it may have a future benefit. If the patent is overturned (and I hope it is), it makes a much stronger example of how out-of-control the USPTO is, that it fails to identify extremely obvious techniques and refuse patents on them -- i.e. the USPTO is incompetent to perform their duties, at least in the area of software.
I'd be interested to see what the General Accounting Office would say about such blatent incompetence -- if Open Source geeks could pressure their lawmakers enough to get them to have the GAO take a closer look, that could potentially lead to some actual reform...
Re:slashdot and cutting edge is about sourcecode!
on
Mozilla M12 Released
·
· Score: 1
Here's what it sounds like you're saying: Slashdot users are oveloading the ftp servers so that the developers can't get any work done. Please don't announce things before they're ready for to be consumed by the general public.
Does this mean that slashdot community is no longer the developer community?
No, I'm saying any developers who are interested enough will already be tracking what's going on, and an announcement like this serves more to pull in people with a more casual interest -- those people would be better served by announcing it after the binaries most of them want are available, right?
For developers willing to make a more serious contribution, let's hope they're already using the CVS server and building every day and fixing bugs so the lazy masses can benefit from their efforts!:-)
The Mozilla build team is experienced enough to figure out for themselves when to post the source - copies of the build probably went out to the mirrors before being posted on the mozilla site. By the time binaries are available the slashdot effect for the sources will have subsided. They know what they're doing.
Don't count on it. This morning when I checked, ftp.mozilla.org had 9 different binary distributions online, and the mozilla.org website does indeed have an announcement about it. Now it is appropriate to consider announcing this on Slashdot.
Nevertheless, don't just assume all mirrors are up-to-date immediately; not all mirrors have any special access. When I checked this morning, the following mirrors appeared to be up-to-date:
So, I found 4 current mirrors. But the other 7 mirrors sites I reached were out of date. (And many listed mirror sites no longer appear to have mirrors -- the mirror list needs to be updated, it would seem.)
The moral of the story is that mirrors don't magically have the data, sometimes you have to give them some time -- and if you don't drive the load to the original source, the mirrors will work better for everyone...
I recall hearing somewhere (can't remember the source, but I remember it was a congressional staffer - can any one else place this?) that it takes on the order of four (that's 4, 2*2, IV) handwritten letters to make a someone in the house/senate take action on an issue.
So perhaps, instead of emailing your congresscritters, you might want to take the 2-3 minutes it takes to write them a letter on the subject.
Interesting point. Another good suggestion I've seen is to send the letter by registered mail. I've seen the claim that the post office "must" hand-deliver registered mail to the recipient by law -- I don't know if this is actually true or not, but it seems clear that a registered letter will make more of an impression whether or not it is truly delivered directly to the congresscritter...
Slashdot Mirror
- Linux 2.2 (extracts into "package" directory like Mozilla milestones)
- Windows
- MacOS 8.5
A warning from Netscape's FTP server:Netscape 6 Preview Release 1 is a pre-release version of the next generation browser from Netscape. Given its pre-release status, Netscape recommends that you install this software only if you regularly test pre-release products and that you back up your system prior to installation. Downloading this verison assumes you've read the licensing agreement and understand the potential issues associated with using pre-release products.
How can an old 6809 based machine like the Amiga possibly compete with modern multi-tasking architectures like the PC?
Pedantic note: The Amiga was based on the 68000 series of microprocessors. The 6809 was not part of this series.
The codebase was taken from Netscape on March 31, 1998. People struggled with the old code for months trying to achieve the desired results. On October 26, 1998, Brendan Eich announced that the old code would be mothballed and development would proceed with a completely new architecture. I'm not an expert on the Mozilla codebase, but my impression that most of the code has been replaced, and very little remains of the original Netscape 5.0 codebase.
The new layout engine (Gecko), the cross-platform component system (XPCOM), the cross-platform front-end toolkit (XPFE), the HTML editor (Ender), the new networking library (Necko) and the mail/news components are all new code that comprises a huge chunk of Mozilla. (And that's not all of the new code!) Calling the new release "Netscape 6.0" was clearly a marketing decision, but it's not totally unreasonable given the extent of changes since the first developer's release of Netscape 5.0...
I'd say Mozilla has come a long way. In just a year and a half, the browser has been almost completely rewritten to be cross-platform and standards-compliant like no other browser. That's quite an accomplishment, whether or not a final release is imminent.
I submitted the article on March 31, 2000. It wasn't posted until April 1. I probably should have put the date in parens after "today" for this very reason, but it is why I mentioned the March 31, 1998 date explicitly. (Really, I'm surprised nobody submitted it much earlier.)
According to the PBS schedule for the DirecTV feed (and other satellite feeds?), "Code Rush" is being broadcast at 10:00 PM on Friday, March 31 instead of 10:00 PM on Thursday, March 30...
Makes you wonder about the Sonny Bono Copyright Term Extension Act retroactively extending copyrights for existing works, doesn't it?
I don't believe it in the least. I think that people have a choice. Either become a cripple and raise the infant mortality rate or have a few minor cases of problems. The greater good is in effect.
(This is off-topic, but I'm sick of this crap.)
My daughter is dead because of this idea that bureaucrats should mandate vaccines for the "greater good". She was 9 weeks old after being born two months early; she weighed 6 pounds and received 6 vaccines at her 2-month "well-baby" visit. One of those vaccines (Rotavirus) was not tested on premature infants, approved by the CDC despite that fact (and before FDA approval) and mandated as yet another wonderful vaccine to save our children from the nuisance of ever getting sick. It was later removed from the vaccine schedule and then removed from the market entirely due to unforeseen reactions that were acknowledged (for once) by the CDC and the manufacturer.
My daughter was perfectly healthy when she went to the doctor's office, and she was dead 14 hours later. How did this server the greater good? We, the parents, didn't feel it was safe for her to receive these vaccines, but the doctor insisted he/she knew better than we did. (If we had known that Rotavirus was primarily a risk for bottle-fed children in daycare, that it was new and little tested, and that it was a genetically-engineered vaccine made from monkey tissue, we never would have allowed it; my wife was staying home and breastfeeding anyhow.)
What's the opinion of all these "experts" now? Oh, it was SIDS and couldn't be prevented. Bullshit! She was fine until her immature immune system was bombarded by half a dozen pathogens at once. Since the medical community and the pharmaceutical industry have a vested interest in the status quo, we shouldn't be so surprised that so many "unexplainable" SIDS cases peak from 2-6 months of age when routine vaccinations occur at 2, 4 and 6 months of age...
Don't believe everything you hear. Everyone paints such a rosy picture of how vaccines are a triumph of the modern age and our saviors from the ravages of disease, but little serious research goes into the possible dangers of the vaccines themselves. Is it really worth the risk of unknown vaccine reactions to avoid the known mild effects of a disease such as Chicken Pox? (Of course, they relabel familiar diseases to make them sound scary and unfamiliar -- you'll just be told that your child "could die" if they don't get the "Varicella" vaccine. They don't mention that your child could also die from the vaccine itself, that it could weaken their immune system, etc.)
ObTopical: I agree that anti-gravity research may be useful, if only for serendipitous discoveries that may result. On the other hand, funding such speculative research may be an unwise investment if it's with the expectation of a marketable invention rather than basic research...
Since the site linked from the story appears to have been slashdotted, here is an alternate link to the same story.
The world would be a little boring if everything that we shall ever invent has already been invented.
This was supposedly said by the U.S. Patent Office over a century ago. However, it appears to be an urban legend.
We were trying to make a scalable, reliable, efficient and nearly fault-tolerant mail platform based on a strategy of cheap servers clustered around more expensive (but stable) NetApp filers. The inspiration for this architecture came from the following excellent Earthlink papers:
- A Scalable News Architecture on a Single Spool
- A Highly Scalable Electronic Mail Service Using Open Systems
We wanted to use Maildir format to avoid NFS locking issues on the shared mail spool. (The locking problems seemed to be the main trouble that Earthlink had, using Unix mailbox format.) At the insistence of a new hire, we tried using qmail instead of sendmail as the MTA. (My preference was sendmail, since I know it well; qmail was interesting but an unknown quantity, and we were under a tight deadline.)Unfortunately, in our attempts to move to the intended server architecture, we ran into a number of assumptions in qmail which are hardcoded and scattered through the "modular" qmail code:
- qmail assumes that all users have an entry in
/etc/passwd (we needed user information to come from a database, not /etc/passwd) - qmail assumes that each user has a home directory which contains a ".qmail" file to control delivery (we wanted all users to be in Maildir format, and we wanted forwarding information to come from the same database, not from a ".qmail" file)
- qmail assumes each user has a unique UID number (calls getpwuid())
- qmail assumes its queue directory is local and plays games with the inode numbers (we wanted to experiment with an NFS-mounted queue for fault-tolerance, although the performance tradeoff may have proven unacceptable)
- qmail assumes there is only one queue runner, so of course no locking is done on the queue (we wanted to experiment with a shared queue so multiple servers could drain a single queue in parallel and distribute load better)
After fighting with qmail for several weeks, we ended up tossing all that work and starting over with sendmail when the new hire abruptly quit the company. In three days, we had most of the code written and working in sendmail that we fought with qmail for weeks trying to get it to do what we wanted.In my experience, the core qmail code is nearly incomprehensible, totally unmaintainable, and the much tauted "security" seems to be mostly through obscurity. The code is filled with idioms unique to qmail, and riddled with cross-dependencies between the ridiculous number of separate source files (many of which are one line long). While it may be easy to extend in certain ways envisioned by the author, modifying the core code can be a nightmare.
Sendmail, on the other hand, is very clean. The code is well-modularized with clear interfaces. (I added a new map type to the sendmail source easily, in less than a day with very few lines of the original source modified.) The MDA functions are clearly separated from MTA functions, and the MTA doesn't make unwarranted assumptions. (It often doesn't even make warranted assumptions, but that's a different topic of discussion.) Making a Maildir version of "mail.local" was a breeze. Even modifying the arcane "sendmail.cf" file wasn't nearly as as hard as trying to work with the qmail source code!
In summary, qmail has a niche it fills well -- small, simple user communities on a single server. If you have more than about 5,000 users, you may start finding that the single server no longer can handle the load, and that's when you'll start to stumble across qmail's limitations. If you want to run a serious mail platform under heavy load, sendmail is a better choice.
*or* you can make a word processor which is good (better than ms word) and runs under both windows/mac and linux.
This is the idea behind AbiWord -- a cross-platform open-source word processor that uses an XML-based format as its native file format. The current version runs on Windows, Linux, BeOS, Solaris and other Unix systems. A MacOS port is said to be underway. Don't get me wrong, the features are not there yet, but I think it's a good direction...
Moderators, please moderate the above comment up. It's a very good idea.
Although this isn't quite the same approach, the classic Amiga OS achieves the same goal in a cleaner, simpler fashion. The Amiga had real-time priorities associated with each task (analogous to a process in Unix), and a lower-priority task could never preempt a higher-priority task. However, tasks with the same priority would preempt each other with standard round-robin preemptive multitasking. Most user tasks would run at the default priority, in the middle of the range.
It was a very elegant solution, integrated cleanly into the operating system instead of hacked around it. The downside, of course, is that you have to be very careful programming high-priority tasks, since they can starve lower-priority tasks completely with an endless loop...
To illustrate the value of this system, consider the amazing responsiveness the Amiga's GUI had, despite running on an 8 MHz 68000. This was partly due to the fact that the tasks handling the GUI functions ran (by default) at a higher real-time priority, thus weren't slowed by CPU-hungry user tasks. (Also, since the Amiga didn't have virtual memory, paging couldn't slow down the system either...)
Although this isn't the same approach, I'm not entirely convinced this patent is sufficiently novel to deserve a patent. If you give an engineer the task of retrofitting real-time support onto an existing OS with minimum impact, this seems like the obvious solution. (There might also be prior art in implementations of virtual machines...)
There is one sound security practice thats simple, and would clamp down on much of this. I would just love to be able to have everyone (ISP's included) only let packets out from their networks that origionate from their networks. It was as true 5 years ago as it is now -- be a good net admin and clamp down on spoofing!
If anything, ISP's should be more proactive about this, and block bogus IP addresses coming from their customers. Then if a site fails to block the spoofed packets, the ISP would drop them anyhow, and the network as a whole would be protected just as well.
This would be the ideal. Unfortunately, it's probably easier said than done. (Handling one large static block would be easy, but dynamic routing with BGP suddenly makes it more complex...)
Oh well, looks promising. Anyone know if there's an ActiveX wrapper for mozilla yet (IE has had that since IE3)....which is why so many apps have integrated HTML (WinAmp, Neoplanet, Office, and other 3rd party ones I can't remember :)).
Adam Lock has a homepage for the Mozilla ActiveX Project. I haven't played with it myself, but from looking over the page, it appears that the project is well along. Also, it allows Mozilla to replace IE as an ActiveX control using the same API! They're also working on allowing Netscape and Mozilla to use ActiveX controls as a plug-in, but this appears to be an early effort yet.
Will it really be so hard for Netscape to reclaim the browser market from Microsoft if Mozilla can replace IE easily, is more powerful, and supports web standards better? I guess we'll see...
space.com has an article about Cruithne as a moon, "More Moons Around Earth? It's Not So Loony", from October 29...
But I've been thinking about some of the other potential Crusoe has. The possibilities are mind-boggling, and I can only hope Transmeta recognizes them and will exploit them soon...
On a side note, I hope Transmeta doesn't go public. Then they'll be beholden to the whims of investors who care only about short-term returns, even if long-term interests suffer. They've already got some serious funding behind them, and they have a good chance to make a killing in the market to recoup the money they've invested. What would they really gain from an IPO?
Stopping the auctioning of Linux domain names is good, but stopping LinuxOne's IPO would be even better. LinuxOne is a blatent scam, designed to bilk lazy investors out of millions of dollars.
Investors who do their homework will know not to invest in LinuxOne's IPO, but someone is bound to fall for it, and if they do, they will be badly burned by it. This scam can't be good for the reuptation of Linux in general, despite the lack of respect LinuxOne has in the community.
If Linus refuses permission for LinuxOne to use the Linux trademark, can't that be used to stop to IPO, or at least to force them to use a different name and a ticker symbol other than "LINX"?
Stopping LinuxOne's scam would be a true public service...
There's more to make's apparent "slowness" than meets the eye. Peter Miller has written an excellent analysis in his paper, "Recursive Make Considered Harmful" -- his argument is that make has been misused for years, and we need to rethink how we use it. Instead of recursive invocations of make, we need to use the features of modern make implementations (e.g. GNU make) to make whole-project Makefiles that can do the job make exists to do.
Because Unix projects were once small enough to fit in a single directory comfortably, people got used to the idea of "one directory, one Makefile". When projects began to require many directories to organize the source files, many Makefiles and recursive invocations of make became the norm. This turns out to be extremely inefficient and prone to error, for a variety of reasons detailed in the paper. Instead, he advocates using many fragments of a single Makefile (one fragment per directory) and including those with make's include directive. (Hence the need for a modern make.) The paper also contains a section about writing efficient Makefiles, with techniques to significantly improve processing speed even with traditional recursive make techniques.
Common objections to this technique are also addressed:
- 4.1. A Single Makefile Is Too Big
- 4.2. A Single Makefile Is Unmaintainable
- 4.3. It's Too Hard To Write The Rules
- 4.4. I Only Want To Build My Little Bit
- 4.5. The Build Will Take Too Long
- 4.6. You'll Run Out Of Memory
While these techniques don't seem to have caught on much yet, there are some real-world projects (e.g. XEmacs) that seem to be doing so successfully...Take the time to read the paper; it looks to be worthwhile...
The head of the FAA is doing a publicity stunt to demonstrate her faith in the Y2K rollover -- flying into San Francisco at 7 minutes past midnight. However, given that air-traffic control systems operate on GMT, what does it say about her "faith" in landing 8 hours after the critical time? (It sure leaves her plenty of time not to board that plane, "just in case"...)
Especially when it comes to aim-bots, it's difficult to guarantee that a player isn't cheating. Statistical analysis might be useful for finding suspicious patterns, but any detection can be spoofed, and truly skilled players might look like aim-bots. (However, a real player might have more realistic hit accuracy and standard deviations -- if the accuracy is too consistent, this may be suspicious.)
The real solution, of course, is community. If honest players refuse to play with cheaters, then the cheaters can't ruin the game. Authentication of players would be necessary, and a community could have procedures to eject cheaters when identified. Calculated statistics from the server could help to identify suspects, and leave it to the community to ascertain whether the suspect is a cheater or a highly-skilled player.
Chances are that highly-skilled players won't be easily ejected as cheaters, and there's always the possibility of such a player proving his/her skill by playing in the physical presence of a trusted community member using a trusted client...
At the risk of being redundant, I think it's important for everyone here to realize that the USPTO is reviewing this patent, not because a bunch of open source geeks (no offense intended, I consider myself a geek) made a fuss about patent reform, but because a bunch of big companies that make generous campain contributions to key lawmakers would stand to suffer because of the existence of this patent. I doubt those same companies will support any patent reform that challenges their own bottom lines.
Sure, we've won this battle, but for the wrong reasons. And, I'm sorry to say, this doesn't bring us all that much closer to winning the war.
I agree that the USPTO couldn't care less about Open Source geeks, and no doubt this "review" is taking place because many powerful companies started leaning heavily on lawmakers, enough that the USPTO is more afraid of not reviewing the patent. With that much pressure on them, there's good reason to hope the patent will be overturned; nothing else would satisfy those who are pressuring the lawmakers to pressure the USPTO.
However, despite the fact that this review is obviously political in nature, it may have a future benefit. If the patent is overturned (and I hope it is), it makes a much stronger example of how out-of-control the USPTO is, that it fails to identify extremely obvious techniques and refuse patents on them -- i.e. the USPTO is incompetent to perform their duties, at least in the area of software.
I'd be interested to see what the General Accounting Office would say about such blatent incompetence -- if Open Source geeks could pressure their lawmakers enough to get them to have the GAO take a closer look, that could potentially lead to some actual reform...
Here's what it sounds like you're saying: Slashdot users are oveloading the ftp servers so that the developers can't get any work done. Please don't announce things before they're ready for to be consumed by the general public.
:-)
Does this mean that slashdot community is no longer the developer community?
No, I'm saying any developers who are interested enough will already be tracking what's going on, and an announcement like this serves more to pull in people with a more casual interest -- those people would be better served by announcing it after the binaries most of them want are available, right?
For developers willing to make a more serious contribution, let's hope they're already using the CVS server and building every day and fixing bugs so the lazy masses can benefit from their efforts!
Don't count on it. This morning when I checked, ftp.mozilla.org had 9 different binary distributions online, and the mozilla.org website does indeed have an announcement about it. Now it is appropriate to consider announcing this on Slashdot.
Nevertheless, don't just assume all mirrors are up-to-date immediately; not all mirrors have any special access. When I checked this morning, the following mirrors appeared to be up-to-date:
So, I found 4 current mirrors. But the other 7 mirrors sites I reached were out of date. (And many listed mirror sites no longer appear to have mirrors -- the mirror list needs to be updated, it would seem.)
The moral of the story is that mirrors don't magically have the data, sometimes you have to give them some time -- and if you don't drive the load to the original source, the mirrors will work better for everyone...
I recall hearing somewhere (can't remember the source, but I remember it was a congressional staffer - can any one else place this?) that it takes on the order of four (that's 4, 2*2, IV) handwritten letters to make a someone in the house/senate take action on an issue.
So perhaps, instead of emailing your congresscritters, you might want to take the 2-3 minutes it takes to write them a letter on the subject.
Interesting point. Another good suggestion I've seen is to send the letter by registered mail. I've seen the claim that the post office "must" hand-deliver registered mail to the recipient by law -- I don't know if this is actually true or not, but it seems clear that a registered letter will make more of an impression whether or not it is truly delivered directly to the congresscritter...