And thereby drive down costs of software, for the good of all? That's a valid economic choice.
I would not keep this in if I were editing it now. Your reaction was probably that 'for the good of all' is not an economic motivation. I'd agree with that, though that's how it tends to work out over the big picture. That's due to supply and demand, though.
But even the highest end, most complex software is absurdly cheap on a marginal basis.
Also obviously not true. But if we focus our discussion on broadly useful, commodity software, this is not such a strange thing to say. If Linux has 100 million CPU's running, then each of those 100 million CPU's represent a relatively low marginal cost.
The rest of the points I think hold up pretty well. It's appropriate for people to choose to use commercial software where commercial software is better than open source software, and where the fear of proprietary lock-in is not too constraining. But it's also appropriate for open source to be there as an option if the adopter is technically savvy enough, or if the software is enough of a commodity that operating it is reasonable in the absence of commercial levels of documentation, user interface refinements, and marketing.
As a consumer of software, I need marketing to reassure me that a product is functional and reliable. Or.. I could go online and read the word-of-mouth testimony of hundreds or thousands of people who may have used the product. In that regime, marketing may not be such a competitive advantage as it would be if it had a greater exclusivity on message transmission.
Anyway. It's all economics, otherwise it wouldn't be happening. Relax.
The GPL is an instrument expressly designed to lower programmer's incomes.
And thereby drive down costs of software, for the good of all? That's a valid economic choice.
Yes, large-scale software can be expensive to create. But even the highest end, most complex software is absurdly cheap on a marginal basis. Given that, and given that Microsoft has been obtaining outlandishly high monopoly rents on software for years, it's only to be expected that there be a market reaction to that. If that is Sun putting out Open Office to protect their hardware sales, or HP or IBM supporting Linux to prospectively protect themselves from being parasitized by Microsoft's very high share on PC profits, that's an economically justifiable market reaction.
You can't talk economics without talking supply and demand. If you've got a large supply of programmers of varying education levels who can cheaply collaborate to produce broadly useful software and you've got a lot of people who need custom solutions for their businesses, then the market says that common software should be cheap and the custom solutions should be expensive.
After all, the GPL does nothing significant to lower the salary of programmers working on custom IT projects for businesses of all sizes. It improves the quality and lowers the cost when a large organ bank exists that can be adopted for custom implementation.. this helps to improve the programmer's productivity for that business, which helps support his salary.
If you're disappointed because it's hard to sell commodity software, then I empathize. I empathized with Netscape when their software was commoditized and bundled with a monopolist's product. I empathize with programmers whose jobs are being cut back due to cheaper programmers in India.
But it's all supply and demand, it's all rational economics.
People are going to write software no matter what you do.. universities, businesses, bake sales.. lots of people need a bit of software to help them do something or other. The GPL allows them to release that software for the public good without enabling that software to be appropriated for commercial, proprietary sale. It makes it possible for some folks to release software publically for others to use when they would not have been able to otherwise.
The GPL DISincentivizes software development? There sure is one hell of a lot of code in Linux that needs explanation then, sir. And in FreeBSD, and in OpenBSD as well, if you care to look at gcc, gdb, emacs, and on and on.
Why would they be talking about killing the F-22? Isn't it already in deployment? With cost-accounting practices, all of the investment into the F-22 is sunk if you scale back the buys.
I guess I've just watched one two many Wings programs extolling the world's best fighter.
One thing Arch doesn't do, however, is import old repositories from CVS. Though some of the Subversion team's ideological purities bother me (why can't I have per-file revision counts?), I can at least convert my old CVS repository to Subversion without losing my revision history.
True. It's also true that Fedora is driving SELinux into their product, and I know the Snare guys are working on integrating syscall-level auditing into Linux.
The security options for Linux will continue to get better, the only question is whether that will dominate over the increasing number of naive Linux users.
Besides, you're SEVERELY underestimating the amount of BSD servers in use.
Is he? How do you know? The data isn't there, just as the data wasn't there in the study. Without that data, the study can tell you nothing about the inherent security of the systems at issue.
It's interesting that something that was always used to "prove" Linux's security--its wide usage in the face of apparently low breach rates--is suddenly being used now to JUSTIFY those breaches, which have turned how to be a very high number.
I don't think anyone here is JUSTIFYING those breaches. I think that we're just questioning the results of a study that doesn't bother to provide statistically informative data.
Your opinion, sure. Lots of us penguinistas are as clueful as the users of any other Unix-type distribution.
OpenBSD has some nice security bits, but that high level of security touted on the OpenBSD site is only for bundled software. If you install any significant services, the security questions are the same on OpenBSD as they are for Linux or the other BSD's. RedHat uses the same vsftpd and sshd that OpenBSD uses.
Linux vendors are concerned about security (well, maybe not the Lindows guys.. brrr), and so are we professional Linux users.
It's the non-professional Linux users that would be the problem, I suppose, and yes, there are an increasing number of them. But to diss Linux and push OS X isn't particularly relevant in a security discussion, I don't think.
Since IBM had already gone ahead and distributed the derived code in such a way that significantly harmed the copyright owner of the original code, SCO is absolutely within its rights to sue for damages as well as removal of the offending code from the infringing codebase.
Only if RCU or JFS are derived works. JFS was originally developed under OS/2, it's extremely difficult to imagine how it could be considered a derived work of SYSV. RCU was developed in the context of a UNIX system (dynix), but the likelihood that Linux is similar enough to the AT&T-specific code that originally hosted RCU to make it easy or possible to carry along AT&T derivations also seems slim. RCU is a patented IBM algorithm, not a specific bit of copyrighted AT&T derived code.
Sure, if SCO is correct in their theory of derived works, then they'd have a case. But there hasn't been any plausible presentation that they are correct in their theory.
If the GPL author can demand that an entire codebase be opened upon the inclusion of even a small amount of GPL'd code, then SCO is well within their rights to demand the same in their licenses and expect the same adherence from the licensee.
Nonsense. The GPL is an affirmative grant of expanded copyright privileges. If I create some code and incorporate some GPL'ed stuff into it, it is not the case that my code is suddenly tainted and becomes GPL'ed. It's just that if I distribute the combined work under terms incompatible with the GPL, I am illegally distributing that (GPL'ed) portion of the combined work whose copyright does not belong to me. GPL'ing my own software is NOT mandatory.. neither the FSF nor Linus Torvalds, no anyone else has the right to force me to GPL my code. But they can stop me from distributing _their_ code.. and if my code is totally useless without that GPL'ed software, well, too bad.
The AT&T contract that SCO is basing their entire case on (although they've been screaming bloody murder to distract people from this fact in the press) states that derived works shall be treated in similar fashion to AT&T's unmodified works for the purposes of the IBM/Sequent/SGI contracts. That is, you can't modify AT&T's code and then give it away.
That says nothing about RCU or JFS or XFS, which are original code created by IBM and SGI, respectively. That code is not derivative of AT&T's code merely because it was commingled into AIX and IRIX. AT&T/Novell/SCO/Caldera/SCOX did not have anything to do with the creation of RCU, JFS, or XFS. SCO is making a very persuasive case that RCU, JFS, and XFS were contributed to Linux by IBM and SGI, here. And that's great. But they haven't shown in the slightest degree that, against all common sense or case law, IBM and SGI's original works become 'derivative' of AT&T's code because they were at one point commingled into a product that contained AT&T code.
The GPL doesn't work that way. The AT&T license didn't work that way, judging from AT&T's own comments in the 1985 $echo newsletter cited at GROKLAW. And you know what? Copyright doesn't work that way, either.
What's wrong with that? You are still allowed to modify and redistribute the code to your heart's content, as long as you acknowledge the original authors. Wouldn't you want your work acknowledged?
The problem is not that those terms are onerous in and of themselves. The problem is that those terms are seemingly incompatible with the GPL, in particular the GPL's requirements that a redistributor of GPL'ed material is not allowed to place additional restrictions on redistribution.
Given that there is a vast amount of GPL'ed software that is linked against X libraries, this would, on the face of it, make it impossible to distribute that GPL'ed software in compliance with both the new XFree86 and GPL licenses. At least, if the GPL'ed software was considered in some way derivative of the XFree86 licensed software.
I'm sure all of this will get sorted out, but people are right to be raising the question right now.
Actually, in case you hadn't noticed, these are the Glory Days of X, man. I don't consider that era when you had to worry about 8 bit color palette collisions to be anything like a time of glory.
TrueColor displays, KDE, Gnome, XRender, Xft.. these are some of the ingredients of a glorious new age for X.
Happily, Keith and Jim are still involved.
That's still kind of gross, though. Particularly when you may have a significant variety of OS, library, and distro revisions to worry over.
Has the SWT community provided a standard set of templates and resources to make it easy to do this? If I could download a tar file or GUI library shared objects for a wide variety of operating systems, along with the appropriate browser detection code to provide the shared libraries, that might make it seem a bit more tractable.
Of course, it would be even better if the JNLP protocol and launcher could do this.. I'd hate to pass somebody some useless DLLs just because their copy of Mozilla Firebird for Linux is set to emulate the IE/Windows user agent string.
However, people who oppose "security through obscurity", especially when in conjunction with blind open source advocacy, would argue that giving would-be intruders the blueprints of the door system would somehow deter them and make the system more secure.
So how do you distinguish 'blind' open source advocacy from any other sort?
In cryptographics, the security of the system comes down to the mathematics and the implementation thereof in a practical system. If open source makes it more likely that someone with a brain will notice an insecure facet and be motivated to fix it for their own benefit, in addition to the common good, then open source has proven a virtue for the system's security.
If open source just means that bad guys can see what you're doing (in a given installation of particular interest, for instance) and you're not getting the benefit of peer review and shared technical progress then you should probably ask yourself why your project hasn't gathered a productive community around it.
The community that grows up around successful open source projects is more important than the quality of the code, in many respects, after all.
My app gets downloaded every day to run on a wide variety of systems. I know that SWT is supposed to be compatible with Java Web Start, but I don't understand how you can make a JNLP launch package that includes the shared objects/dll's for all of the permutations of Windows, Linux, Macintosh, Solaris, OS/2...
I'd love to have a higher speed GUI, and I like the idea of a high quality native look and feel (so long as the native look and feel isn't Motif, ugh. Guess I need to make sure those Solaris systems have GTK, huh?), but the advantages of guaranteed ubiquity on the Java platform leave Swing my choice for the time being.
those of us who need filesystems other than ext2/3 just grab the other source tarball and extract it into/usr/src/modules/'subsystem'.
That's a testing nightmare, given how fast the kernel evolves. If there's a kernel config option in the standard kernel, the odds are that configuration of the module code will be used and tested with that version of the kernel. If there are any mismatches, incompatibilities, or other bugs, there'll be a chance of someone finding and reporting it, since there's a known configuration for test.
Interesting that CA is pushing for inclusion of a kernel auditing facility in 2.7. That sort of functionality, required in a number of federal contexts, is already available in a Linux-compatible, GPL'ed code base, from Intersect Alliance down in Australia. The Snare project patches the Linux kernel with auditing instrumentation, making it possible to detect abnormal system call activity that other methods don't.
Solaris has had something like this for a long time in the form of BSM, as had Windows. Even Mac OS X has preliminary BSM support in Mac OS X Panther. It would be very great to see this kind of functionality as a config option on the Linux kernel, and hopefully sooner rather than later.
Yeah, we discussed doing exactly that here several years ago, for those users whose systems didn't have their MAC addresses properly registered in our systems database.
If only I had realized we had a non-obvious, patentable idea that we could claim over everyone in the country, we'd be rich.
Yeah, I saw that too. Anyone who thinks that BSD didn't grow organically in a similar fashion is a bit of a BSD-optimist, I think.
Perhaps what he means is that BSD hasn't grown as fast or as floridly as Linux has. That's fine. But let's not pretend that BSD (which started as a hack on AT&T Unix) sprang fully formed from the brow of a more elite cadre of uber-hackers than Linux has, please.
What's wrong with the mathematically appropriate GCD in that context?
And the 'least value of the things being factored' is 1, again.
It really doesn't make sense. It's just another antinomal drift in meaning, like the phrase 'i could care less' for 'i couldn't care less'. It's precisely wrong.
<rant>Greatest common denominator, please. Least common denominator is a corruption of the english language. In mathematics, the least/lowest common denominator is always identity, or 1. That is, with any given samples, the lowest common denominator doesn't tell you anything at all. But if you have 33, 22, and 55, the greatest common denominator is 11, which does indeed tell you something.
Lowest common denominator is a conflation of greatest common denominator and lowest common multiple. The fact that it connotates a low value rather than a 'great' value makes it a popular usage, but it's dead wrong.</rant>
Python may be more productive than Java for some programmers.. I don't know, I've not done enough Python (more than a few thousand lines) to be able to judge properly for myself. But I do know that my increase in productivity in moving to Java was closer to 10 times than it was to 0.3 to 0.4 times.
I've written hundreds of thousands of lines of Java code without needing or wanting to use a debugger more than a handful of times. That's radically different from C and C++. When you add in the memory protection, solid encapsulation, threads and thread safe libraries, integrated exception handling, extensive class libraries.. the jump from C++ is really quite large.
My (relatively uninformed) intuition is that the jump to Python isn't as large an improvement, but that's more about how really wretched C++ is, not about how ungood Python is.
I absolutely loved it. I wish we could have heard more of the old theme song, as that was always one of the very best bits of the old series.
I hope like hell that it becomes a series and that they keep the writing team. I also hope that they write out an arc ahead of time and tell a single cohesive story. Not like Voyager where there's one big goal set up, and if the characters ever achieved the goal, boom, end of story. The Gilligan's Island phenomena must be avoided at all costs, but if they can do that, kick ass.
Also, it was great hearing 'frack' on TV again. I loved that bit in the original series back in the day.
Slashdot Mirror
Sigh, I wish I could edit my posts.
And thereby drive down costs of software, for the good of all? That's a valid economic choice.
I would not keep this in if I were editing it now. Your reaction was probably that 'for the good of all' is not an economic motivation. I'd agree with that, though that's how it tends to work out over the big picture. That's due to supply and demand, though.
But even the highest end, most complex software is absurdly cheap on a marginal basis.
Also obviously not true. But if we focus our discussion on broadly useful, commodity software, this is not such a strange thing to say. If Linux has 100 million CPU's running, then each of those 100 million CPU's represent a relatively low marginal cost.
The rest of the points I think hold up pretty well. It's appropriate for people to choose to use commercial software where commercial software is better than open source software, and where the fear of proprietary lock-in is not too constraining. But it's also appropriate for open source to be there as an option if the adopter is technically savvy enough, or if the software is enough of a commodity that operating it is reasonable in the absence of commercial levels of documentation, user interface refinements, and marketing.
As a consumer of software, I need marketing to reassure me that a product is functional and reliable. Or.. I could go online and read the word-of-mouth testimony of hundreds or thousands of people who may have used the product. In that regime, marketing may not be such a competitive advantage as it would be if it had a greater exclusivity on message transmission.
Anyway. It's all economics, otherwise it wouldn't be happening. Relax.
The GPL is an instrument expressly designed to lower programmer's incomes.
And thereby drive down costs of software, for the good of all? That's a valid economic choice.
Yes, large-scale software can be expensive to create. But even the highest end, most complex software is absurdly cheap on a marginal basis. Given that, and given that Microsoft has been obtaining outlandishly high monopoly rents on software for years, it's only to be expected that there be a market reaction to that. If that is Sun putting out Open Office to protect their hardware sales, or HP or IBM supporting Linux to prospectively protect themselves from being parasitized by Microsoft's very high share on PC profits, that's an economically justifiable market reaction.
You can't talk economics without talking supply and demand. If you've got a large supply of programmers of varying education levels who can cheaply collaborate to produce broadly useful software and you've got a lot of people who need custom solutions for their businesses, then the market says that common software should be cheap and the custom solutions should be expensive.
After all, the GPL does nothing significant to lower the salary of programmers working on custom IT projects for businesses of all sizes. It improves the quality and lowers the cost when a large organ bank exists that can be adopted for custom implementation.. this helps to improve the programmer's productivity for that business, which helps support his salary.
If you're disappointed because it's hard to sell commodity software, then I empathize. I empathized with Netscape when their software was commoditized and bundled with a monopolist's product. I empathize with programmers whose jobs are being cut back due to cheaper programmers in India.
But it's all supply and demand, it's all rational economics.
Go read your copy of The Magic Cauldron, man.
People are going to write software no matter what you do.. universities, businesses, bake sales.. lots of people need a bit of software to help them do something or other. The GPL allows them to release that software for the public good without enabling that software to be appropriated for commercial, proprietary sale. It makes it possible for some folks to release software publically for others to use when they would not have been able to otherwise.
The GPL DISincentivizes software development? There sure is one hell of a lot of code in Linux that needs explanation then, sir. And in FreeBSD, and in OpenBSD as well, if you care to look at gcc, gdb, emacs, and on and on.
Why would they be talking about killing the F-22? Isn't it already in deployment? With cost-accounting practices, all of the investment into the F-22 is sunk if you scale back the buys.
I guess I've just watched one two many Wings programs extolling the world's best fighter.
One thing Arch doesn't do, however, is import old repositories from CVS. Though some of the Subversion team's ideological purities bother me (why can't I have per-file revision counts?), I can at least convert my old CVS repository to Subversion without losing my revision history.
True. It's also true that Fedora is driving SELinux into their product, and I know the Snare guys are working on integrating syscall-level auditing into Linux.
The security options for Linux will continue to get better, the only question is whether that will dominate over the increasing number of naive Linux users.
Besides, you're SEVERELY underestimating the amount of BSD servers in use.
Is he? How do you know? The data isn't there, just as the data wasn't there in the study. Without that data, the study can tell you nothing about the inherent security of the systems at issue.
It's interesting that something that was always used to "prove" Linux's security--its wide usage in the face of apparently low breach rates--is suddenly being used now to JUSTIFY those breaches, which have turned how to be a very high number.
I don't think anyone here is JUSTIFYING those breaches. I think that we're just questioning the results of a study that doesn't bother to provide statistically informative data.
Your opinion, sure. Lots of us penguinistas are as clueful as the users of any other Unix-type distribution.
OpenBSD has some nice security bits, but that high level of security touted on the OpenBSD site is only for bundled software. If you install any significant services, the security questions are the same on OpenBSD as they are for Linux or the other BSD's. RedHat uses the same vsftpd and sshd that OpenBSD uses.
Linux vendors are concerned about security (well, maybe not the Lindows guys.. brrr), and so are we professional Linux users.
It's the non-professional Linux users that would be the problem, I suppose, and yes, there are an increasing number of them. But to diss Linux and push OS X isn't particularly relevant in a security discussion, I don't think.
Since IBM had already gone ahead and distributed the derived code in such a way that significantly harmed the copyright owner of the original code, SCO is absolutely within its rights to sue for damages as well as removal of the offending code from the infringing codebase.
Only if RCU or JFS are derived works. JFS was originally developed under OS/2, it's extremely difficult to imagine how it could be considered a derived work of SYSV. RCU was developed in the context of a UNIX system (dynix), but the likelihood that Linux is similar enough to the AT&T-specific code that originally hosted RCU to make it easy or possible to carry along AT&T derivations also seems slim. RCU is a patented IBM algorithm, not a specific bit of copyrighted AT&T derived code.
Sure, if SCO is correct in their theory of derived works, then they'd have a case. But there hasn't been any plausible presentation that they are correct in their theory.
Seconded.
If the GPL author can demand that an entire codebase be opened upon the inclusion of even a small amount of GPL'd code, then SCO is well within their rights to demand the same in their licenses and expect the same adherence from the licensee.
Nonsense. The GPL is an affirmative grant of expanded copyright privileges. If I create some code and incorporate some GPL'ed stuff into it, it is not the case that my code is suddenly tainted and becomes GPL'ed. It's just that if I distribute the combined work under terms incompatible with the GPL, I am illegally distributing that (GPL'ed) portion of the combined work whose copyright does not belong to me. GPL'ing my own software is NOT mandatory.. neither the FSF nor Linus Torvalds, no anyone else has the right to force me to GPL my code. But they can stop me from distributing _their_ code.. and if my code is totally useless without that GPL'ed software, well, too bad.
The AT&T contract that SCO is basing their entire case on (although they've been screaming bloody murder to distract people from this fact in the press) states that derived works shall be treated in similar fashion to AT&T's unmodified works for the purposes of the IBM/Sequent/SGI contracts. That is, you can't modify AT&T's code and then give it away.
That says nothing about RCU or JFS or XFS, which are original code created by IBM and SGI, respectively. That code is not derivative of AT&T's code merely because it was commingled into AIX and IRIX. AT&T/Novell/SCO/Caldera/SCOX did not have anything to do with the creation of RCU, JFS, or XFS. SCO is making a very persuasive case that RCU, JFS, and XFS were contributed to Linux by IBM and SGI, here. And that's great. But they haven't shown in the slightest degree that, against all common sense or case law, IBM and SGI's original works become 'derivative' of AT&T's code because they were at one point commingled into a product that contained AT&T code.
The GPL doesn't work that way. The AT&T license didn't work that way, judging from AT&T's own comments in the 1985 $echo newsletter cited at GROKLAW. And you know what? Copyright doesn't work that way, either.
IANALTG.
What's wrong with that? You are still allowed to modify and redistribute the code to your heart's content, as long as you acknowledge the original authors. Wouldn't you want your work acknowledged?
The problem is not that those terms are onerous in and of themselves. The problem is that those terms are seemingly incompatible with the GPL, in particular the GPL's requirements that a redistributor of GPL'ed material is not allowed to place additional restrictions on redistribution.
Given that there is a vast amount of GPL'ed software that is linked against X libraries, this would, on the face of it, make it impossible to distribute that GPL'ed software in compliance with both the new XFree86 and GPL licenses. At least, if the GPL'ed software was considered in some way derivative of the XFree86 licensed software.
I'm sure all of this will get sorted out, but people are right to be raising the question right now.
Actually, in case you hadn't noticed, these are the Glory Days of X, man. I don't consider that era when you had to worry about 8 bit color palette collisions to be anything like a time of glory. TrueColor displays, KDE, Gnome, XRender, Xft.. these are some of the ingredients of a glorious new age for X. Happily, Keith and Jim are still involved.
Grandparent links to a proper Linux torrent.
It did, thanks.
That's still kind of gross, though. Particularly when you may have a significant variety of OS, library, and distro revisions to worry over.
Has the SWT community provided a standard set of templates and resources to make it easy to do this? If I could download a tar file or GUI library shared objects for a wide variety of operating systems, along with the appropriate browser detection code to provide the shared libraries, that might make it seem a bit more tractable.
Of course, it would be even better if the JNLP protocol and launcher could do this.. I'd hate to pass somebody some useless DLLs just because their copy of Mozilla Firebird for Linux is set to emulate the IE/Windows user agent string.
However, people who oppose "security through obscurity", especially when in conjunction with blind open source advocacy, would argue that giving would-be intruders the blueprints of the door system would somehow deter them and make the system more secure.
So how do you distinguish 'blind' open source advocacy from any other sort?
In cryptographics, the security of the system comes down to the mathematics and the implementation thereof in a practical system. If open source makes it more likely that someone with a brain will notice an insecure facet and be motivated to fix it for their own benefit, in addition to the common good, then open source has proven a virtue for the system's security.
If open source just means that bad guys can see what you're doing (in a given installation of particular interest, for instance) and you're not getting the benefit of peer review and shared technical progress then you should probably ask yourself why your project hasn't gathered a productive community around it.
The community that grows up around successful open source projects is more important than the quality of the code, in many respects, after all.
My app gets downloaded every day to run on a wide variety of systems. I know that SWT is supposed to be compatible with Java Web Start, but I don't understand how you can make a JNLP launch package that includes the shared objects/dll's for all of the permutations of Windows, Linux, Macintosh, Solaris, OS/2...
I'd love to have a higher speed GUI, and I like the idea of a high quality native look and feel (so long as the native look and feel isn't Motif, ugh. Guess I need to make sure those Solaris systems have GTK, huh?), but the advantages of guaranteed ubiquity on the Java platform leave Swing my choice for the time being.
those of us who need filesystems other than ext2/3 just grab the other source tarball and extract it into /usr/src/modules/'subsystem'.
That's a testing nightmare, given how fast the kernel evolves. If there's a kernel config option in the standard kernel, the odds are that configuration of the module code will be used and tested with that version of the kernel. If there are any mismatches, incompatibilities, or other bugs, there'll be a chance of someone finding and reporting it, since there's a known configuration for test.
Interesting that CA is pushing for inclusion of a kernel auditing facility in 2.7. That sort of functionality, required in a number of federal contexts, is already available in a Linux-compatible, GPL'ed code base, from Intersect Alliance down in Australia. The Snare project patches the Linux kernel with auditing instrumentation, making it possible to detect abnormal system call activity that other methods don't.
Solaris has had something like this for a long time in the form of BSM, as had Windows. Even Mac OS X has preliminary BSM support in Mac OS X Panther. It would be very great to see this kind of functionality as a config option on the Linux kernel, and hopefully sooner rather than later.
Yeah, we discussed doing exactly that here several years ago, for those users whose systems didn't have their MAC addresses properly registered in our systems database.
If only I had realized we had a non-obvious, patentable idea that we could claim over everyone in the country, we'd be rich.
Yeah, I saw that too. Anyone who thinks that BSD didn't grow organically in a similar fashion is a bit of a BSD-optimist, I think.
Perhaps what he means is that BSD hasn't grown as fast or as floridly as Linux has. That's fine. But let's not pretend that BSD (which started as a hack on AT&T Unix) sprang fully formed from the brow of a more elite cadre of uber-hackers than Linux has, please.
What's wrong with the mathematically appropriate GCD in that context?
And the 'least value of the things being factored' is 1, again.
It really doesn't make sense. It's just another antinomal drift in meaning, like the phrase 'i could care less' for 'i couldn't care less'. It's precisely wrong.
<rant>Greatest common denominator, please. Least common denominator is a corruption of the english language. In mathematics, the least/lowest common denominator is always identity, or 1. That is, with any given samples, the lowest common denominator doesn't tell you anything at all. But if you have 33, 22, and 55, the greatest common denominator is 11, which does indeed tell you something.
Lowest common denominator is a conflation of greatest common denominator and lowest common multiple. The fact that it connotates a low value rather than a 'great' value makes it a popular usage, but it's dead wrong.</rant>
Python may be more productive than Java for some programmers.. I don't know, I've not done enough Python (more than a few thousand lines) to be able to judge properly for myself. But I do know that my increase in productivity in moving to Java was closer to 10 times than it was to 0.3 to 0.4 times.
I've written hundreds of thousands of lines of Java code without needing or wanting to use a debugger more than a handful of times. That's radically different from C and C++. When you add in the memory protection, solid encapsulation, threads and thread safe libraries, integrated exception handling, extensive class libraries.. the jump from C++ is really quite large.
My (relatively uninformed) intuition is that the jump to Python isn't as large an improvement, but that's more about how really wretched C++ is, not about how ungood Python is.
I absolutely loved it. I wish we could have heard more of the old theme song, as that was always one of the very best bits of the old series.
I hope like hell that it becomes a series and that they keep the writing team. I also hope that they write out an arc ahead of time and tell a single cohesive story. Not like Voyager where there's one big goal set up, and if the characters ever achieved the goal, boom, end of story. The Gilligan's Island phenomena must be avoided at all costs, but if they can do that, kick ass.
Also, it was great hearing 'frack' on TV again. I loved that bit in the original series back in the day.