The original plan was, in fact, to open-source a slightly sanitized (non-Netscape and non-exportable code removed) Communicator.
That was done, and the Mozilla folks spent a couple years with it before deciding the codebase was complete crap and rewrote the thing from the ground up, producing the Mozilla we know and love today.
You can still see the original "sanitized" Communicator tree in the "Mozilla Classic" CVS branch.
Wanna place a bet on when the first major Open Source security fuckup will happen?
Too late, sendmail's been the poster child for hideously insecure Open Source software for years. Granted, in maybe the past two, it's improved dramatically in that regard.
Spare me the groupthink. You're forgetting that roads are for pedestrians, cyclists, animals, farm equipment, and damn near anything that needs to get from point A to point B, at whatever speed it can muster.
This is not universally true. Consider limited-access highways, which are the primary use for these devices anyway.
I believe in this case what they are referring to is the ability to run the same binary on various Unix OSes (including Linux) on the same hadrware platform.
For instance, PA-RISC Linux and HP-UX would be binary-compatible, as would SunOS (on SPARC) be with SparcLinux. This would require some amount of work, but it is not wholly infeasible.
I don't believe they mean that you would be able to run the same binary on, say... ia32 Linux, Tru64 on Alpha, and MacOS X on PPC.
At least in lynx keybindings mode, you can use < and > to scroll left and right, respectively. I forget what the "w3m native" binding has for that. Also moving the cursor around off one edge or the other will also scroll.
I'll admit, sometimes it's hard to endure a short-term inconvenience (it's going to be a little while before people stop using NS 4.x and stop complaining about how much your page sucks) for a long-term benefit. I certainly thing decent CSS support is worth biting the bullet for, though.
Suprisingly it is pretty small. The packed-up nightly builds which include all of the.sos for browser (with debugging symbols!), mail, news, etc, plus a lot of images, scripts, and demo pages, are about a 5MB download. Do a non-debug build, omit the mailnews libraries (leaving just the browser and some other stuf), and leave out all the demo images/html, and I think you're left with something pretty embeddable.
In general, I agree with your very perceptive assessment (somebody moderate his comment up, please), but I confess that as a Capitalist and Linux goon, I'm a little confused by the last bit:
On another note, I find it laughable how the linux goons are trying their damnedest to cash in. I guess communists would abandon their ideals for a wad of cash given the chance.
I'll admit I don't like Socialism or Communism very much, but I don't think characterizing "linux goons" as communists (and by extension, Free Software as being inherently communistic) is very fair or accurate. Many of us are capitalists who have ethical concerns about taking unfair advantage of situations of universal zero marginal cost.
... I don't care how trendy Linux is, this market cap is just downright insane...
I sincerely hope people don't get burned by this...
Writing C programs in ASM...
on
V2 OS
·
· Score: 1
How hard would it be to write a million line C program in asm ?
Axiomatically, it's impossible. A million-line C program would have to be written in C, just as a million-line asm program would need to be written in asm.
... or did you mean write an asm program that is the functional equivalent of a million-line C program? *grin*
I don't consider alpha code enterprise-ready, no matter how stable it is. fwiw, 2.0 (the stable branch) does have some limited PDC functionality too, but it's not that complete.
As someone who is responsible for supporting Samba deployments in a Fortune 500 company, I feel somewhat qualified to speak to the issue of "enterprise readiness".
Samba seems to have a real problem with encrypted passwords. They say that they HAVE to be used in some configs and CAN'T be used in others.
This is an unfortunate consequence of the laws of mathematics. Both NT and Unix use irreversible hash algorithms to "encrypt" passwords, but they use different ones. There is simply no way to "convert" an NT password hash into a UNIX password hash, or vice-versa. I'm sorry, but not even Microsoft can produce code that can bypass the laws of mathematics (although some days non-deterministic behavior has you wondering...)
In practice, this is not a serious limitation. At work, the Samba servers are members of a resource domain and authenticate against NT PDCs. It's also possible to replace them with Samba PDCs -- if you don't insist on using UNIX-hashed passwords for Samba authentication, encrypted passwords will work fine. Samba's emerging LDAP functionality also raises the possiblity of directly sharing account databases between the NT and Unix sides.
If you insist on using a Unix-style password database for Samba authentication, then you will not be able to use encrypted passwords on the wire. That is, however, the only limitation. All other configurations can use encrypted passwords.
The only circumstances under which you cannot use plaintext passwords are when dealing with Win98 or NT4SP3+, and that's Microsoft's doing, as they disabled negotation of plaintext passwords.
Why is it MS products can connect to anything but Samba has problems.
For values of "anything" that equal MS products?
Samba also has real problems with oplocks.
The only real limitation on oplocks in Samba deals with situations where you can have both Unix and NT users accessing the data simultaneously, if the particular Unix flavor does not itself support oplocks. Under those circumstances, you'll need to turn oplocks off to avoid potential data corruption.
Note that this is due to an architectural limitation of certain Unix flavors, not of Samba itself. On Unices that support oplocks (i.e. IRIX), oplocks are safe because Samba uses the OS's native oplock facilities.
They need to fix it before it is enterprise ready.
I'd say it's enterprise-ready now, for pretty much everything but PDC/BDC functionality. Stop with the FUD.
... Intel [which] is on the cusp of bringing out Merced, which, combined with RAMBUS technology, sponsored by Intel, represents a virtual processor revolution?
You should be aware that most of the technologies used in the Merced architecture (which you should be aware is now called "Itanium") were previously pioneered in architectures like PA-RISC. 64-bit architectures in general have been around for a long time, too. RAMBUS was developed outside of Intel by Rambus Incorporated.
Intel is bringing these technologies to the desktop market, which is not a bad thing, but there are no recent indications of any special ability to innovate, as none of these technologies originated with Intel.
The only reason AMD has currently stuck with implementing ia32 clones has been that they have not been in a secure enough situation to do much else (although, they have made some interesting technological advances even in implementing their clones). If they manage to gain a reasonably comfortable position in the market, they will finally be able to take the same kinds of risks.
Based on past performance (cheaper processors, better designs, less bastardly behavior, less bungling), I would much rather have a financially secure AMD in the role of introducing newer technology to the desktop market, rather than Intel. That is why I (and I suspect many other slashdot readers) choose to support AMD.
I think the Linux community has a tendency to favor the underdog, regardless of facts or the situation...
I'm sorry if this sounds harsh, but I think some critics (read: you) of the "Linux community" (read: slashdot posters) have a tendency to blindly take Intel PR material at face value, regardless of the facts of the situation.
so they take legal action currently available to at least make sure the software they contribute to cannot be owned.
Not quite. What they do is provide a legal model that software authors (starting with themselves) can use to enforce something like "Rather than abusing my 'ownership' of this code, I am allowing you to have it, too, as long as you are willing to do the same for others."
The real problem comes from both sides of the aisle.
I'm quite sure the encryption opponents are quite relieved that anyone who might otherwise oppose them is too busy blaming whatever group he or she is not a part of, be it the Democrats or the Republicans, the Liberals or the Conservatives.
If you give the source away, you give the program away.
Indeed.
Now, if you mean to imply that as soon as a copy of source "escapes", the market goes away because everyone can get a copy at more or less zero cost, then that's just wrong.
If their market had dried up as soon as gratis copies were circulating, RedHat would only have been able to sell at most one copy of their distribution.
Giving away software doesn't mean that your market dissapears.
I can say to you that I will sell you a spot on Mars, but if (someday) you could go to that little spot that I said you own and you find little green men living there, it is no longer thiers?
More or less. At least, that's the way it worked when we screwed over the American Indians.
I would like to sell people little glass vacuum spheres. Then you can say you own nothing, and it is something!
In all seriousness, that's not a bad idea for a novelty gift.
Slashdot Mirror
The original plan was, in fact, to open-source a slightly sanitized (non-Netscape and non-exportable code removed) Communicator.
That was done, and the Mozilla folks spent a couple years with it before deciding the codebase was complete crap and rewrote the thing from the ground up, producing the Mozilla we know and love today.
You can still see the original "sanitized" Communicator tree in the "Mozilla Classic" CVS branch.
Wanna place a bet on when the first major Open Source security fuckup will happen?
Too late, sendmail's been the poster child for hideously insecure Open Source software for years. Granted, in maybe the past two, it's improved dramatically in that regard.
Spare me the groupthink. You're forgetting that roads are for pedestrians, cyclists, animals, farm equipment, and damn near anything that needs to get from point A to point B, at whatever speed it can muster.
This is not universally true. Consider limited-access highways, which are the primary use for these devices anyway.
I believe in this case what they are referring to is the ability to run the same binary on various Unix OSes (including Linux) on the same hadrware platform.
For instance, PA-RISC Linux and HP-UX would be binary-compatible, as would SunOS (on SPARC) be with SparcLinux. This would require some amount of work, but it is not wholly infeasible.
I don't believe they mean that you would be able to run the same binary on, say... ia32 Linux, Tru64 on Alpha, and MacOS X on PPC.
At least in lynx keybindings mode, you can use < and > to scroll left and right, respectively. I forget what the "w3m native" binding has for that. Also moving the cursor around off one edge or the other will also scroll.
> So what happens when AOL/Netscape decide to
> take mozilla and roll it into a big happy
> Netscape 5?
Not that much; Mozilla will still continue to exist/be developed in its own right (AOL couldn't stop it if they wanted to).
I'll admit, sometimes it's hard to endure a short-term inconvenience (it's going to be a little while before people stop using NS 4.x and stop complaining about how much your page sucks) for a long-term benefit. I certainly thing decent CSS support is worth biting the bullet for, though.
Suprisingly it is pretty small. The packed-up nightly builds which include all of the .sos for browser (with debugging symbols!), mail, news, etc, plus a lot of images, scripts, and demo pages, are about a 5MB download. Do a non-debug build, omit the mailnews libraries (leaving just the browser and some other stuf), and leave out all the demo images/html, and I think you're left with something pretty embeddable.
I believe there are now multiple servers.
In general, I agree with your very perceptive assessment (somebody moderate his comment up, please), but I confess that as a Capitalist and Linux goon, I'm a little confused by the last bit:
On another note, I find it laughable how the linux goons are trying their damnedest to cash in. I guess communists would abandon their ideals for a wad of cash given the chance.
I'll admit I don't like Socialism or Communism very much, but I don't think characterizing "linux goons" as communists (and by extension, Free Software as being inherently communistic) is very fair or accurate. Many of us are capitalists who have ethical concerns about taking unfair advantage of situations of universal zero marginal cost.
... I don't care how trendy Linux is, this market cap is just downright insane...
I sincerely hope people don't get burned by this...
... I don't care how trendy Linux is, this market cap is just downright insane...
I sincerely hope people don't get burned by this...
How hard would it be to write a million line C program in asm ?
Axiomatically, it's impossible. A million-line C program would have to be written in C, just as a million-line asm program would need to be written in asm.
... or did you mean write an asm program that is the functional equivalent of a million-line C program? *grin*
I don't consider alpha code enterprise-ready, no matter how stable it is. fwiw, 2.0 (the stable branch) does have some limited PDC functionality too, but it's not that complete.
As someone who is responsible for supporting Samba deployments in a Fortune 500 company, I feel somewhat qualified to speak to the issue of "enterprise readiness".
Samba seems to have a real problem with encrypted passwords. They say that they HAVE to be used in some configs and CAN'T be used in others.
This is an unfortunate consequence of the laws of mathematics. Both NT and Unix use irreversible hash algorithms to "encrypt" passwords, but they use different ones. There is simply no way to "convert" an NT password hash into a UNIX password hash, or vice-versa. I'm sorry, but not even Microsoft can produce code that can bypass the laws of mathematics (although some days non-deterministic behavior has you wondering...)
In practice, this is not a serious limitation. At work, the Samba servers are members of a resource domain and authenticate against NT PDCs. It's also possible to replace them with Samba PDCs -- if you don't insist on using UNIX-hashed passwords for Samba authentication, encrypted passwords will work fine. Samba's emerging LDAP functionality also raises the possiblity of directly sharing account databases between the NT and Unix sides.
If you insist on using a Unix-style password database for Samba authentication, then you will not be able to use encrypted passwords on the wire. That is, however, the only limitation. All other configurations can use encrypted passwords.
The only circumstances under which you cannot use plaintext passwords are when dealing with Win98 or NT4SP3+, and that's Microsoft's doing, as they disabled negotation of plaintext passwords.
Why is it MS products can connect to anything but Samba has problems.
For values of "anything" that equal MS products?
Samba also has real problems with oplocks.
The only real limitation on oplocks in Samba deals with situations where you can have both Unix and NT users accessing the data simultaneously, if the particular Unix flavor does not itself support oplocks. Under those circumstances, you'll need to turn oplocks off to avoid potential data corruption.
Note that this is due to an architectural limitation of certain Unix flavors, not of Samba itself. On Unices that support oplocks (i.e. IRIX), oplocks are safe because Samba uses the OS's native oplock facilities.
They need to fix it before it is enterprise ready.
I'd say it's enterprise-ready now, for pretty much everything but PDC/BDC functionality. Stop with the FUD.
Pick any two.
You should be aware that most of the technologies used in the Merced architecture (which you should be aware is now called "Itanium") were previously pioneered in architectures like PA-RISC. 64-bit architectures in general have been around for a long time, too. RAMBUS was developed outside of Intel by Rambus Incorporated.
Intel is bringing these technologies to the desktop market, which is not a bad thing, but there are no recent indications of any special ability to innovate, as none of these technologies originated with Intel.
The only reason AMD has currently stuck with implementing ia32 clones has been that they have not been in a secure enough situation to do much else (although, they have made some interesting technological advances even in implementing their clones). If they manage to gain a reasonably comfortable position in the market, they will finally be able to take the same kinds of risks.
Based on past performance (cheaper processors, better designs, less bastardly behavior, less bungling), I would much rather have a financially secure AMD in the role of introducing newer technology to the desktop market, rather than Intel. That is why I (and I suspect many other slashdot readers) choose to support AMD.
I think the Linux community has a tendency to favor the underdog, regardless of facts or the situation...
I'm sorry if this sounds harsh, but I think some critics (read: you) of the "Linux community" (read: slashdot posters) have a tendency to blindly take Intel PR material at face value, regardless of the facts of the situation.
so they take legal action currently available to at least make sure the software they contribute to cannot be owned.
Not quite. What they do is provide a legal model that software authors (starting with themselves) can use to enforce something like "Rather than abusing my 'ownership' of this code, I am allowing you to have it, too, as long as you are willing to do the same for others."
Berlin-- http://www.berlin-consortium.org
The real problem comes from both sides of the aisle.
I'm quite sure the encryption opponents are quite relieved that anyone who might otherwise oppose them is too busy blaming whatever group he or she is not a part of, be it the Democrats or the Republicans, the Liberals or the Conservatives.
Berlin-- http://www.berlin-consortium.org
I was unaware that Bill Clinton and Al Gore were Republicans. Thanks for enlightening me.
Berlin-- http://www.berlin-consortium.org
(define (recurse for-whom) ((recurse for-whom)))
(recurse "dummies")
Berlin-- http://www.berlin-consortium.org
If you give the source away, you give the program away.
Indeed.
Now, if you mean to imply that as soon as a copy of source "escapes", the market goes away because everyone can get a copy at more or less zero cost, then that's just wrong.
If their market had dried up as soon as gratis copies were circulating, RedHat would only have been able to sell at most one copy of their distribution.
Giving away software doesn't mean that your market dissapears.
Berlin-- http://www.berlin-consortium.org
I can say to you that I will sell you a spot on Mars, but if (someday) you could go to that little spot that I said you own and you find little green men living there, it is no longer thiers?
More or less. At least, that's the way it worked when we screwed over the American Indians.
I would like to sell people little glass vacuum spheres. Then you can say you own nothing, and it is something!
In all seriousness, that's not a bad idea for a novelty gift.
Berlin-- http://www.berlin-consortium.org
After all, if you went there and declared autonomy, who would come stop you?
Lack of food, fuel, and oxygen.
Berlin-- http://www.berlin-consortium.org
FWIW, the more "canonical" approach to #5 would be:
static int mult(int x, int r) {
return ( r > 1 ) : x + mult(x, r - 1) : x;
}
int sxp1(int x) {
return _sxp1(x, x) + 1;
}
Okay, okay, I'll stop now...
Berlin-- http://www.berlin-consortium.org