Slashdot Mirror

The Pumpkins, as I understand it, pushed Machina II out on P2P because Virgin were not interested in putting out another record in a similar vein after Machina I had done so poorly ( hell with that, I thought it was great. )

You can get it at beZip.de, or from the Chicago Metro's website, or finally from this fansite.

Try threading the tracks back into the original Machina order as given on Billys diagram, and I, at least, find the story a bit easier to follow.

Bummer the Machina III remix album from the aborted animated series never got released!

• BeOS5-PersonalEdition.exe (45 MB) - BeOS which installs its filesystem virtual into one file on your Windows partition. No partitioning required, no risk involved! Ideal for trying it out.
• BeOS4Linux.tar.gz (41 MB) - same thing, but installs into a Linux ext2 partition. Needs a bootdisk here, though.
• dano_51d0.zip (68,4 MB) - Never released "next generation" BeOS. If link is buggered, paste this without spaces into emule/lmule/xmule: ed2k://|file|dano_51d0.zip|71802854|30CA778C7F8E1B 5A94557E5CD8923B93|/
• DeveloperEdition-1-1-boot-and-main.zip (188 MB) - Needs own partition. Great distro, about as much fun as a Linux desktop of two years ago.
• BeOS-Zeta-Presentation-CeBIT2003.avi (67 MB)
• OpenBeOS recreates the OS in open source

an article from the University of Hagen for German speaking FreeBSD newbies can be downloaded here:

Download (pdf, 45 pages)

Best Regards,

Sebastian

http://bezip.de

Ciao,

Sebastian

Okay, I've been trolled. C'mon now. "A couple of seconds"? I'm writing this on a P2-300 Vaio laptop. If a menu took a single second to load, Mozilla would be usuable for me. I seriously doubt that you have used Mozilla in the last year. If you have, then you are just lying or trying to run it on a 486 with 16MB of RAM.

Last time I used Mozilla, it was last week; the 19-July build for BeOS. Compared to everything else in BeOS, it was damn slow; so slow that I routinely used NetPositive, with its horrible rendering engine, just to avoid loading Moz.

Optimize the preferences dialog algorithms, and XUL will seem faster.

Fair enough, except that my only complaint with the prefs, at least as compared to the rest of XUL, is that they routinely won't save. They're no slower than anything else, for me at least.

AbiWord supports Windows, Linux, FreeBSD, Mac OS X, and QNX. That's it.

So I guess my copy of AbiWord on BeOS was just a dream then? No, probably not, seeing that it's right here. It doesn't support Mac OS 9 because that's a dead OS.

Also, if you'll read my original post, I don't think XUL should be completely scrapped. I simply think that, on the more popular platforms, XUL should be eschewed in favor of native widgets. Use XUL for AmigaOS, Mac OS 9, and other dead OSes; use native widgets for Windows and GTK.

My point was that Galeon does less than Mozilla. In addition, I believe that a new XUL "theme" (for lack of a better word) could make Mozilla look exactly like Galeon with comparable speed.

I've used themes that have not a single button (simply a URL bar), yet they're slower than Galeon. When I dual-boot into Windows, to run IE, a web browser that does as much as Mozilla, IE runs circles around Moz. So, why?

Sounds very similar to the arguments you are making now.

I have a new slogan for XUL. It's "write once, run anywhere." Oh wait, that's someone else's slogan - Java! Do you think that we should all start programming in Java instead? I think that C is good, Objective C is better, and eventually even higher-level languages should be used. But I think, for the most part, they should always be compiled, not emulated. Clearly most other people agree with me; if write-once run-anywhere was so good, Windows would be written in Java right now.

How about twenty years ago when the X Windows System was first being proposed. Why on earth would anyone want a universal windowing system? It will be the death of innovation and speed.

Funny you should bring that up - I've been advocating the mass deployment of Berlin, now Fresco, for a while now. Because Fresco's much higher-level than X, and will therefore make xplatformability easier. But Fresco is written in C++, and when you run Fresco on your computer, you're running a machine language app. It would be absurd to write Fresco, or X, in Java; it would be insanely slow. Instead, they're written in C/C++; portable to multiple platforms, but fast.

research project after research project has demonstrated that productivity skyrockets after using a scripting language in place of a compiled language like C. These same real-world study documents also demonstrate no great speed increase in most (>90%) applications when C is used.

Productivity for what? I agree that most small apps should be written in some form of a scripting language, as Perl/Python (Parrot!) has become fast enough for most use. Especially for console apps; how great it is to have one console Jabber client that I can run on every platform (yes, it exists). But something like Mozilla is so huge that writing it in an emulated language won't work.

Remember Knuth's 80-20 rule? You did read Knuth's work right? 80% of running time is in 20% of the code. How much time do you think the UI is taking in processing time? Let's suppose for the moment that you're right, I'm wrong, and XUL is the source of all of the problems with speed in Mozilla. In most browsing sessions, I barely touch the menubar; most of my time is spent in the main browser area. If I'm not interacting with XUL most of the time, how can it be such a horrible timesink in real-world use.

I don't know about you, but it's rare that I can get Moz to accept keyboard shortcuts. For whatever reason, it fails to do so. Therefore, I often have to resort to the back and forward buttons. It shouldn't take upwards of 5 seconds to even select "back", as it did on Be. Maybe it's better on other platforms, but not on Be.

That said, I assert that you have not put a profiler on Mozilla and are talking out of your ass with regard to the XUL engine. You might say that the UI design is bad. You might say that some of the backend component calls could use some optimization, but when you say that XUL is too slow to comfortably use, you sound like a fool.

Whereas your insults make you sound more intelligent. I might say that XUL is bad from a philosophical standpoint. I think that all widgets should be consistent. That's why I like Fresco; finally, no more toolkits, everything is consistent, and themes are universal. That's why I hate skins, and why I generally resort to using mpg321 (GPLed clone of mpg123) to play audio, because I can't find a skin-free GTK player. In the case of xmms, I'll freely admit that skins don't make it any slower, and that most of the player is in GTK anyhow. But, in my opinion, the whole concept of a desktop that has ten different programs with ten completely different looks is beyond me. On win32 and GTK, Moz should use native widgets, not for the speed but for consistency.

you can download Mozilla 1.0 for

- Windows
- Linux
- FreeBSD
- BeOS (only 1.0 RC2 at the moment)

from http://bezip.de

Ciao,

Sebastian

some time ago many of my friends thought, that with Palm buying Be, Inc. the end of BeOS would be near.
But now with OpenBeOS and BlueOS comming up nicely, BeOS is far from being dead!
Keep up the good work, develop more apps for BeOS - we need them!
There is still a big community out there loving this great OS!!!

Ciao,

Sebastian

--

BeZip.de - download more than 1.100 shareware and freeware apps for BeOS