I remember seeing original article (by Lempel & Ziv ?) in an IEEE magazine way back. How can it be patented if it was published in a scientific magazine? Isn't it used in just about any compressing algorithm today (winzip, gzip and what not)?
Even RLE is patented. (two separate patents, actually) Algorithm patents have no basis in fairness or reality. It's just a matter of picking the algorithm with the fewest patents, or the algorithm with the patent holders who are least likely to make your life a living hell.
That wouldn't get you much of anywhere; PNG uses the same compression algorithm as gzip, although it is a little more efficient because it is applied a less general fashion.
Netscape 4.5+ IE 4.0+ (kind of) Opera Mozilla W3C Amaya Konqueror GNOME-help
... and there are more, too.
As for lack of animation support, what percentage of GIFs in the sites you folks visit are animated? Of those, what percentage of them actually contribute to the content of the site?
Of those, what percentage would render the sites useless if they were not animated?
Lack of animation support is a lame reason not to use PNGs, at least in the majority of cases, where you don't need animation.
At worst, you can always use GIFs for those specific times when you do really need animation. ---
> 1. Is this LZW compression the same compression > used in the unix "compress" command?
It's related, anyway. Patent problems are among the reasons that the GNU folks created gzip as a replacement for compress.
> If Unisys failed to defend their > patent/copyright (does anyone know the facts > regarding what rights they have to LZW?) for so > long, wouldn't it have lapsed?
They have a patent on the algorithm, and were essentially licencing the patent for free, not failing to defend it outright. It wasn't until LZW started getting widely used that they decided to yank the rug out from under everyone and start charging money.
> 3. Who do we email at Unisys to complain about > this?
You don't. This has been going on a long time now, and a lot of people have been complaining. It seems that as long as they get their money, they don't give a shit what happens the rest of the world. ---
Re:Do you even know what you're talking about?
on
UN Proposes Email Tax
·
· Score: 1
> It's a callous attitude, but if your program has > a memory leak do you just buy more memory?
Of course not; obviously we need to make sure these people don't reproduce, to leave more resources for the rest of us. These people are nothing more than a resource leak in the grand program of life that must be excised... Oh, wait... that's genocide, isn't it?
Yes, it is a very callous attitude. It is an arrogant attitude.
That being said, you are right in implying that there are some fundamental inefficiencies in these areas that limit the effectiveness of simply pumping in resources (i.e. food). I would submit, however, that they are not the result of overpopulation, but corrupt and inefficient governments. There are, even now, enough resources to go around; the problem is that they end up "going around" to a very few people.
Since when has it been right, or even efficient, to eliminate a group of people simply to prop up the economic viability of a wasteful totalitarian regime?
Who made you and your kind the masters of humanity, such that you can select entire portions of the population and deem them a waste of resources?
Since when do you start throwing out valuable data rather than fixing an innefficient resource allocation scheme?
The really sad thing is that in many cases, these governmnents are in power largely because of our intervention in the regional politics in the first place.
Can we stop acting like we know better how to run other people's affairs? Can we stop making things worse because we don't really understand what's going on? Can we stop telling them whether or not they should have children? Can we stop telling them who their leaders should be? (yes, we HAVE contributed to the overthrow of several democratically elected governments)
Can we stop acting like we are some superior civilization, it being our birthright to dictate the way the rest of the world is run? ---
Hey, I've got a better idea! Let's tax...abortions! One million abortions in the USA alone every year, times say $100 == $100 million dollars!
I dunno about you, but I can't say I'd feel comfortable knowing that my internet access was being funded by blood money.
---
Re:Do you even know what you're talking about?
on
UN Proposes Email Tax
·
· Score: 1
> imposing measures intended to prevent births
Oh, like the U.S. has been doing to a number of third-world countries? i.e. money-for-sterilization campeigns in areas that we won't even send enough food (at lower cost) to? ---
Re:Don't abandon your language classes anytime soo
on
Universal Translators?
·
· Score: 1
> A long time? What's this amount to, 15 or 20 > years? It's not like this is a project that has > eluded humanity for centuries.
Actually, it kind of is... software is just the latest and best tool in this quest.
> Breakthroughs are always just around the corner. > Maybe your friend has given you good reason to > play skeptic. The again, maybe he's not the one > who makes the breakthrough.
Oh, bullshit. Some reasonable skepticism is always healthy. It's not like his friend has given up trying.
> By the power of Greyskull! I invoke Moore's Law!
*sigh*
When will you people learn that these things aren't just a matter of throwing more CPU at the problem? You need better algorithms first.
Until you have good algorithms, all the Beowulf clusters in the world aren't going to do you a damn bit of good... ---
Explicit is not always bad. Especially when you have to debug.:-) You can force things to be run out-of-process in CORBA, too, but if you later decide you want them to be in-process, you don't necessarily have to subsequently rewrite (or recompile) any code. For the second point, you are saying that for communication within a single address space http/XML is overkill. Right? You can wrap pretty much anything to be convenient for the programmer; the question is whether or not the runtime overhead is worth it. But isn't CORBA also? Even if the remote call gets "reduced" to standard call for performance reasons, it's still seems like a lot tedious work for the programmer. Having toyed with CORBA a little myself now, I'd have to say that it's really not that evil at all. Even the fearsome memory management funkiness that most people complain about goes away if you use the _var types, which you are supposed to. In the future there will be more networked devices, most of which will talk http, so the idea of a UI based on http/XML is not so far fetched. I'll probably look different than today's desktops and I have no idea what it might be like... I'm suddenly getting visions of an environment using an XML-based language (a la Postscript) for the display engine.:P Which might not actually be bad. I dunno. I think Berlin is going to end up being a major test case for CORBA's utility and viability. ---
When you pass a message to a program it can do any complex task you want. Only the app code will be more explicit (i.e. you will see that you are doing a network operation, rather than pretend that it's a function call).
Indeed. Except that something like WIDL _forces_ you to draw the in-process/out-of-process lines at design/compile time, without giving you flexibility to redraw them later. I think.
A Web server is a simpler thing that exposes an interface to the network (http/XML) and various programs can communicate with it using messages that are readable by humans (to an extend).
That is very true. The value of human-readable (text) protocols are often highly underestimated.
Why not imbed an http interface into an app and use it along with XML for message formatting for communications.
You're talking about replacing IIOP with XML over HTTP... depending on what you're doing, that's a massive amount of overhead compared to the same thing done with IIOP. Absolutely incredibly massive. (for some things, like I think the intended applications of WIDL, the RMI calls aren't going to be that frequent, so you can afford it)
Just the fact that you need IDL is wrong. IDL is completely backwards. You describe your interface in IDL, then compile it to generate code that describes the interface in your favorite language - the same information in two places.
Mmm... yes and no; what it actually generates is a partial implementation of that interface. That being said, IDL's way of doing things still does strike me as kind of funky.
Shouldn't the interface be generated from your sources so that it exists in just one place?
I could provide an analogy, like "Shouldn't the object code be generated from your sources so that [your code] exists in one place? [As opposed to generating assembly and then assembling that to the object code.]". I think that's mainly a property of the way most build environments and compiler frontends are set up. If the compiler frontend would take IDL directly, that step would be hidden too.
I'll have to think about this some more; there is an additional component of having the interface and implementation split into separate source files. (but, is that a bad thing?)
What exactly do you use CORBA for in Berlin? D-n-D?
It's pretty pervasive, actually. Used for quite literally everything. Everything. Have a look at the design documents; I think they do a better job than I can at explaining it.
> I would not want to think about the first, but > the second is a quite interesting proposition. > If every object on your desktop has a URL then > maybe you could get to your desktop from any > machine on the internet.
URLs don't imply either XML/HTML or HTTP, though.
Nor do I think you could do a particularly useful desktop via XML/HTML alone without a supporting technology such as CORBA or COM getting involved somewhere.
> Anyway, have you heard of WIDL? Take a > look...Keep in mind that nearly every machine > connected to the Internet has a web server.
Looks interesting. And useful. However, it also enforces an explicit client/server model. You get RMI, but the "remote" is always very explicit.
Would it be useful for broad in-process use? (no)
Again, I don't see it as competing with CORBA; the two just aren't quite in the same problem space, although there is obviously some overlap. (where the overlap occurs, for many applications I probably would choose WIDL)
And, I suppose my challenge still stands: could you implement something like Berlin, completely replacing CORBA and C++ with WIDL(XML)/HTTP and your language of choice?
> You could argue that IDL is an equivalent > interchange format, but lets face it, IDL's days > are numbered given the amount of work going into > XML.
... XML is an interchange format, IDL is an interface definition format. Two entirely different problem domains... where are you getting these strange ideas from? CORBA/IIOP, for which IDL is generally used for defining object interfaces, is not there to replace XML/HTTP, it's there to transparently glue applications together out of objects scattered across a (potentially) heterogeneous LAN or (less frequently) WAN.
That's quite different from the enforced (and explicit) client/server split enforced by XML/HTTP "applications" (if you can call them that). Which is not to say that XML/HTTP is going anywhere either; it's very very good for document interchange... just, I don't see how it's really any use for implementation-independent distributed execution, which is what CORBA/IIOP addresses...
Now, as for IDL, you can probably define an XML DTD for interface definitions, but it'd be almost by necessity be trivially transformable into IDL anyway, and quite useless for document exchange.
My challenge to you:
- Write and exchange general-purpose documents in IDL format
- Implement a desktop environment using XML and HTTP
When you have done these things (IF you can find a way to do these things), you will understand what each of these standards are meant to do, and what they are not meant to do. ---
Is there any good reason to use CORBA instead of simpler things, like http protocol and (let's say) XML?
XML is a static data format (yes, XSL adds some rather interesting "intelligent" transformation capabilities, but even so). Similarly, HTTP is a (relatively) simple (mostly) unidirectional data transfer protocol. I really don't understand how either can be compared to a distributed object model. Their uses, capabilities and so forth are entirely different.
The whole CORBA thing feels too complex for the simple tasks its trying to acomplished.
What simple tasks? CORBA is not primarily a standard for document interchange, it's a standard for allowing distributed objects to communicate to implement arbitrary functionalities (which may or may not have anything to do with documents, as such). Although, I wouldn't be very inclined to use it for most web stuff, if that's what you mean.
In any case, the uses to which CORBA is most successfuly put are certainly not simple -- take the Berlin project, for example. I really don't see how XML and HTTP would be suitable for implementing a desktop environment.
---
Exigez tous /. des poteaux pour �tre en fran�ais!
on
Austria Bans Spam
·
· Score: 1
> If Hitler had won WWII this post would be > relevant, but since this is not the case, and > since the most widely used language in the world > is definitely *NOT* German, I think we could in > the interests of common sense cut/. a little > slack, eh?
(Bien que plusieurs des utilisateurs de l'Internet ne soient pas les orateurs du français) La langue française est en effet la plus commune au monde, pour inclure les citoyens de beaucoup de pays en Indonésie et en Asie!
C'est simplement "common sense" que le langage servi par la majeure partie du peuple dans le monde doit trop être écrit sur le slashdot.
I hate to be a wet blanket, but I don't see any real motivation for a $30k linux box.
Because the same hardware with a proprietary Unix would likely be a $32k+ box.
The point is not to buy the hefty hardware just for the sake of running Linux, but rather to run Linux on the hefty hardware because it's more cost-effective that way.
so it really has nothing to do at all with the x graphics system or whatever.
No, but the hardware is still accessed directly from userspace in exactly the same fashion as XFree86 and SVGAlib. I was using X11 as a particular example of the problems with the "get overly broad i/o permissions and then beat on the hardware directly from userspace while ignoring the kernel" approach to hardware support.
(Actually, the next rev of XFree86 likely will do 3d graphics support, so there:P)
that reminds me of G.K. Chesterton's "Napoleon of Notting Hill" for some reason (set in 1984; Orwell's book was in part a reaction against it). As an aside, I think both he, Orwell, and Huxley were mostly right; their predictions aren't quite as exclusive as you might think. ---
> Excellent credentials for spotting invented > histories, eh? "It takes one to know one", and > all that.
... hrm? ---
Re: troll who doesn't know how to read
on
EDA: Unix vs. NT
·
· Score: 1
> Err, you definitely need root permission to use > pppd. Obvious since/dev/modem is a device under > unix and hence by default not all users should > be allowed to use pppd. (Well unless/dev/modem > is 777:))
That's why you use Unix groups... although most people don't for some stupid reason.
I'd say that it's premature to be writing off Mozilla at this point. They're still making noticable progress, and I've been keeping a relatively close eye on the project; a lot of the developers are still Netscape engineers, but there have been and continue to be some very important contributions by outsiders. Moreover, even with the revised milestones, we're still looking good for December.
The key here is to get a more or less stable, usable product out. Most causual hackers are going to want something that they can add on to incrementally, and having to engage in massive debugging gets in the way of that. I think that's one of the things that's turned off a lot of potential developers.
Unfortunately, because of the size of the product, it's not really that easy to pick a subset of the functionality, clean that up and release it. Given the product, I'm really not sure that they have much choice but to try and make it spring from the head of Zeus fully formed.
One of the major delaying factors, too, was that the realization that the thing needed more or less rewriting from scratch came so late in the game. It wasn't that long ago that they were still trying to kluge around the Mozilla Classic tree.
In fact, I think the existing codebase is going to be an issue in a lot of cases where a propreitary package is open-sourced.
With some notable exceptions (i.e. massive, mission-critical efforts like Oracle or IBM's database products), closed-source software as a whole tends to be extremely poorly engineered in comparison to most of the open-sourced software I've seen, no matter whether it's written by Mentor Graphics or Netscape or Microsoft or some 14-year-old kid writing shareware. These monolithic kluges are not only badly engineered, they make it extremely difficult for "casual developers" to get involved if the source is ever opened. Open Source development thrives on lightweight, modular designs.
So, more often than not, the new core developers end up with the old codebase dangling from their collective neck like a bloody albatross. It's happened to the Mozilla people, and it's happened to me...
Enter MegaZeux, a considerably more advanced clone of Epic Megagames' first product, ZZT. The original author abandoned it about '95 or '96, and being somewhat of a fan of the software, I campeigned for it to be released under the GPL. I finally got my wish.
I and a handfull of other people spent the next eight months (or perhaps even a little longer than that) trying to coerce the old DOS codebase into something cleaner and more portable (even for DOS; it was beginning to suffer majorly from realmode limitations, and we wanted a 32-bit protected mode port). The code still gives me nightmares. I finally gave up on it late this April.
So, now I'm rewriting the thing from scratch. (I suppose I should point out that the release of the original source wasn't a total waste, as it's not only been an invaluable reference for me, some of the other members of the development team have been adding minor features to the original codebase, which still builds only in Turbo C++)
I guess what I'm trying to say is that it's probably unrealistic to expect newly released proprietary source to be useful for anything beyond reference and scaffolding.
If the codebase actually proves usable, that's great, but I don't think we should launch into these things with the expectation that we won't have to rewrite it all anyway. I think that expectation has been the cause of much of the dissillusionment surrounding Mozilla.
[ n.b. Mozilla has other problems too, ranging from poor management to funky licencing; I just don't think they're as major as most people seem to think ]
that's my $0.02.
P.S. If anyone reading this is interested in the sort of retro-gaming stuff like MegaZeux for Linux (the primary target platform of my rewrite), drop me a line after appropriately de-spamming my email. Or drop by http://www.zeux.org/mzx/ if you're just idly curious about the whole thing. ---
Slashdot Mirror
> GGI is not portable to windows or mac
Actually there's a Win32 port now.
---
I remember seeing original article (by Lempel & Ziv ?) in an IEEE magazine way back. How can it be patented if it was published in a scientific magazine? Isn't it used in just about any compressing algorithm today (winzip, gzip and what not)?
Even RLE is patented. (two separate patents, actually) Algorithm patents have no basis in fairness or reality. It's just a matter of picking the algorithm with the fewest patents, or the algorithm with the patent holders who are least likely to make your life a living hell.
---
> Maybe someone could write a *.pnz (.png.gz)
That wouldn't get you much of anywhere; PNG uses the same compression algorithm as gzip, although it is a little more efficient because it is applied a less general fashion.
---
> Also please note that PNG cannot do animations
> (yet).
That is a reason not to use PNG in cases where you do not need animation?
---
Netscape 4.5+
IE 4.0+ (kind of)
Opera
Mozilla
W3C
Amaya
Konqueror
GNOME-help
... and there are more, too.
As for lack of animation support, what percentage of GIFs in the sites you folks visit are animated?
Of those, what percentage of them actually contribute to the content of the site?
Of those, what percentage would render the sites useless if they were not animated?
Lack of animation support is a lame reason not to use PNGs, at least in the majority of cases, where you don't need animation.
At worst, you can always use GIFs for those specific times when you do really need animation.
---
> 1. Is this LZW compression the same compression
> used in the unix "compress" command?
It's related, anyway. Patent problems are among the reasons that the GNU folks created gzip as a replacement for compress.
> If Unisys failed to defend their
> patent/copyright (does anyone know the facts
> regarding what rights they have to LZW?) for so
> long, wouldn't it have lapsed?
They have a patent on the algorithm, and were essentially licencing the patent for free, not failing to defend it outright. It wasn't until LZW started getting widely used that they decided to yank the rug out from under everyone and start charging money.
> 3. Who do we email at Unisys to complain about
> this?
You don't. This has been going on a long time now, and a lot of people have been complaining. It seems that as long as they get their money, they don't give a shit what happens the rest of the world.
---
> It's a callous attitude, but if your program has
... that's genocide, isn't it?
> a memory leak do you just buy more memory?
Of course not; obviously we need to make sure these people don't reproduce, to leave more resources for the rest of us. These people are nothing more than a resource leak in the grand program of life that must be excised... Oh, wait
Yes, it is a very callous attitude. It is an arrogant attitude.
That being said, you are right in implying that there are some fundamental inefficiencies in these areas that limit the effectiveness of simply pumping in resources (i.e. food). I would submit, however, that they are not the result of overpopulation, but corrupt and inefficient governments. There are, even now, enough resources to go around; the problem is that they end up "going around" to a very few people.
Since when has it been right, or even efficient, to eliminate a group of people simply to prop up the economic viability of a wasteful totalitarian regime?
Who made you and your kind the masters of humanity, such that you can select entire portions of the population and deem them a waste of resources?
Since when do you start throwing out valuable data rather than fixing an innefficient resource allocation scheme?
The really sad thing is that in many cases, these governmnents are in power largely because of our intervention in the regional politics in the first place.
Can we stop acting like we know better how to run other people's affairs? Can we stop making things worse because we don't really understand what's going on? Can we stop telling them whether or not they should have children? Can we stop telling them who their leaders should be? (yes, we HAVE contributed to the overthrow of several democratically elected governments)
Can we stop acting like we are some superior civilization, it being our birthright to dictate the way the rest of the world is run?
---
Hey, I've got a better idea! Let's tax...abortions! One million abortions in the USA alone every year, times say $100 == $100 million dollars!
I dunno about you, but I can't say I'd feel comfortable knowing that my internet access was being funded by blood money.
---
> imposing measures intended to prevent births
Oh, like the U.S. has been doing to a number of third-world countries? i.e. money-for-sterilization campeigns in areas that we won't even send enough food (at lower cost) to?
---
> A long time? What's this amount to, 15 or 20 > years? It's not like this is a project that has > eluded humanity for centuries.
Actually, it kind of is... software is just the latest and best tool in this quest.
> Breakthroughs are always just around the corner.
> Maybe your friend has given you good reason to
> play skeptic. The again, maybe he's not the one
> who makes the breakthrough.
Oh, bullshit. Some reasonable skepticism is always healthy. It's not like his friend has given up trying.
> By the power of Greyskull! I invoke Moore's Law!
*sigh*
When will you people learn that these things aren't just a matter of throwing more CPU at the problem? You need better algorithms first.
Until you have good algorithms, all the Beowulf clusters in the world aren't going to do you a damn bit of good...
---
Explicit is not always bad. Especially when you have to debug. :-) You can force things to be run out-of-process in CORBA, too, but if you later decide you want them to be in-process, you don't necessarily have to subsequently rewrite (or recompile) any code. For the second point, you are saying that for communication within a single address space http/XML is overkill. Right? You can wrap pretty much anything to be convenient for the programmer; the question is whether or not the runtime overhead is worth it. But isn't CORBA also? Even if the remote call gets "reduced" to standard call for performance reasons, it's still seems like a lot tedious work for the programmer. Having toyed with CORBA a little myself now, I'd have to say that it's really not that evil at all. Even the fearsome memory management funkiness that most people complain about goes away if you use the _var types, which you are supposed to. In the future there will be more networked devices, most of which will talk http, so the idea of a UI based on http/XML is not so far fetched. I'll probably look different than today's desktops and I have no idea what it might be like... I'm suddenly getting visions of an environment using an XML-based language (a la Postscript) for the display engine. :P Which might not actually be bad. I dunno. I think Berlin is going to end up being a major test case for CORBA's utility and viability.
---
When you pass a message to a program it can do any complex task you want. Only the app code will be more explicit (i.e. you will see that you are doing a network operation, rather than pretend that it's a function call).
Indeed. Except that something like WIDL _forces_ you to draw the in-process/out-of-process lines at design/compile time, without giving you flexibility to redraw them later. I think.
A Web server is a simpler thing that exposes an interface to the network (http/XML) and various programs can communicate with it using messages that are readable by humans (to an extend).
That is very true. The value of human-readable (text) protocols are often highly underestimated.
Why not imbed an http interface into an app and use it along with XML for message formatting for communications.
You're talking about replacing IIOP with XML over HTTP... depending on what you're doing, that's a massive amount of overhead compared to the same thing done with IIOP. Absolutely incredibly massive. (for some things, like I think the intended applications of WIDL, the RMI calls aren't going to be that frequent, so you can afford it)
Just the fact that you need IDL is wrong. IDL is completely backwards. You describe your interface in IDL, then compile it to generate code that describes the interface in your favorite language - the same information in two places.
Mmm... yes and no; what it actually generates is a partial implementation of that interface. That being said, IDL's way of doing things still does strike me as kind of funky.
Shouldn't the interface be generated from your sources so that it exists in just one place?
I could provide an analogy, like "Shouldn't the object code be generated from your sources so that [your code] exists in one place? [As opposed to generating assembly and then assembling that to the object code.]". I think that's mainly a property of the way most build environments and compiler frontends are set up. If the compiler frontend would take IDL directly, that step would be hidden too.
I'll have to think about this some more; there is an additional component of having the interface and implementation split into separate source files. (but, is that a bad thing?)
What exactly do you use CORBA for in Berlin? D-n-D?
It's pretty pervasive, actually. Used for quite literally everything. Everything. Have a look at the design documents; I think they do a better job than I can at explaining it.
---
> I would not want to think about the first, but
> the second is a quite interesting proposition.
> If every object on your desktop has a URL then
> maybe you could get to your desktop from any
> machine on the internet.
URLs don't imply either XML/HTML or HTTP, though.
Nor do I think you could do a particularly useful desktop via XML/HTML alone without a supporting technology such as CORBA or COM getting involved somewhere.
> Anyway, have you heard of WIDL? Take a
> look...Keep in mind that nearly every machine
> connected to the Internet has a web server.
Looks interesting. And useful. However, it also enforces an explicit client/server model. You get RMI, but the "remote" is always very explicit.
Would it be useful for broad in-process use? (no)
Again, I don't see it as competing with CORBA; the two just aren't quite in the same problem space, although there is obviously some overlap. (where the overlap occurs, for many applications I probably would choose WIDL)
And, I suppose my challenge still stands: could you implement something like Berlin, completely replacing CORBA and C++ with WIDL(XML)/HTTP and your language of choice?
If so, would it be practical?
---
HTTP and IIOP address two different problem domains: delivering data versus RMI. There's absolutely no reason why they can't coexist.
---
> You could argue that IDL is an equivalent
> interchange format, but lets face it, IDL's days
> are numbered given the amount of work going into
> XML.
... XML is an interchange format, IDL is an interface definition format. Two entirely different problem domains... where are you getting these strange ideas from? CORBA/IIOP, for which IDL is generally used for defining object interfaces, is not there to replace XML/HTTP, it's there to transparently glue applications together out of objects scattered across a (potentially) heterogeneous LAN or (less frequently) WAN.
That's quite different from the enforced (and explicit) client/server split enforced by XML/HTTP "applications" (if you can call them that). Which is not to say that XML/HTTP is going anywhere either; it's very very good for document interchange... just, I don't see how it's really any use for implementation-independent distributed execution, which is what CORBA/IIOP addresses...
Now, as for IDL, you can probably define an XML DTD for interface definitions, but it'd be almost by necessity be trivially transformable into IDL anyway, and quite useless for document exchange.
My challenge to you:
- Write and exchange general-purpose documents in IDL format
- Implement a desktop environment using XML and HTTP
When you have done these things (IF you can find a way to do these things), you will understand what each of these standards are meant to do, and what they are not meant to do.
---
Is there any good reason to use CORBA instead of simpler things, like http protocol and (let's say) XML?
XML is a static data format (yes, XSL adds some rather interesting "intelligent" transformation capabilities, but even so). Similarly, HTTP is a (relatively) simple (mostly) unidirectional data transfer protocol. I really don't understand how either can be compared to a distributed object model. Their uses, capabilities and so forth are entirely different.
The whole CORBA thing feels too complex for the simple tasks its trying to acomplished.
What simple tasks? CORBA is not primarily a standard for document interchange, it's a standard for allowing distributed objects to communicate to implement arbitrary functionalities (which may or may not have anything to do with documents, as such). Although, I wouldn't be very inclined to use it for most web stuff, if that's what you mean.
In any case, the uses to which CORBA is most successfuly put are certainly not simple -- take the Berlin project, for example. I really don't see how XML and HTTP would be suitable for implementing a desktop environment.
---
> If Hitler had won WWII this post would be /. a little
> relevant, but since this is not the case, and
> since the most widely used language in the world
> is definitely *NOT* German, I think we could in > the interests of common sense cut
> slack, eh?
(Bien que plusieurs des utilisateurs de l'Internet ne soient pas les orateurs du français) La langue française est en effet la plus commune au monde, pour inclure les citoyens de beaucoup de pays en Indonésie et en Asie!
C'est simplement "common sense" que le langage servi par la majeure partie du peuple dans le monde doit trop être écrit sur le slashdot.
---
I hate to be a wet blanket, but I don't see any real motivation for a $30k linux box.
Because the same hardware with a proprietary Unix would likely be a $32k+ box.
The point is not to buy the hefty hardware just for the sake of running Linux, but rather to run Linux on the hefty hardware because it's more cost-effective that way.
---
so it really has nothing to do at all with the x graphics system or whatever.
No, but the hardware is still accessed directly from userspace in exactly the same fashion as XFree86 and SVGAlib. I was using X11 as a particular example of the problems with the "get overly broad i/o permissions and then beat on the hardware directly from userspace while ignoring the kernel" approach to hardware support.
(Actually, the next rev of XFree86 likely will do 3d graphics support, so there :P)
---
that reminds me of G.K. Chesterton's "Napoleon of Notting Hill" for some reason (set in 1984; Orwell's book was in part a reaction against it).
As an aside, I think both he, Orwell, and Huxley were mostly right; their predictions aren't quite as exclusive as you might think.
---
That would be *way* cool. I mean if I could just turn on additional computers and share the processor power on all those computers on my network.
I mean, is something like this allready in the works for Linux?
Check out MOSIX (in particular, MO6): http://www.cs.huji.ac.il/mosix/
---
> Excellent credentials for spotting invented
> histories, eh? "It takes one to know one", and
> all that.
... hrm?
---
> Err, you definitely need root permission to use /dev/modem is a device under /dev/modem :))
> pppd. Obvious since
> unix and hence by default not all users should
> be allowed to use pppd. (Well unless
> is 777
That's why you use Unix groups... although most people don't for some stupid reason.
---
There was a /. article a while back about his PhD being bogus, if I remember correctly. Hit the archives to confirm.
---
I'd say that it's premature to be writing off Mozilla at this point. They're still making noticable progress, and I've been keeping a relatively close eye on the project; a lot of the developers are still Netscape engineers, but there have been and continue to be some very important contributions by outsiders. Moreover, even with the revised milestones, we're still looking good for December.
The key here is to get a more or less stable, usable product out. Most causual hackers are going to want something that they can add on to incrementally, and having to engage in massive debugging gets in the way of that. I think that's one of the things that's turned off a lot of potential developers.
Unfortunately, because of the size of the product, it's not really that easy to pick a subset of the functionality, clean that up and release it. Given the product, I'm really not sure that they have much choice but to try and make it spring from the head of Zeus fully formed.
One of the major delaying factors, too, was that the realization that the thing needed more or less rewriting from scratch came so late in the game. It wasn't that long ago that they were still trying to kluge around the Mozilla Classic tree.
In fact, I think the existing codebase is going to be an issue in a lot of cases where a propreitary package is open-sourced.
With some notable exceptions (i.e. massive, mission-critical efforts like Oracle or IBM's database products), closed-source software as a whole tends to be extremely poorly engineered in comparison to most of the open-sourced software I've seen, no matter whether it's written by Mentor Graphics or Netscape or Microsoft or some 14-year-old kid writing shareware. These monolithic kluges are not only badly engineered, they make it extremely difficult for "casual developers" to get involved if the source is ever opened. Open Source development thrives on lightweight, modular designs.
So, more often than not, the new core developers end up with the old codebase dangling from their collective neck like a bloody albatross. It's happened to the Mozilla people, and it's happened to me...
Enter MegaZeux, a considerably more advanced clone of Epic Megagames' first product, ZZT. The original author abandoned it about '95 or '96, and being somewhat of a fan of the software, I campeigned for it to be released under the GPL. I finally got my wish.
I and a handfull of other people spent the next eight months (or perhaps even a little longer than that) trying to coerce the old DOS codebase into something cleaner and more portable (even for DOS; it was beginning to suffer majorly from realmode limitations, and we wanted a 32-bit protected mode port). The code still gives me nightmares. I finally gave up on it late this April.
So, now I'm rewriting the thing from scratch. (I suppose I should point out that the release of the original source wasn't a total waste, as it's not only been an invaluable reference for me, some of the other members of the development team have been adding minor features to the original codebase, which still builds only in Turbo C++)
I guess what I'm trying to say is that it's probably unrealistic to expect newly released proprietary source to be useful for anything beyond reference and scaffolding.
If the codebase actually proves usable, that's great, but I don't think we should launch into these things with the expectation that we won't have to rewrite it all anyway. I think that expectation has been the cause of much of the dissillusionment surrounding Mozilla.
[ n.b. Mozilla has other problems too, ranging from poor management to funky licencing; I just don't think they're as major as most people seem to think ]
that's my $0.02.
P.S. If anyone reading this is interested in the sort of retro-gaming stuff like MegaZeux for Linux (the primary target platform of my rewrite), drop me a line after appropriately de-spamming my email. Or drop by http://www.zeux.org/mzx/ if you're just idly curious about the whole thing.
---