No, a closed source driver is not better than nothing.
Tell that to the large number of people waiting for drivers that aren't forthcoming, who don't have the skills to write the driver themselves.
Closed source == binary == specific kernel version. People will load it for other versions anyway.
A driver version should not be tied to a kernel version in the first place. With a well-defined API (i.e. UDI), this sort of backward-compatibility and forward-compatibility will work and should be encouraged. Needing to rebuild every driver because you updated the kernel is a waste of time and effort, especially when the drivers need updates to match kernel changes.
Closed source == little review == it-compiles-so-ship-it attitude == lousy quality. Both cases lead to people complaining about Linux when it's a specific driver at fault which they almost certainly don't know about.
The Linux UDI environment could be implemented in such a way that the kernel and other drivers and programs are protected from buggy drivers. This is taken for granted in userspace with user programs, but everyone assumes that drivers have to be privileged and that a buggy driver can always crash the kernel. UDI drivers don't know or care if they're running in a protected environment. It might be slower, but it would make Linux more stable, not less! (It would also allow blame for buggy drivers to be placed appropriately.) Also, you would still have the ability to implement an Open Source driver, which would hopefully be of higher quality than the closed source driver, giving the best of both worlds.
Furthermore, a closed source driver will lead to pressure to not update the kernel because it would break closed source drivers == no improvements == obsolete code, code to handle historic cases, etc etc etc.
Quite the opposite, actually. UDI drivers would (finally) separate out policy decisions and leave them in the kernel, where they belong. More improvements could be made to the kernel's driver code, because the API remains unchanged and drivers need not be recoded for architectural changes. Also, there would be no reason not to update the kernel for non-driver changes, since the UDI drivers written for the old kernel would be forward-compatible with the new kernel supporting the same UDI specification. In fact, rewriting drivers using the UDI model would allow existing historic cruft to be discarded easily.
Hardware vendors who can't see the rational for open source now aren't going to suddenly see the light just because it's UDI instead of native. They will still be narrow minded and myopic. They will still imagine their competitors are so inept that they can't or won't reverse engineer the damned thing, even tho they do it themselves all the time.
So? We already have that problem, with companies that refuse to release anything but a Windows-specific binary-only closed-source driver, and no released specs. Handle it the same as now -- buy the products where the vendor "gets it" and shun the ones that don't. Consumers still have some power to affect these things, you know.
As for redundant drivers for different OSs, the problem is NOT getting vendors to write drivers, it's getting vendors to release specs so WE can write drivers. Think of it! They could release ONE spec and get drivers for free. What a concept!
You're in such a hurry to do their work for them? The Open Source community has so many spare development cycles that we should waste them on every variation in hardware instead of developing innovative new software? I've got a better idea -- let the hardware vendors shoulder the burden of basic support for their devices. If they want a high-quality driver, they should be smart enough to release the basic driver as Open Source (and release specs) so that they get bugfixes and enhancements for free. If they're myopic enough to keep the source closed, the market will tend to converge on the smarter companies who release the source because their hardware will work better. I'd rather see development cycles spent on Mozilla than subsidizing hardware vendors...
Backward and forward compatibility hinders development. You get a bloated slow kernel because it has to support all sorts of obsolete crap and try (and fail) to support unknown future capabilities. Worst aspect of "future" compatibility is that future drivers are constrained by previous thinking, meaning losing all advances since the forward compatibility was designed.
It only hinders development if poor API's were chosen to begin with. Look at the compatibility problems caused by IBM's shortsighted BIOS interface, just in the area of hard drives. (540 Meg limit, 2 Gig limit, 8.4 Gig limit, 32 Gig limit, etc.) It is very hard to design a good interface for device drivers that doesn't hinder future code with a bad API. Project UDI has spent years designing this API, and it shows. Why don't you try reading some of the introductory material about UDI? They really thought about this, and came up with a very powerful and flexible framework. (Jury's still out on performance.) Down the road, if UDI 1.0 doesn't meet the needs, a revision of the API could be done, which probably means dual compatibility for a long time. Such a thing wouldn't be done casually.
The ONLY advantage would be for prototyping drivers. Maybe someone could write a user mode driver with a generic kernel interface. Gawddd! Swapping in a user task to handle interrupts! What a mess.
UDI would be excellent for prototyping drivers (even if performance sucks), and good for keeping unstable drivers under control (if the environment is designed for it). Yes, userspace drivers would perform poorly compared to kernelspace drivers, but why not allow both modes? Untrusted drivers could be loaded into userspace and run slowly but safely. After they've proven themselves, the user/sysadmin could choose to allow the driver to run in kernelspace for performance. Best of both worlds. (This switching could potentially even be automated...)
One other thing: UDI represents the best hope for "fringe" operating systems (e.g. HURD) to get comprehensive driver support. A new OS only needs to implement a UDI environment, and all existing UDI drivers would work "for free". Wouldn't more competition between free OS's benefit everyone? Let's relieve alternative OS authors of the burden of constantly trying to achieve device driver parity with established OS's. Linux has been fighting that battle for years. Now that Linux is becoming one of those established OS's, Linux users are getting cavalier about support for non-Linux OS's. Should the "next Linux" have to duplicate all that effort? Entrenched Windows with its superior applications and driver support has always been a major barrier to entry for Linux. Sure, Linux is a better OS, and may "win" over Windows in the end. So when another OS comes out that's better than Linux, would it really be a good thing for that OS to have the same barrier that Linux has had to overcome?
I was told by someone at SCO that Monterey would have UDI as its sole API for drivers, but after a little searching, I found a reference on SCO's website about it -- "UDI device driver model" is listed under "Common Enabling Technologies".
I can see several good reasons for Linux to support UDI drivers:
Drivers may become available that wouldn't otherwise be available. (Even a closed-source driver is better than nothing.)
Hardware manufacturers would have some incentive to release driver source, since only source-level compatibility is guaranteed with UDI.
Linux, FreeBSD and other free operating systems wouldn't have to waste time rewriting drivers already implemented, if they all support UDI -- duplication of effort isn't helpful.
UDI drivers are cleanly separated from policy decisions about operating system implementation; changes to the core OS architecture won't require rewriting UDI drivers.
Since UDI drivers would be backward-compatible and forward-compatible across all UDI-supporting versions of the Linux kernel, there would be no need to rebuild drivers when rebuilding the kernel, and it would be simple (and easier to maintain) to distribute each UDI driver as a separate package rather than including millions of lines of code in the Linux kernel for drivers, when any given user needs only a few of them.
The Linux kernel could be designed to allow memory protection and fault-tolerance of UDI drivers, enhancing system stability at a (further) performance cost. (I'd rather have an experimental driver run slowly than crash my system!)
If the performance is that bad, the existing Linux device driver API could be used for the drivers where performance matters. (Besides, some talented hacker may find a solution to the performance problem.)
Would supporting UDI in the mainline Linux kernel really be such a bad thing?
Project UDI (Uniform Driver Interface) is approaching this write-once, run-anywhere driver implementation idea in a fairly comprehensive manner.
While it's not ready yet, the architecture is impressively clean and powerful. The same UDI driver code could potentially run (with only a recompile, no code changes) on a Windows system (e.g. Win95 or NT), a Unix system (e.g. Solaris or Linux), a small multitasking system without VM (e.g. Amiga), a small singletasking system (e.g. MS-DOS), or an intelligent I/O processor (e.g. I2O)... Each of these systems would need appropriate implementations of the UDI environment, but could run the same drivers. UDI drivers are written with very few assumptions about multitasking, memory protection, etc. You could even protect the OS from buggy drivers! (At a performance cost.)
As a case in point, SCO's next-generation Monterey operating system is slated to use UDI as its sole driver API...
I wasn't whining. I was speculating on what could be done with Mozilla and Perl integrated together.
In point of fact, I am seriously considering working on this myself. It's always a tough decision where to focus attention -- I have many more projects I'm interested in than I have time to devote to them. Because this one is particularly interesting, I suspect it may end up fairly high on the list...
Perhaps 1 MB is optimistic in terms of process size; I was thinking more of executable size. It's about a 500K binary on Linux. To get a better idea of process size, I did "perl -de 0" and at the prompt I did 'system "ps u $$"' to find the size of the fully-initialized perl process -- it came to a little over 3 MB. Worse than 1 MB, but better than 10 MB. And still a small fraction of what Mozilla tends to use...
Java is a poor choice for non-object-oriented programming; Perl isn't exclusively object-oriented like Java, but it is object-oriented. Like C++, you can choose to ignore the object-oriented features and use Perl for straight procedural programming if you prefer. (TMTOWTDI!) That flexibility doesn't mean that Perl is unsuitable for object-oriented programming.
I've seen clean, well-written object-oriented code written in C before; object-oriented programming is more of a programming discipline and architectural design question than a language feature issue. Language features are largely syntactic sugar. (Nice sugar to have, unquestionably, but still syntactic sugar.)
Any true interpreter handles instructions as they come. The bourne shell (/bin/sh) and PHP3 fall into this category. This is more expensive in loops because the instruction-decoding overhead is paid each time through the loop.
You're right, the internal form is not machine code, so the execution of that form is effectively a mini-interpreter/virtual machine. On the other hand, work has been done on compiling Perl to C, which would give you machine code in the end -- this isn't quite ready for prime time yet, but a "real" Perl compiler is in the works.
"Fast enough" means that for many purposes, the extra (and undisputed) speed you can get from recoding in C/C++ isn't really worth the trouble. Would I use Perl for heavy-duty numerical analysis? Probably not. Would I consider using it for a complex application or network server? Yes.
As an example of "fast enough", I recently wrote a small network server in Perl with a select() loop handling multiple TCP/IP connections in parallel with a multiprotocol object-oriented implementation. This server was intended to be an XML-based database server, which worked reasonably well. However, as an experiment, I added minimal HTTP protocol support to the same server, enough to do a GET successfully. Out of curiosity, I had a co-worker do a performance test with his Java-based testing program. I don't recall the exact results, but with 10-20 separate threads hitting the server 10-20 times per second, the average response time was something like 30-50ms. For what I needed, that was fast enough.
By the way, CGI programs aren't a good showcase for Perl's performance, since you pay the overhead of initializing the Perl interpreter and compiling the program for every hit. The Apache mod_perl module is a much better example. (IMDB uses mod_perl for complex database queries and dynamic HTML generation, and it's on the top-20 list of largest sites with fast response times. Is that fast enough?)
Yes, you can easily find examples where Perl won't be fast enough, and in those cases you should write the program in C/C++ for performance. However, in many cases, well-written Perl code will be fast enough. (Keep in mind that a Quicksort in BASIC is preferable to a bubble sort in optimized assembler -- good algorithms are more important than language efficiency.)
In the end, I agree with you. Use what works for you. For me, that's often Perl -- I can write code in Perl much faster than in C, because it's more powerful and saves you from hassles such as memory management. My time is often more valuable than the computer's time, and if I can save 90% of my time for other projects for runtime performance that's 2-3 time slower, that's fine with me as long as the slower runtime is fast enough...
I didn't snub him. All I said was that it's really not a substitute, because it's specific to Windows. Since Mozilla is a cross-platform application, it runs on Windows, Mac, Unix and other platforms (some better than others yet). This is a good thing, since it offers the widest possible audience. I'd rather be locked into a browser choice (Mozilla) and free to choose an OS, then to be locked into browser+OS together (IE+Windows)...
As for ActiveX scripting, I don't know enough about that to comment, but I do know that someone is working on integrating Mozilla with ActiveX on Windows platforms; isn't that a good thing?
Okay, I stand corrected. You can run it under IE on Windows. That doesn't really offer the cross-platform parity that Mozilla does, so it's really not a substitute.
Besides, I was envisioning more than just generating dynamic HTML; I was thinking of bindings that would allow Perl to integrate cleanly with XUL and make fully interactive applications on a portable platform (Mozilla) that would be (hopefully) easier to program than most other cross-platform GUI framework solutions...
Since Perl compiles a program into an internal form and runs that, it doesn't have nearly the overhead of a true interpreted language. However, the Perl compiler is always available for the "eval" operator to dynamically compile and execute more code generated by the program, giving it the flexibility of an interpreted language.
Yes, C/C++ can be made faster than Perl. But well-written Perl code can be fast enough.
What are the flaws in the Safe module that aren't easily resolved? (I agree, Safe and/or Penguin is the obvious way to work with untrusted content.)
The simple solution is to punt and give a warning (a la ActiveX) that this code could do nasty things and ask the user whether or not to trust the code. (Cryptographic signatures on the code would, of course, be helpful here -- as would a web of trust a la PGP.)
Keep in mind, though, that this is not necessarily only useful for web-based applications, but also for more traditional applications where the code is installed on your hard drive, and implicitly trusted. (Thereby neatly side-stepping all the thorny security implications!) Basically, in this scenario, the fact that Mozilla is a browser would be incidental; Mozilla/Perl would be used as a quick, easy, powerful platform for building powerful GUI-based user applications. Can't be any worse than Visual Basic, can it?
Perl may take a different approach than most OO languages, and it only supports method inheritance (no data inheritance), but it's perfectly suited to object-oriented programming. It's more naturally polymorphic than most OO languages. True, Perl doesn't take an "OO Nazi" stance on strictly enforcing OO rules; if you want that, use Java instead.
People who write web pages for a living often have to deal with Perl already for server-side CGI scripts, unless they're an ASP or PHP shop. Perl may have a lot of features that are hard to learn, but you can start small and use just the features you do understand. Strict OO languages don't have this kind of flexibility.
As for Python, it might not be a bad idea, but there are a lot more Perl programmers out there than Python programmers. (Supporting both would be good, especially if via plugins.)
For Netscape to fork and develop separately from Mozilla would discard all the benefits they hoped to gain from releasing Mozilla in the first place.
The only way I could imagine this happening would be if the Mozilla developers took the code in some direction very different from what Netscape is willing to accept. While that's conceivable, both sides have good reason to avoid that sort of division, because of the synergy Netscape and Mozilla have when using the same codebase. (Also, while the majority of Mozilla.org's contributors remain on Netscape's payroll, they'll continue to follow Netscape's priorities.)
Yes, embedding Perl into Mozilla would add about 1 Meg to the size of the runtime. Have you noticed how large that runtime already is? Given that it already can chew up 32 Meg in a flash, I'm not sure that one more would hurt much!
I know that Mozilla is very modular, but I'm not sufficiently familiar with the dynamic loading capabilities (if any) to answer your last question. I don't know if Perl glue would need to be in an XPCOM module (which is probably best) or whether it could be a "plugin" that end-users install (which might be XPCOM; I don't know), but I'm sure it must be possible to embed Perl without re-architecting Mozilla again.
I guess this is a project I could try to work on sometime (if nobody else is already doing it), although there's a lot of code I'd have to familiarize myself with before I could even begin...
PerlScript is a server-side tool to be used in ASP-style pages instead of VBscript. This is completely different from what I was suggesting. My thought was to embed the Perl interpreter in the browser on the client side, to allow not just "dynamic content" but a full-blown application to run entirely on that Mozilla/Perl platform. (Such an application might load from the local hard disk; there may not be a client-server interaction at all...)
Netscape 6 and above will be based on Mozilla, but they will not be entirely Open Source, as proprietary licensed code (e.g. Sun's Java and RSA's cryptographic code) will be added to the Mozilla code. Of course, Netscape will also have different branding, which is mostly a marketing thing. While Netscape and Mozilla could fork completely and drift apart, neither side really wants that to happen.
I believe that the ability to write cross-platform GUI applications on the Mozilla platform is one of the strongest features it has going for it. Even if the "browser wars" fizzle out and IE wins the day (which I really doubt), the platform Mozilla makes available will still be quite valuable in and of itself.
Unfortunately, Javascript may not be the ideal language for writing these cross-platform applications. The thought that's floating around in my mind right now is adding Perl to the mix. It's already impressively cross-platform, and an extremely powerful programming language. Just imagine what you could do with Mozilla's platform coupled with an embedded Perl interpreter and Perl language bindings (e.g. for XUL) as good as (or better than) Javascript's bindings...
You make a good point. I'll try to download some of your MP3's this weekend and check it out. (Can't guarantee I'll like it, but I'll try to check it out at least.)
This is a bit like schoolteachers punishing an entire class in response to the actions of a few. This may be annoying, but it tends to be effective -- it tends to create peer pressure against the perpetrators to behave themselves. Since the script kiddies running these DoS attacks are impacting the service for everyone, this is probably a good thing. Maybe they should do this more often?
Look at this: Why is mozilla/netscape so huge? And are those really 4 processes, or are those 4 threads sharing the same memory?
Those are 4 Linux kernel threads sharing the same memory. They are created at the system level by the Linux clone(2) system call that resembles fork(2), but allows indepent control over shared virtual memory, shared file system information, shared file descriptors, shared signal handlers, and shared process id number. (These are all flags in bitmask parameter to the clone call.)
Unfortunately, each Linux kernel thread takes up a process slot, which I personally don't care for. It means a heavily-threaded program can fill the process table faster and it makes "ps" listings more confusing, as in your example. I'd rather see a two-tier architecture of threads within processes, although I suppose this technique has some flexibility not found in other OS's. (Maybe a two-tier architecture, plus the clone(2) call for when such flexibility is necessary?)
The old Netscape "layer" tag was non-standard, and will not be supported in Mozilla/Netscape 6. My understanding that the equivalent mechanisms used with IE5 should work more or less the same as in IE. (Wow, standards compliance!)
So how come Netscape (and the mozilla project) both ship a tar.gz which unpacks a directory called "package"??
I've asked this question before as well. Apparently it is a tar file of a "package" subdirectory within the Mozilla build tree. That's all well and good, but is it really that hard to rename the directory before tarring it up?
I'll accept it for nightly builds, though I'd like to see the build ID in the directory name. For Mozilla milestones and especially Netscape-branded releases that are targeted at wider audiences, this is clearly poor behavior.
I guess I should really file a Bugzilla bug about it, assuming it isn't already there.
Slashdot Mirror
One other thing: UDI represents the best hope for "fringe" operating systems (e.g. HURD) to get comprehensive driver support. A new OS only needs to implement a UDI environment, and all existing UDI drivers would work "for free". Wouldn't more competition between free OS's benefit everyone? Let's relieve alternative OS authors of the burden of constantly trying to achieve device driver parity with established OS's. Linux has been fighting that battle for years. Now that Linux is becoming one of those established OS's, Linux users are getting cavalier about support for non-Linux OS's. Should the "next Linux" have to duplicate all that effort? Entrenched Windows with its superior applications and driver support has always been a major barrier to entry for Linux. Sure, Linux is a better OS, and may "win" over Windows in the end. So when another OS comes out that's better than Linux, would it really be a good thing for that OS to have the same barrier that Linux has had to overcome?
Thanks for the pointers. I found the second press release, once I knew to look for it...
I hope this gets added to the mainline kernel when it's done...
I was told by someone at SCO that Monterey would have UDI as its sole API for drivers, but after a little searching, I found a reference on SCO's website about it -- "UDI device driver model" is listed under "Common Enabling Technologies".
- Drivers may become available that wouldn't otherwise be available. (Even a closed-source driver is better than nothing.)
- Hardware manufacturers would have some incentive to release driver source, since only source-level compatibility is guaranteed with UDI.
- Linux, FreeBSD and other free operating systems wouldn't have to waste time rewriting drivers already implemented, if they all support UDI -- duplication of effort isn't helpful.
- UDI drivers are cleanly separated from policy decisions about operating system implementation; changes to the core OS architecture won't require rewriting UDI drivers.
- Since UDI drivers would be backward-compatible and forward-compatible across all UDI-supporting versions of the Linux kernel, there would be no need to rebuild drivers when rebuilding the kernel, and it would be simple (and easier to maintain) to distribute each UDI driver as a separate package rather than including millions of lines of code in the Linux kernel for drivers, when any given user needs only a few of them.
- The Linux kernel could be designed to allow memory protection and fault-tolerance of UDI drivers, enhancing system stability at a (further) performance cost. (I'd rather have an experimental driver run slowly than crash my system!)
- If the performance is that bad, the existing Linux device driver API could be used for the drivers where performance matters. (Besides, some talented hacker may find a solution to the performance problem.)
Would supporting UDI in the mainline Linux kernel really be such a bad thing?Project UDI (Uniform Driver Interface) is approaching this write-once, run-anywhere driver implementation idea in a fairly comprehensive manner.
While it's not ready yet, the architecture is impressively clean and powerful. The same UDI driver code could potentially run (with only a recompile, no code changes) on a Windows system (e.g. Win95 or NT), a Unix system (e.g. Solaris or Linux), a small multitasking system without VM (e.g. Amiga), a small singletasking system (e.g. MS-DOS), or an intelligent I/O processor (e.g. I2O)... Each of these systems would need appropriate implementations of the UDI environment, but could run the same drivers. UDI drivers are written with very few assumptions about multitasking, memory protection, etc. You could even protect the OS from buggy drivers! (At a performance cost.)
As a case in point, SCO's next-generation Monterey operating system is slated to use UDI as its sole driver API...
I wasn't whining. I was speculating on what could be done with Mozilla and Perl integrated together.
In point of fact, I am seriously considering working on this myself. It's always a tough decision where to focus attention -- I have many more projects I'm interested in than I have time to devote to them. Because this one is particularly interesting, I suspect it may end up fairly high on the list...
Perhaps 1 MB is optimistic in terms of process size; I was thinking more of executable size. It's about a 500K binary on Linux. To get a better idea of process size, I did "perl -de 0" and at the prompt I did 'system "ps u $$"' to find the size of the fully-initialized perl process -- it came to a little over 3 MB. Worse than 1 MB, but better than 10 MB. And still a small fraction of what Mozilla tends to use...
Java is a poor choice for non-object-oriented programming; Perl isn't exclusively object-oriented like Java, but it is object-oriented. Like C++, you can choose to ignore the object-oriented features and use Perl for straight procedural programming if you prefer. (TMTOWTDI!) That flexibility doesn't mean that Perl is unsuitable for object-oriented programming.
I've seen clean, well-written object-oriented code written in C before; object-oriented programming is more of a programming discipline and architectural design question than a language feature issue. Language features are largely syntactic sugar. (Nice sugar to have, unquestionably, but still syntactic sugar.)
Any true interpreter handles instructions as they come. The bourne shell (/bin/sh) and PHP3 fall into this category. This is more expensive in loops because the instruction-decoding overhead is paid each time through the loop.
You're right, the internal form is not machine code, so the execution of that form is effectively a mini-interpreter/virtual machine. On the other hand, work has been done on compiling Perl to C, which would give you machine code in the end -- this isn't quite ready for prime time yet, but a "real" Perl compiler is in the works.
"Fast enough" means that for many purposes, the extra (and undisputed) speed you can get from recoding in C/C++ isn't really worth the trouble. Would I use Perl for heavy-duty numerical analysis? Probably not. Would I consider using it for a complex application or network server? Yes.
As an example of "fast enough", I recently wrote a small network server in Perl with a select() loop handling multiple TCP/IP connections in parallel with a multiprotocol object-oriented implementation. This server was intended to be an XML-based database server, which worked reasonably well. However, as an experiment, I added minimal HTTP protocol support to the same server, enough to do a GET successfully. Out of curiosity, I had a co-worker do a performance test with his Java-based testing program. I don't recall the exact results, but with 10-20 separate threads hitting the server 10-20 times per second, the average response time was something like 30-50ms. For what I needed, that was fast enough.
By the way, CGI programs aren't a good showcase for Perl's performance, since you pay the overhead of initializing the Perl interpreter and compiling the program for every hit. The Apache mod_perl module is a much better example. (IMDB uses mod_perl for complex database queries and dynamic HTML generation, and it's on the top-20 list of largest sites with fast response times. Is that fast enough?)
Yes, you can easily find examples where Perl won't be fast enough, and in those cases you should write the program in C/C++ for performance. However, in many cases, well-written Perl code will be fast enough. (Keep in mind that a Quicksort in BASIC is preferable to a bubble sort in optimized assembler -- good algorithms are more important than language efficiency.)
In the end, I agree with you. Use what works for you. For me, that's often Perl -- I can write code in Perl much faster than in C, because it's more powerful and saves you from hassles such as memory management. My time is often more valuable than the computer's time, and if I can save 90% of my time for other projects for runtime performance that's 2-3 time slower, that's fine with me as long as the slower runtime is fast enough...
I didn't snub him. All I said was that it's really not a substitute, because it's specific to Windows. Since Mozilla is a cross-platform application, it runs on Windows, Mac, Unix and other platforms (some better than others yet). This is a good thing, since it offers the widest possible audience. I'd rather be locked into a browser choice (Mozilla) and free to choose an OS, then to be locked into browser+OS together (IE+Windows)...
As for ActiveX scripting, I don't know enough about that to comment, but I do know that someone is working on integrating Mozilla with ActiveX on Windows platforms; isn't that a good thing?
Okay, I stand corrected. You can run it under IE on Windows. That doesn't really offer the cross-platform parity that Mozilla does, so it's really not a substitute.
Besides, I was envisioning more than just generating dynamic HTML; I was thinking of bindings that would allow Perl to integrate cleanly with XUL and make fully interactive applications on a portable platform (Mozilla) that would be (hopefully) easier to program than most other cross-platform GUI framework solutions...
Thanks for the pointer.
Since Perl compiles a program into an internal form and runs that, it doesn't have nearly the overhead of a true interpreted language. However, the Perl compiler is always available for the "eval" operator to dynamically compile and execute more code generated by the program, giving it the flexibility of an interpreted language.
Yes, C/C++ can be made faster than Perl. But well-written Perl code can be fast enough.
What are the flaws in the Safe module that aren't easily resolved? (I agree, Safe and/or Penguin is the obvious way to work with untrusted content.)
The simple solution is to punt and give a warning (a la ActiveX) that this code could do nasty things and ask the user whether or not to trust the code. (Cryptographic signatures on the code would, of course, be helpful here -- as would a web of trust a la PGP.)
Keep in mind, though, that this is not necessarily only useful for web-based applications, but also for more traditional applications where the code is installed on your hard drive, and implicitly trusted. (Thereby neatly side-stepping all the thorny security implications!) Basically, in this scenario, the fact that Mozilla is a browser would be incidental; Mozilla/Perl would be used as a quick, easy, powerful platform for building powerful GUI-based user applications. Can't be any worse than Visual Basic, can it?
Perl may take a different approach than most OO languages, and it only supports method inheritance (no data inheritance), but it's perfectly suited to object-oriented programming. It's more naturally polymorphic than most OO languages. True, Perl doesn't take an "OO Nazi" stance on strictly enforcing OO rules; if you want that, use Java instead.
People who write web pages for a living often have to deal with Perl already for server-side CGI scripts, unless they're an ASP or PHP shop. Perl may have a lot of features that are hard to learn, but you can start small and use just the features you do understand. Strict OO languages don't have this kind of flexibility.
As for Python, it might not be a bad idea, but there are a lot more Perl programmers out there than Python programmers. (Supporting both would be good, especially if via plugins.)
For Netscape to fork and develop separately from Mozilla would discard all the benefits they hoped to gain from releasing Mozilla in the first place.
The only way I could imagine this happening would be if the Mozilla developers took the code in some direction very different from what Netscape is willing to accept. While that's conceivable, both sides have good reason to avoid that sort of division, because of the synergy Netscape and Mozilla have when using the same codebase. (Also, while the majority of Mozilla.org's contributors remain on Netscape's payroll, they'll continue to follow Netscape's priorities.)
Yes, embedding Perl into Mozilla would add about 1 Meg to the size of the runtime. Have you noticed how large that runtime already is? Given that it already can chew up 32 Meg in a flash, I'm not sure that one more would hurt much!
I know that Mozilla is very modular, but I'm not sufficiently familiar with the dynamic loading capabilities (if any) to answer your last question. I don't know if Perl glue would need to be in an XPCOM module (which is probably best) or whether it could be a "plugin" that end-users install (which might be XPCOM; I don't know), but I'm sure it must be possible to embed Perl without re-architecting Mozilla again.
I guess this is a project I could try to work on sometime (if nobody else is already doing it), although there's a lot of code I'd have to familiarize myself with before I could even begin...
PerlScript is a server-side tool to be used in ASP-style pages instead of VBscript. This is completely different from what I was suggesting. My thought was to embed the Perl interpreter in the browser on the client side, to allow not just "dynamic content" but a full-blown application to run entirely on that Mozilla/Perl platform. (Such an application might load from the local hard disk; there may not be a client-server interaction at all...)
Netscape 6 and above will be based on Mozilla, but they will not be entirely Open Source, as proprietary licensed code (e.g. Sun's Java and RSA's cryptographic code) will be added to the Mozilla code. Of course, Netscape will also have different branding, which is mostly a marketing thing. While Netscape and Mozilla could fork completely and drift apart, neither side really wants that to happen.
I believe that the ability to write cross-platform GUI applications on the Mozilla platform is one of the strongest features it has going for it. Even if the "browser wars" fizzle out and IE wins the day (which I really doubt), the platform Mozilla makes available will still be quite valuable in and of itself.
Unfortunately, Javascript may not be the ideal language for writing these cross-platform applications. The thought that's floating around in my mind right now is adding Perl to the mix. It's already impressively cross-platform, and an extremely powerful programming language. Just imagine what you could do with Mozilla's platform coupled with an embedded Perl interpreter and Perl language bindings (e.g. for XUL) as good as (or better than) Javascript's bindings...
You make a good point. I'll try to download some of your MP3's this weekend and check it out. (Can't guarantee I'll like it, but I'll try to check it out at least.)
This is a bit like schoolteachers punishing an entire class in response to the actions of a few. This may be annoying, but it tends to be effective -- it tends to create peer pressure against the perpetrators to behave themselves. Since the script kiddies running these DoS attacks are impacting the service for everyone, this is probably a good thing. Maybe they should do this more often?
Look at this: Why is mozilla/netscape so huge? And are those really 4 processes, or are those 4 threads sharing the same memory?
Those are 4 Linux kernel threads sharing the same memory. They are created at the system level by the Linux clone(2) system call that resembles fork(2), but allows indepent control over shared virtual memory, shared file system information, shared file descriptors, shared signal handlers, and shared process id number. (These are all flags in bitmask parameter to the clone call.)
Unfortunately, each Linux kernel thread takes up a process slot, which I personally don't care for. It means a heavily-threaded program can fill the process table faster and it makes "ps" listings more confusing, as in your example. I'd rather see a two-tier architecture of threads within processes, although I suppose this technique has some flexibility not found in other OS's. (Maybe a two-tier architecture, plus the clone(2) call for when such flexibility is necessary?)
The old Netscape "layer" tag was non-standard, and will not be supported in Mozilla/Netscape 6. My understanding that the equivalent mechanisms used with IE5 should work more or less the same as in IE. (Wow, standards compliance!)
So how come Netscape (and the mozilla project) both ship a tar.gz which unpacks a directory called "package"??
I've asked this question before as well. Apparently it is a tar file of a "package" subdirectory within the Mozilla build tree. That's all well and good, but is it really that hard to rename the directory before tarring it up?
I'll accept it for nightly builds, though I'd like to see the build ID in the directory name. For Mozilla milestones and especially Netscape-branded releases that are targeted at wider audiences, this is clearly poor behavior.
I guess I should really file a Bugzilla bug about it, assuming it isn't already there.