Losing access to organ donors from your family, the fiscal and social support of your spouse or children or parents, and being unable to find a co-signer for a loan or work recommendations because you have been "shunned" is indeed fiscal harm. So is being unable to work, or sleep, or visit the community you spent the lat 10 years and invested your life into.
I agree that "other groups have done it" is not an excuse. If it were, the Middle East would be filled with factions each trying to avenge the crimes of their neighbors ancestors.
The IRS. The charitable organization certificate is known as a "501c3", and it's a big fiscal deal for a lot of charities and churches, because it eliminates taxes on a lot of your fiscal affairs. It also buys you a lot of First Amendment protection in US courts.
Unfortunately, that quote has never been verified, to the best of my knowledge. Authors like Harlan Ellison, who was a young and active fan when L. Ron was in his pulp writing prime and met him at various parties, have said it sounds like it's something L. Ron would say but they didn't hear him say it.
There's so much other fraud from the guy, there's no need to use unverified or unverifiable quotes to make a sound bite for yourself.
You may have noticed that Magneto eventually *lost* his campaign?
The world needs heroes. Mr. Henson seems to be one of them. I admire his courage, and those of people who speak out and act against fraud, corruption, theft, abuse, or murder. I also admire, respect, and support those who do so gracefully and within the rule of law: such people make better neighbors and colleagues for the long term. Mr. Henson's arrest for peaceful protest is, frankly, the result of lawyers who spend too much time being paid too much money to game the system and wear other people out.
The fight of Scientology on the Internet is particularly instructive: their attempts to censor traffic, and the spam with which they tried to flood traffic, have helped make ISP's think about how to avoid both censorship and denial of service attacks in ways that protect against other abusers. Like a really nasty case of chickenpox, the experience in the childhood of the net helped strengthen our defenses against a far more dangerous infection later.
The cult has a long, long history of illegally harassing critics, to the point of planting fake bomb threats (Operation Snow White), and using the confessional records of its members to blackmail them into silence (documented at www.xenu.net and the books by former members). They also succeeded in suing Cult Awareness Network into bankruptcy with approximately 1500 distinct lawsuits: these are *not* safe people to fight.
Being open source does not a project worth pursuing, or able to be successfully managed by new project leaders. And my experience with Reiserfs (over the last four years) has been that it tends to zero files or lose them when drives start failing on RAID sets, even corrupting the filesystem unrecoverably and forcing a tape backup. And since attempts to perform a final backup as Reiserfs corrupts the system fail randomly, it means a final backup for the last day's work cannot be performed.
This is quite, quite deadly for critical systems. And while htrees may not be as efficient as the new "dancing trees" algorithm, they've proven themselves to be far, far more robust. The big features that compelled the use of Reiserfs, in my experience, was the handling of many thousands of files in one directory. (This is an absolute necessity for Maildir use!) While htree in ext3 may not be as efficient, it's been quite good enough, and far more robust in my experience.
Really? How? I thought Hans was pretty critical to its leadership and develipment, and since ext3 now includes journaling and htree's, there seems little need for it, especially with its remaining tendency to zero files instsead of saving them to lost+found.
1: If your user authentication is network based, and your LDAP or Kerberos or whatever system goes down, being able to get in as root and fix the issue is very handy.
2: Maintaining local user accounts is pesky: see above for what happens when you lose network loser access.
3: The "passwd" command still doesn't have a way to register an *encrypted* password to ease secure local user password management.
4: Badly written remote system management tools that use SSH for system-wide pushing of configurations or scanning of systems often require direct root access. Sad, but true: I've seen and given thumbs down to a lot of these, but been forced twice to use them over my direct rejection of the tools.
Reiserfs suffered from a lot more trouble than that. Reiserfs is effectively dead with its core developer facing murder charges: his cavalier attitude about losing files seems similar to his casual attitude about the location of his ex-wife's corpse. Nasty, but he does seem to be as guilty as OJ Simpson.
It's also the same market as web designers were about 8 years ago or ISP's were about 10 years ago. Lots of small players think they can set up on a shoe string and a back-of-the-napkin business plan, get a bit of funding, and enter the market only to underprice more solid businesses and underprice themselves and the competitors right out of the market.
If you're competent, sell them your services for infrastructure design, warn them of the technical foibles, but get paid in real cash, not stock.
This is a very relevant point, sir or madam. Unfortunately, the reason for *that* is a nasty legal one. The US remains the biggest software creating country in the world, and the export of encryption technologies is oddly regulated. The result is that basic software tools, such as Windows and web authorship tools and file-sharing tools, rarely include good encryption built-in.
Take a look at the history of PGP and Phil Zimmerman's legal troubles to see why people don't include robust security by default. It seems clear that the US government's avowed desire to remain able to crack overseas traffic by limiting cryptography both imperils their own citizens' security, and protects their ability to monitor their own citizens' traffic without warrants or detection. (This was demonstrated forcibly in the discovery of the monitoring rooms of the NSA at various major network provider's network backbones, which is still a nasty matter in the courts.)
They're a pretty big chain. They've filled some of the clothing market niches in places where a Wal-mart or a K-mart or an S-mart would be just too big. I've bought cheap socks and underwear there when traveling and running out of clean clothes on a business trip.
I'm not sure an "organization" to certify us will help, though. It's likely to be another MCSE-like, useless paper trail to protect managers for hirinig "certified" engineersw, instead of the real necessary skill sets to do solid work.
And I've seen, recently, exactly the kind of hapless corporate security that leads to unencrypted or WEP-based wireless traffic. As a visitor at a corporate office, my jaw dropped to the floor upon discovering that they were using WEP in a first-floor office with a cafe across the street where any casual wireless user could probe their network. Then I noticed they were using FTP for internal file transfers of user accounts, encouraging packet sniffing and password theft. They then proceeded to explain to me how their non-discluser agreements and employee contracts prevented abuse.
I recommended against buying *any* technical expertise or software from that company, for this and other reasons. But it was hard for me to get the idea across to my own paycheck signers that if they're this stupid in their office, we can't hope to secure their software products in the field.
Given the availability and use of 40 GB Ipod devices, and USB devices like these (http://gadgets.fosfor.se/the-top-10-weirdest-usb- drives-ever/), it's difficult to avoid. And you don't dare remove USB ports altogether since employees do need good USB audio and graphical devices to do their work.
Would you care to lay a wager that far, far lower encryption standards are used as a matter of course by many federal groups, without even the knowledge of their users? The default setting for many UNIX installations and their password management for/etc/passwd and htpasswd are still DES, and your average Microsoft Certified Software Engineer who is hired straight out of school does not have the experience or pull to get that fixed, even when they do notice the problem.
I think you've mistaken "waving arms at sheep" with "herding cats". The open source community is pretty wildly divergent, and goes lots of ways for lots of reasons.
This is the problem with your whole book of material: the "they can just fork" approach to Novell's situation betrays a deep lack of familiarity with genuine problems and you glossed it over. To sum up: forking Novell's own copy of GPL material to preserve its usability under the Novell-Microsoft patent agreement creates unmaintainable forks of core materials.
The Linux kernel is nearly a strawman in this: even if Linus manages to keep its core in GPLv2 (and I'm not sure he can for more than a few years, but he may!), the userland tools necessary to access new feature sets are critical. Take a look at the LinuxBIOS and Trusted Computing tools for examples where the desire for GPLv3 is extremely real and well-founded to avoid intellectual property booby traps.
Have you actually *done* much kernel work, or backporting or forward porting of software that is locked at certain release levels? It pays me a handy salary, because it's a nightmare tracking down and resolving all the dependencies and interlocking feature changes. Toolsets like Perl are even worse!
Then say what you need to say in separate posts. This is why books have chapters, and you went through so many distinct issues, all of them at least subtlely skewed, that it's difficult to address them as a whole.
You are handwaving over the engineering and legal issues of maintaining a fork. Almost every single sentence of your claims betrays this. I'll take your second paragraph, line-by-line, as an example:
1: But no I haven't tried to for anything myself.
So you're telling other people to do it, with no experience of its pain and difficulty.
2: But you see, they don't have to upgrade anything, they just need to to continue to work with their product. So it isn't the same as devloping everything from scratch.
Oh, my. So I can fork the Linux kernel and maintain support for GigE network cards, especially Broadcom, or new SATA controllers, or NTFS support, or gcc bugs that affect kernel compilation. You've obviously *not* actually done kernel level work. Or any of the other dozens or hundreds of GPL components, such as zlib (used to compress kernel images to make vmlinuz and to compress software for RPM's) or make (used to build most SuSE packages) or gcc (used to compile almost everything). This isn't one tool: it's dozens or *hundreds* that would have to be forked as they become GPLv3 and the Microsoft agreement means they'd be liable for putting Microsoft patented technologies into the GPL domain.
3: So it isn't the same as devloping everything from scratch.
Of course it's not. But new feature and software development has to be separated from GPLv3 development, because Novell has now drunk the Microsoft patent Kool-aid. It means they can't contribute to GPLv3 products or develop from them, because the GPLv3 is aimed squarely at Microsoft and other vendor's abuse of patent law. It's having to develop new features and compatibilities from old GPLv2 releases, adn that's about to become quite difficult in surprising ways.
4: The Linux Kernel will Stay GPLv2.
New drivers won't. This is particularly true for low-level, leading edge functionality such as Infiniband and new file-system types. Even if the rest of the kernel stays GPLv2, which is likely, the userland utilities will very likely update or be released under GPLv3. So go ahead, maintain your own tree of glibc, gcc, make, and zlib.
5: Too much has already been said on that matter to think otherwise.
You mean people like you who've never actually tried to fork a major software project have handwaved the difficulty away.
6: GCC and the GNU tool chain already works so there isn't much to do there unless you change what your working with.
Yeah, and internal combustion are a mature technology so my 1925 car will work just fine. You've obviously *NEVER* dealt with gcc support. I have. It's amazingly stable, but optimizations and handling new issues such as 64-bit are not small changes. If you're willing to freeze all your software development in a toolchain that can no longer be updated, then you're welcome to play in the world of big high availability iron and not be able to get any new customers. You're dead as a doornail in the desktop or advanced technology server worlds.
7: These companies aren't pushing products into people, They are selling products to companies and selling services behind them.
You've apparently never sat in on the marketing people meeting with customer VP's to try and shovel a new product set down your throats, even if it's wildly unsuited to the project at hand. This is what advertising and sales teams are *for*.
8: They don't need to continually develop everything, All they need is to have something stable and working.
And this is why the Western World still uses Roman numerals, right?
Nahh. IBM already has sidestepped the UNIX licensing problems by pursuing Linux, and learned the hard way ho9w to protect it from ludicrous and farudulent claims. Microsoft does *not* want the name UNIX mentioned anywhere near them: it's key to their marketing that they not do direct comparisons or admit its legitimacy.
I've met people from Massachusetts. Apparently the whole town of Belmont, where Romney lives, is very Mormon, with no liquor stores and all the shops closing by 6:00 PM.
Write shorter posts: responding to such long points and failing to cover all your points implies that we agree with the rest, instead of needing eight hours of sleep before being able to finish the reply.
Second, to take a specific example, have you ever tried to fork and maintain a fork of anything critical like gcc, emacs, make, vi, less, gzip, or the Linux kernel? And if the main codeline goes to GPLv3, you'll have to do clean-room development to keep it GPLv2. That makes it far, far more expensive to do such development.
And there are specific instances of the problem. Jeremy Allison's extensive work with Samba was something Microsoft *needed* to spike, by whatever means possible, since most of the network file system drives and external storage devices we're seeing today are Linux and especially Samba based. That's not a market Microsoft can leave alone: it keeps people away from the license and hardware over-burdened Windows server market.
Jeremy continuing in Samba work under the Novell/Microsoft patent agreement put Samba users at risk, and gave Microsoft leverage through Novell to interfere with it. That's perhaps the most obvious example of the problem: there are doubtless others. Fortunately, Jeremy resigned from Novell rather publicly over this deal, and resigned rather publicly. I hope Google, which hired him, can continue his efforts.
Slashdot Mirror
Go for the Discordians. They're more fun at parties, and you get to eat hot dogs.
Losing access to organ donors from your family, the fiscal and social support of your spouse or children or parents, and being unable to find a co-signer for a loan or work recommendations because you have been "shunned" is indeed fiscal harm. So is being unable to work, or sleep, or visit the community you spent the lat 10 years and invested your life into.
I agree that "other groups have done it" is not an excuse. If it were, the Middle East would be filled with factions each trying to avenge the crimes of their neighbors ancestors.
Wait......
The IRS. The charitable organization certificate is known as a "501c3", and it's a big fiscal deal for a lot of charities and churches, because it eliminates taxes on a lot of your fiscal affairs. It also buys you a lot of First Amendment protection in US courts.
Unfortunately, that quote has never been verified, to the best of my knowledge. Authors like Harlan Ellison, who was a young and active fan when L. Ron was in his pulp writing prime and met him at various parties, have said it sounds like it's something L. Ron would say but they didn't hear him say it. There's so much other fraud from the guy, there's no need to use unverified or unverifiable quotes to make a sound bite for yourself.
You may have noticed that Magneto eventually *lost* his campaign?
The world needs heroes. Mr. Henson seems to be one of them. I admire his courage, and those of people who speak out and act against fraud, corruption, theft, abuse, or murder. I also admire, respect, and support those who do so gracefully and within the rule of law: such people make better neighbors and colleagues for the long term. Mr. Henson's arrest for peaceful protest is, frankly, the result of lawyers who spend too much time being paid too much money to game the system and wear other people out.
The fight of Scientology on the Internet is particularly instructive: their attempts to censor traffic, and the spam with which they tried to flood traffic, have helped make ISP's think about how to avoid both censorship and denial of service attacks in ways that protect against other abusers. Like a really nasty case of chickenpox, the experience in the childhood of the net helped strengthen our defenses against a far more dangerous infection later.
The cult has a long, long history of illegally harassing critics, to the point of planting fake bomb threats (Operation Snow White), and using the confessional records of its members to blackmail them into silence (documented at www.xenu.net and the books by former members). They also succeeded in suing Cult Awareness Network into bankruptcy with approximately 1500 distinct lawsuits: these are *not* safe people to fight.
Being open source does not a project worth pursuing, or able to be successfully managed by new project leaders. And my experience with Reiserfs (over the last four years) has been that it tends to zero files or lose them when drives start failing on RAID sets, even corrupting the filesystem unrecoverably and forcing a tape backup. And since attempts to perform a final backup as Reiserfs corrupts the system fail randomly, it means a final backup for the last day's work cannot be performed.
This is quite, quite deadly for critical systems. And while htrees may not be as efficient as the new "dancing trees" algorithm, they've proven themselves to be far, far more robust. The big features that compelled the use of Reiserfs, in my experience, was the handling of many thousands of files in one directory. (This is an absolute necessity for Maildir use!) While htree in ext3 may not be as efficient, it's been quite good enough, and far more robust in my experience.
Really? How? I thought Hans was pretty critical to its leadership and develipment, and since ext3 now includes journaling and htree's, there seems little need for it, especially with its remaining tendency to zero files instsead of saving them to lost+found.
Now *manage* those locally defined users. It's quite a lot of work.
Or give them this Spidey costume personal violation (http://www.ctrlaltdel-online.com/comic.php?d=2007 0505).
For several reasons:
1: If your user authentication is network based, and your LDAP or Kerberos or whatever system goes down, being able to get in as root and fix the issue is very handy.
2: Maintaining local user accounts is pesky: see above for what happens when you lose network loser access.
3: The "passwd" command still doesn't have a way to register an *encrypted* password to ease secure local user password management.
4: Badly written remote system management tools that use SSH for system-wide pushing of configurations or scanning of systems often require direct root access. Sad, but true: I've seen and given thumbs down to a lot of these, but been forced twice to use them over my direct rejection of the tools.
Reiserfs suffered from a lot more trouble than that. Reiserfs is effectively dead with its core developer facing murder charges: his cavalier attitude about losing files seems similar to his casual attitude about the location of his ex-wife's corpse. Nasty, but he does seem to be as guilty as OJ Simpson.
It's also the same market as web designers were about 8 years ago or ISP's were about 10 years ago. Lots of small players think they can set up on a shoe string and a back-of-the-napkin business plan, get a bit of funding, and enter the market only to underprice more solid businesses and underprice themselves and the competitors right out of the market.
If you're competent, sell them your services for infrastructure design, warn them of the technical foibles, but get paid in real cash, not stock.
This is a very relevant point, sir or madam. Unfortunately, the reason for *that* is a nasty legal one. The US remains the biggest software creating country in the world, and the export of encryption technologies is oddly regulated. The result is that basic software tools, such as Windows and web authorship tools and file-sharing tools, rarely include good encryption built-in.
Take a look at the history of PGP and Phil Zimmerman's legal troubles to see why people don't include robust security by default. It seems clear that the US government's avowed desire to remain able to crack overseas traffic by limiting cryptography both imperils their own citizens' security, and protects their ability to monitor their own citizens' traffic without warrants or detection. (This was demonstrated forcibly in the discovery of the monitoring rooms of the NSA at various major network provider's network backbones, which is still a nasty matter in the courts.)
They're a pretty big chain. They've filled some of the clothing market niches in places where a Wal-mart or a K-mart or an S-mart would be just too big. I've bought cheap socks and underwear there when traveling and running out of clean clothes on a business trip.
Hmm. We're a mixed lot.
I'm not sure an "organization" to certify us will help, though. It's likely to be another MCSE-like, useless paper trail to protect managers for hirinig "certified" engineersw, instead of the real necessary skill sets to do solid work.
And I've seen, recently, exactly the kind of hapless corporate security that leads to unencrypted or WEP-based wireless traffic. As a visitor at a corporate office, my jaw dropped to the floor upon discovering that they were using WEP in a first-floor office with a cafe across the street where any casual wireless user could probe their network. Then I noticed they were using FTP for internal file transfers of user accounts, encouraging packet sniffing and password theft. They then proceeded to explain to me how their non-discluser agreements and employee contracts prevented abuse.
I recommended against buying *any* technical expertise or software from that company, for this and other reasons. But it was hard for me to get the idea across to my own paycheck signers that if they're this stupid in their office, we can't hope to secure their software products in the field.
Given the availability and use of 40 GB Ipod devices, and USB devices like these (http://gadgets.fosfor.se/the-top-10-weirdest-usb- drives-ever/), it's difficult to avoid. And you don't dare remove USB ports altogether since employees do need good USB audio and graphical devices to do their work.
Would you care to lay a wager that far, far lower encryption standards are used as a matter of course by many federal groups, without even the knowledge of their users? The default setting for many UNIX installations and their password management for /etc/passwd and htpasswd are still DES, and your average Microsoft Certified Software Engineer who is hired straight out of school does not have the experience or pull to get that fixed, even when they do notice the problem.
I think you've mistaken "waving arms at sheep" with "herding cats". The open source community is pretty wildly divergent, and goes lots of ways for lots of reasons.
This is the problem with your whole book of material: the "they can just fork" approach to Novell's situation betrays a deep lack of familiarity with genuine problems and you glossed it over. To sum up: forking Novell's own copy of GPL material to preserve its usability under the Novell-Microsoft patent agreement creates unmaintainable forks of core materials.
The Linux kernel is nearly a strawman in this: even if Linus manages to keep its core in GPLv2 (and I'm not sure he can for more than a few years, but he may!), the userland tools necessary to access new feature sets are critical. Take a look at the LinuxBIOS and Trusted Computing tools for examples where the desire for GPLv3 is extremely real and well-founded to avoid intellectual property booby traps.
Have you actually *done* much kernel work, or backporting or forward porting of software that is locked at certain release levels? It pays me a handy salary, because it's a nightmare tracking down and resolving all the dependencies and interlocking feature changes. Toolsets like Perl are even worse!
Then say what you need to say in separate posts. This is why books have chapters, and you went through so many distinct issues, all of them at least subtlely skewed, that it's difficult to address them as a whole.
You are handwaving over the engineering and legal issues of maintaining a fork. Almost every single sentence of your claims betrays this. I'll take your second paragraph, line-by-line, as an example:
1: But no I haven't tried to for anything myself.
So you're telling other people to do it, with no experience of its pain and difficulty.
2: But you see, they don't have to upgrade anything, they just need to to continue to work with their product. So it isn't the same as devloping everything from scratch.
Oh, my. So I can fork the Linux kernel and maintain support for GigE network cards, especially Broadcom, or new SATA controllers, or NTFS support, or gcc bugs that affect kernel compilation. You've obviously *not* actually done kernel level work. Or any of the other dozens or hundreds of GPL components, such as zlib (used to compress kernel images to make vmlinuz and to compress software for RPM's) or make (used to build most SuSE packages) or gcc (used to compile almost everything). This isn't one tool: it's dozens or *hundreds* that would have to be forked as they become GPLv3 and the Microsoft agreement means they'd be liable for putting Microsoft patented technologies into the GPL domain.
3: So it isn't the same as devloping everything from scratch.
Of course it's not. But new feature and software development has to be separated from GPLv3 development, because Novell has now drunk the Microsoft patent Kool-aid. It means they can't contribute to GPLv3 products or develop from them, because the GPLv3 is aimed squarely at Microsoft and other vendor's abuse of patent law. It's having to develop new features and compatibilities from old GPLv2 releases, adn that's about to become quite difficult in surprising ways.
4: The Linux Kernel will Stay GPLv2.
New drivers won't. This is particularly true for low-level, leading edge functionality such as Infiniband and new file-system types. Even if the rest of the kernel stays GPLv2, which is likely, the userland utilities will very likely update or be released under GPLv3. So go ahead, maintain your own tree of glibc, gcc, make, and zlib.
5: Too much has already been said on that matter to think otherwise.
You mean people like you who've never actually tried to fork a major software project have handwaved the difficulty away.
6: GCC and the GNU tool chain already works so there isn't much to do there unless you change what your working with.
Yeah, and internal combustion are a mature technology so my 1925 car will work just fine. You've obviously *NEVER* dealt with gcc support. I have. It's amazingly stable, but optimizations and handling new issues such as 64-bit are not small changes. If you're willing to freeze all your software development in a toolchain that can no longer be updated, then you're welcome to play in the world of big high availability iron and not be able to get any new customers. You're dead as a doornail in the desktop or advanced technology server worlds.
7: These companies aren't pushing products into people, They are selling products to companies and selling services behind them.
You've apparently never sat in on the marketing people meeting with customer VP's to try and shovel a new product set down your throats, even if it's wildly unsuited to the project at hand. This is what advertising and sales teams are *for*.
8: They don't need to continually develop everything, All they need is to have something stable and working.
And this is why the Western World still uses Roman numerals, right?
Nahh. IBM already has sidestepped the UNIX licensing problems by pursuing Linux, and learned the hard way ho9w to protect it from ludicrous and farudulent claims. Microsoft does *not* want the name UNIX mentioned anywhere near them: it's key to their marketing that they not do direct comparisons or admit its legitimacy.
I've met people from Massachusetts. Apparently the whole town of Belmont, where Romney lives, is very Mormon, with no liquor stores and all the shops closing by 6:00 PM.
Write shorter posts: responding to such long points and failing to cover all your points implies that we agree with the rest, instead of needing eight hours of sleep before being able to finish the reply.
Second, to take a specific example, have you ever tried to fork and maintain a fork of anything critical like gcc, emacs, make, vi, less, gzip, or the Linux kernel? And if the main codeline goes to GPLv3, you'll have to do clean-room development to keep it GPLv2. That makes it far, far more expensive to do such development.
And there are specific instances of the problem. Jeremy Allison's extensive work with Samba was something Microsoft *needed* to spike, by whatever means possible, since most of the network file system drives and external storage devices we're seeing today are Linux and especially Samba based. That's not a market Microsoft can leave alone: it keeps people away from the license and hardware over-burdened Windows server market.
Jeremy continuing in Samba work under the Novell/Microsoft patent agreement put Samba users at risk, and gave Microsoft leverage through Novell to interfere with it. That's perhaps the most obvious example of the problem: there are doubtless others. Fortunately, Jeremy resigned from Novell rather publicly over this deal, and resigned rather publicly. I hope Google, which hired him, can continue his efforts.