Yes, that's true. That is the real problem -- the federal government uses all sorts of excuses to impose itself upon the people (or the states). This trend shows no signs of reversing, either.
I don't think realistically anyone is ever going to be able to stop the federal government. It has grown in scope and power beyond what anyone has imagined. I honestly hope that the same thing doesn't happen to the EU, where their 'federal' government ends up crushing the sovereignty of member-states, as has happened here in the US.
...To regulate commerce with foreign nations, and among the several states, and with the Indian tribes;
Well, strictly sepeaking, the above sentence proves nothing. They are talking about commerce with foreign nations and among the several states (this means basically, any commerce not inside a state).
Constitutional scholars agree that originally, the United States was to occupy the federal space -- meaning issues between states and with foreign governments. Unfortantely this went the way of the Dodo long ago. Today the federal government is something else entirely. It's sad, but the parent to our posts is right. The 9th and 10th Amendments are ignored completely and there is no clear answer to this. Noone knows what to do about this, and often the argument that is used to justify it is the argument you have presented.
I really wish that the authors of the constitution were much much more explicit in their intentions to limit Federal power, but in the end perhaps incresed Federalism is a good thing for the prosperity of the nation as a whole.. I don't know.
While it's true that BSD is momentarily 'freer' in the sense that you can do whatever you want with it, this logic is ultimately really flawed.
If you look at the big picture, it is _not_ the way to go. FreeBSD discourages the true ideals of Free Software, because it offers no protections to those wishing to contribute, including private companies.
And if you think that if GCC had a BSD license that Apple would simply "give away" their modifications to GCC, you are pretty naive.
And to call the GPL a silly expression of freedom is utterly insulting and completely sophomoric. I won't even respond to that. You clearly don't get what free software is all about.
Yes! You are right. That's the crux of the problem. In fact vendors are DISCOURAGED from contributing to BSD, because they FEAR helping out the competition.
Now, with Linux, even vendors are freer to contribute, because their contributions are GUARANTEED to not be exploited by their competition and used against the vendor that contributed. Everybody wins. This is why GPL is more free than BSD.
Re:Panther/Darwin contributions?
on
FreeBSD 4.9 Released
·
· Score: -1, Flamebait
Yeah most people are blind. It's sad to me that people don't understand why FreeBSD is not as free as GPL'd alternatives.
*sigh*
All my posts on this topic got modded down as troll or flamebait.:(
Yeah and that's because userland is GPL'd! They _have_ to give back. You think if GCC was under a BSD license what would happen? Nope. They would simply take GCC, modify it to suit their needs, then keep the modifications secret.
It makes little business sense for a company to volunteer to give back to the community (after all they put money into the modifications, why help out the competition potentially?), unless code is protected by the GPL.
This is precisely the reason why FreeBSD is less free than Linux.
You have a naive understanding of how the world works my friend. Can you truly be free when there is no system in place to protect your rights? No! Would you consider yourself free if there were no laws?
Sure you would be, for a time, until that pack of hungry hoodlums comes by and denies you all of your freedoms. They beat you up and take away your property. They can do it because they are just as free as you. As soon as they do that you are no longer free. They can do it because you aren't protected by the law.
True freedom means the ability to be protected from losing your freedom. We in the United States like to say we live in a free country. Not because we can do whatever we like, but because we like to think that the system is all about protecting our freedoms as much as is possible in a civilized society (at least we used to think that before the USA Patriot Act.)
Your freedom is about as short-lived as the amount of time it takes some guy to come over and bully you into giving up your rights!
The thing about FreeBSD is that anyone can easily take away the freedom of the software! And many closed-source vendors do just that.
For software to truly be free, it must never ever ever risk losing its freedom, no matter what hands it falls into. Anything else is not free.
Re:Panther/Darwin contributions?
on
FreeBSD 4.9 Released
·
· Score: -1, Flamebait
The problem is that unless your featureset supercedes that of the real FreeBSD project (hard to do if you're just one guy), companies can ignore your fork and stick with the original BSD license.
The only way to do it is to get everyone using your fork and somehow make its features better than those of FreeBSD. But it's a waste of resources, since the FreeBSD maintainers are still working against you, in a sense.
It comes down to this: every line of code the FreeBSD programmers write weakens free software, beacuse ultimately, that line of code can easily be used in non-free software. The FreeBSD developers, without realizing it, are working against software freedom by not GPL'ing their code.
Think about it! I am not just being flamebait here, it's true. And if you think this argument is too idealistic or too zealous or too much like something RMS would say, then you really don't respect GNU software. If you use GNU/Linux at all, you really should think about the ideals that made the whole system possible.
FreeBSD is *not* free guys! It never was! At least not in the true sense of the word. It is rather an attempt by some programmers to whore themselves out so that their code can be as popular as possible and as widely used as possible, with only an afterthought given to the ideals of truly free software.
I love BSD. It's so easy for any Evil Corporation to take it, modify it, redistribute it under a draconian closed-source license, charge an arm-and-a-leg for it, and REAP THE REWARDS! Even if 99% of the code is untouched. Muahahaha!
Guys, wake up. BSD is not free software. It never was. Well it is free, but it's not designed to stay free due to its overly permissive license. Any true supporter of free software would shun it and stick with GNU/Linux these days.
BSD comes with a lot of GNU utils. They *owe* the GNU project, and would do well to switch their license to the FSF's GPL.
(Let me make a piece of software. Call it RedWM, the Red Window Manager, and within it offer only shades of burgundy and not any real Red. That's an analogy for how misnamed FreeBSD truly is!)
The registry itself charges registrars $6/year for registrations. Theoretically a registrar can charge you as little as $6.01 and still make a profit on the sale. However in practice you get get registration prices on the cheap registrars (the ones that don't rip you off) for around $9 or less per year.
People in power have always lied to those that they take power from. Even people without power lie to get out of trouble.
It's a story as old as humanity itself.
You can be shocked and/or appalled by this behavior, but it's quite natural to consider that systems that allow for lying and/or encourage hiding the truth for whatever reason (whether they be justified or not) have always existed and as long as they continue to exist people will continue to lie. If you want to change the behavior pattern, change the underlying system. Unfortunately noone seems to quite have worked out a flawless, utopian system involving human beings. Such systems are difficult to maintain ad infinitum.
Linux already had huge amount of memory mappable as mmap'able since probably the mid 90's.
* larger driver and system space
What does this mean? What the drivers before had to be mapped to a particular region of memory or something? I don't get it. Linux can take as much 'System Space' as it freaking wants. The kernel can map as many memory pages as it wants for itself. Why was this ever limited in the first place?
* ability to detach from processes being debugged
WOW. Imagine THAT! I think Linux has had this ability since 1.0!! Stupid Microsoft OS.
* callbacks for file system filter drivers
How useful. Yeah you convinced me. Now let me write Microsoft that big check for their buggy worm-infested OS. Now that I can install filesystem filter drivers easily using their callback scheme, I can really fly! No wonder they have that commercial where everyone is flying out the window in their office. I mean this was the one feature people really were screaming for in order to increase their productivity and become super-beings and reach nirvana. THANKS BILLY FOR THIS GREAT OS!
Well, if I am not mistaken in the current Gcc/Glibc combo you can turn on dumb things like gets() and mktemp() anyway.. but their being off by default makes most programs safer and a minority of programs require special platform-specific build flags...
It's not even a matter of checking user input!
on
LSB & Posix Conflicts
·
· Score: 4, Informative
No programmer in their right mind uses the I/O POSIX functions without checking the user input. Too bad there are still very common buffer overflows, format strings and heap overflows found in (more or less major) projects.
Dude, gets() is so bad, there is _no way_ to guarantee that the incoming string isn't going to totally cause a buffer overflow! _No way_! You can ioctl() with FIONREAD all you want, you still aren't guaranteed that the string you pass to gets() is actually big enough to hold the incoming text. At best you get a program crash -- at worst you get a hacker with root!
gets() is just bad, horrible, terrible design. You say something about checking the input to prevent overflows, but by the time you get the string back from gets() it's too late! The stack is already fsked. Or if it's on the heap you probably already crashed or your program is somehow otherwise corrupt...
WRONG! POSIX does some really dumb things!!
on
LSB & Posix Conflicts
·
· Score: 5, Informative
POSIX does some dumb things. Ever hear of the gets() function?
Also, in most cases the LSB is a superset of POSIX, but the contradictions are _minor_. Not show-stoppers.. not enough to require significant application rewrites when porting to Linux. So what if O_LARGEFILE is set most of the time? This is actually a good thing because most of the time it causes no problems. Even if you are checking the fd flags O_LARGEFILE being set isn't a problem as long as you check the flags in the _right_ way, that is logical AND'ing them with the flag you want to check for. The only time this contradiction causes a problem is if you are breing stupid and expecting the flags to be explicitly equal to some magic number you were expecting. Sure that is not exactly to spec, but for 99.9% of the apps out there it doesn't break compatibility, and if it does it's a one-line fix. However the benefint of fcntl() acting this way is clear -- most apps on linux have no problems with 64-bit file-sizes which are more and more common these days!
106 2.1.4 gets
107 The LSB has deprecated the gets() function, whereas it is a first
108 class function in ISO/IEC 9945 and ISO/IEC 9899.
How about the gets() function??! This is a dumb function. A first class function!! It is the stupidest function ever and GUARANTEES buffer overflow errors!!!
If you will remember the movie, that computer _was_ on a private network. She had to break into this private secure office building before she even began hacking. So she was behind the firewall already because she was physically in the building.
You know.. you may be right.. consider this little program. It is a series of characters in an array.. the characters are 0x01,0x01,0x01,0x00 (as was your case (2)). When you print this out as an int, you get 65793. This is certainly less than 16 million.
So I don't get what Ingo means when he says that this region is somehow ASCII-shielded... because you are right.. on the x86 the high order byte is last, not first (as was the assumption in Ingo Molnar's little readme).
Why would you ever need to recompile an application to take advantage of a kernel patch? I could see the need to recompile libraries or statically compiled applications, but it seems logical to me that a kernel patch should only require you to patch the programs that use the kernel source code: the kernel (maybe some modules too, but I don't think that's the case here).
While it is true that in general even HUGE changes to the kernel rarely need an application recompile, and are transparent, sometimes this is not the case.
Consider the following:
Some applications interact with the kernel's address space and/or filesystem format/implementation, consider programs like e2fsck, modprobe/insmod, mke2fs, mkreiserfs, et al. These programs need to know about any changes to the kernel's implementation of loadable kernel modules, filesystems, etc.
Occasionally the kernel adds functionality. Consider the Xfree86 DRM infrastructure. That was new and required application support.
Consider that the kernel once didn't support ELF binaries. A.out was the norm. When the kernel started supporting the ELF format, the compiler tools needed to be changed.
Actually, even this patch is not entirely transparent. In order to best benefit from the ASCII-armor area, you will notice that in the readme text file they actually gave a patch to binutils to make executables try and use a lower address for their program text. Executables (unlike shared libraries) aren't relocatable and thus need to be re-linked in order to use a different (lower) address...
This is a very strong analogy. A compiler is considered crap if it segfaults at all on 'bad' code (or even on good code). Sure, these things happen.. everyone is human and they make mistakes. But I agree with you that it should be avoided at all costs.
As for the whole library discussion, that is a different animal all together and I totally agree that it can often be desirable for libraries to crash and/or not check their inputs for validity, esp. if it is expensive to do so. Some libraries can decide to check their inputs, and in general these types of functions in these libraries are considered more 'developer friendly' but this type of decision must be made on a case-by-case basis when designing a library.
I work on an industry-leading mathematical library. We rely, in a few places, on getting sensible input from our client apps. If they give us garbage, they have no guarantees about getting a sensible error back, or even about anything ever coming back.
I must disagree with you there, Anonymous Brave Guy. There is a difference between your library and IE. One is a library while the other is a user application. Clients of a library are other programs (code) that link to the library and make calls to it. The application programmers that use your library can be given an exact spec on 'defined' and 'undefined' usage of each of the library's functions/methods. Each and every defined usage of the library is guaranteed to produce defined (non-crashing) results. Often undefined usage of the library is EXPECTED to crash the program immediately (this can help with developer testing and debugging.. having errors not crash a program but rather propagate out far beyond an errant call is often considered undesirable because it makes debugging more difficult.)
However, full user appliations are a different story. They are expected to be ultra-robust and (ideally) crashproof. Especially mainstream 'consumer' apps like IE, which just about everyone that has ever used a computer has probably fired up once or twice in their life, if not every day.
Computer programs need to be rock-solid. They need to be able to process input (valid or invalid) indefinitely until they are stopped by the user.
Slashdot Mirror
Touche. I'm not actually a warez kid, though. You are probably lacking in a decent sense of humor, that is all.
You are also an asshole.
Yes, that's true. That is the real problem -- the federal government uses all sorts of excuses to impose itself upon the people (or the states). This trend shows no signs of reversing, either.
I don't think realistically anyone is ever going to be able to stop the federal government. It has grown in scope and power beyond what anyone has imagined. I honestly hope that the same thing doesn't happen to the EU, where their 'federal' government ends up crushing the sovereignty of member-states, as has happened here in the US.
Well, strictly sepeaking, the above sentence proves nothing. They are talking about commerce with foreign nations and among the several states (this means basically, any commerce not inside a state).
Constitutional scholars agree that originally, the United States was to occupy the federal space -- meaning issues between states and with foreign governments. Unfortantely this went the way of the Dodo long ago. Today the federal government is something else entirely. It's sad, but the parent to our posts is right. The 9th and 10th Amendments are ignored completely and there is no clear answer to this. Noone knows what to do about this, and often the argument that is used to justify it is the argument you have presented.
I really wish that the authors of the constitution were much much more explicit in their intentions to limit Federal power, but in the end perhaps incresed Federalism is a good thing for the prosperity of the nation as a whole.. I don't know.
While it's true that BSD is momentarily 'freer' in the sense that you can do whatever you want with it, this logic is ultimately really flawed.
If you look at the big picture, it is _not_ the way to go. FreeBSD discourages the true ideals of Free Software, because it offers no protections to those wishing to contribute, including private companies.
And if you think that if GCC had a BSD license that Apple would simply "give away" their modifications to GCC, you are pretty naive.
And to call the GPL a silly expression of freedom is utterly insulting and completely sophomoric. I won't even respond to that. You clearly don't get what free software is all about.
Yes! You are right. That's the crux of the problem. In fact vendors are DISCOURAGED from contributing to BSD, because they FEAR helping out the competition.
Now, with Linux, even vendors are freer to contribute, because their contributions are GUARANTEED to not be exploited by their competition and used against the vendor that contributed. Everybody wins. This is why GPL is more free than BSD.
Yeah most people are blind. It's sad to me that people don't understand why FreeBSD is not as free as GPL'd alternatives.
:(
*sigh*
All my posts on this topic got modded down as troll or flamebait.
Yeah and that's because userland is GPL'd! They _have_ to give back. You think if GCC was under a BSD license what would happen? Nope. They would simply take GCC, modify it to suit their needs, then keep the modifications secret.
It makes little business sense for a company to volunteer to give back to the community (after all they put money into the modifications, why help out the competition potentially?), unless code is protected by the GPL.
This is precisely the reason why FreeBSD is less free than Linux.
You have a naive understanding of how the world works my friend. Can you truly be free when there is no system in place to protect your rights? No! Would you consider yourself free if there were no laws?
Sure you would be, for a time, until that pack of hungry hoodlums comes by and denies you all of your freedoms. They beat you up and take away your property. They can do it because they are just as free as you. As soon as they do that you are no longer free. They can do it because you aren't protected by the law.
True freedom means the ability to be protected from losing your freedom. We in the United States like to say we live in a free country. Not because we can do whatever we like, but because we like to think that the system is all about protecting our freedoms as much as is possible in a civilized society (at least we used to think that before the USA Patriot Act.)
Your freedom is about as short-lived as the amount of time it takes some guy to come over and bully you into giving up your rights!
The thing about FreeBSD is that anyone can easily take away the freedom of the software! And many closed-source vendors do just that.
For software to truly be free, it must never ever ever risk losing its freedom, no matter what hands it falls into. Anything else is not free.
The problem is that unless your featureset supercedes that of the real FreeBSD project (hard to do if you're just one guy), companies can ignore your fork and stick with the original BSD license.
The only way to do it is to get everyone using your fork and somehow make its features better than those of FreeBSD. But it's a waste of resources, since the FreeBSD maintainers are still working against you, in a sense.
It comes down to this: every line of code the FreeBSD programmers write weakens free software, beacuse ultimately, that line of code can easily be used in non-free software. The FreeBSD developers, without realizing it, are working against software freedom by not GPL'ing their code.
Think about it! I am not just being flamebait here, it's true. And if you think this argument is too idealistic or too zealous or too much like something RMS would say, then you really don't respect GNU software. If you use GNU/Linux at all, you really should think about the ideals that made the whole system possible.
Yes! That's the problem with the BSD license. I really hope people wake up and realize there is no Free in FreeBSD.
FreeBSD is *not* free guys! It never was! At least not in the true sense of the word. It is rather an attempt by some programmers to whore themselves out so that their code can be as popular as possible and as widely used as possible, with only an afterthought given to the ideals of truly free software.
I love BSD. It's so easy for any Evil Corporation to take it, modify it, redistribute it under a draconian closed-source license, charge an arm-and-a-leg for it, and REAP THE REWARDS! Even if 99% of the code is untouched. Muahahaha!
Guys, wake up. BSD is not free software. It never was. Well it is free, but it's not designed to stay free due to its overly permissive license. Any true supporter of free software would shun it and stick with GNU/Linux these days.
BSD comes with a lot of GNU utils. They *owe* the GNU project, and would do well to switch their license to the FSF's GPL.
(Let me make a piece of software. Call it RedWM, the Red Window Manager, and within it offer only shades of burgundy and not any real Red. That's an analogy for how misnamed FreeBSD truly is!)
The registry itself charges registrars $6/year for registrations. Theoretically a registrar can charge you as little as $6.01 and still make a profit on the sale. However in practice you get get registration prices on the cheap registrars (the ones that don't rip you off) for around $9 or less per year.
People in power have always lied to those that they take power from. Even people without power lie to get out of trouble.
It's a story as old as humanity itself.
You can be shocked and/or appalled by this behavior, but it's quite natural to consider that systems that allow for lying and/or encourage hiding the truth for whatever reason (whether they be justified or not) have always existed and as long as they continue to exist people will continue to lie. If you want to change the behavior pattern, change the underlying system. Unfortunately noone seems to quite have worked out a flawless, utopian system involving human beings. Such systems are difficult to maintain ad infinitum.
This just proves to me how Wind0z3 is a toy OS.
* larger memory mapped file size
Linux already had huge amount of memory mappable as mmap'able since probably the mid 90's.
* larger driver and system space
What does this mean? What the drivers before had to be mapped to a particular region of memory or something? I don't get it. Linux can take as much 'System Space' as it freaking wants. The kernel can map as many memory pages as it wants for itself. Why was this ever limited in the first place?
* ability to detach from processes being debugged
WOW. Imagine THAT! I think Linux has had this ability since 1.0!! Stupid Microsoft OS.
* callbacks for file system filter drivers
How useful. Yeah you convinced me. Now let me write Microsoft that big check for their buggy worm-infested OS. Now that I can install filesystem filter drivers easily using their callback scheme, I can really fly! No wonder they have that commercial where everyone is flying out the window in their office. I mean this was the one feature people really were screaming for in order to increase their productivity and become super-beings and reach nirvana. THANKS BILLY FOR THIS GREAT OS!
That's just a linking problem. You are clearly a moron. And what's with your line breaks?
Retard.
Well, if I am not mistaken in the current Gcc/Glibc combo you can turn on dumb things like gets() and mktemp() anyway.. but their being off by default makes most programs safer and a minority of programs require special platform-specific build flags...
Dude, gets() is so bad, there is _no way_ to guarantee that the incoming string isn't going to totally cause a buffer overflow! _No way_! You can ioctl() with FIONREAD all you want, you still aren't guaranteed that the string you pass to gets() is actually big enough to hold the incoming text. At best you get a program crash -- at worst you get a hacker with root!
gets() is just bad, horrible, terrible design. You say something about checking the input to prevent overflows, but by the time you get the string back from gets() it's too late! The stack is already fsked. Or if it's on the heap you probably already crashed or your program is somehow otherwise corrupt...
POSIX does some dumb things. Ever hear of the gets() function?
Also, in most cases the LSB is a superset of POSIX, but the contradictions are _minor_. Not show-stoppers.. not enough to require significant application rewrites when porting to Linux. So what if O_LARGEFILE is set most of the time? This is actually a good thing because most of the time it causes no problems. Even if you are checking the fd flags O_LARGEFILE being set isn't a problem as long as you check the flags in the _right_ way, that is logical AND'ing them with the flag you want to check for. The only time this contradiction causes a problem is if you are breing stupid and expecting the flags to be explicitly equal to some magic number you were expecting. Sure that is not exactly to spec, but for 99.9% of the apps out there it doesn't break compatibility, and if it does it's a one-line fix. However the benefint of fcntl() acting this way is clear -- most apps on linux have no problems with 64-bit file-sizes which are more and more common these days!
If you will remember the movie, that computer _was_ on a private network. She had to break into this private secure office building before she even began hacking. So she was behind the firewall already because she was physically in the building.
You know.. you may be right.. consider this little program. It is a series of characters in an array.. the characters are 0x01,0x01,0x01,0x00 (as was your case (2)). When you print this out as an int, you get 65793. This is certainly less than 16 million.
#include <stdio.h>
#include <string.h>
int main(void)
{
char arr[sizeof(int)] = { 0x01, 0x01, 0x01, 0x00 };
printf("%d\n", *((int *)arr));
return 0;
}
So I don't get what Ingo means when he says that this region is somehow ASCII-shielded... because you are right.. on the x86 the high order byte is last, not first (as was the assumption in Ingo Molnar's little readme).
What GIVES??! Anyone? What am *I* missing?
While it is true that in general even HUGE changes to the kernel rarely need an application recompile, and are transparent, sometimes this is not the case.
Consider the following:
Actually, even this patch is not entirely transparent. In order to best benefit from the ASCII-armor area, you will notice that in the readme text file they actually gave a patch to binutils to make executables try and use a lower address for their program text. Executables (unlike shared libraries) aren't relocatable and thus need to be re-linked in order to use a different (lower) address...
As for the whole library discussion, that is a different animal all together and I totally agree that it can often be desirable for libraries to crash and/or not check their inputs for validity, esp. if it is expensive to do so. Some libraries can decide to check their inputs, and in general these types of functions in these libraries are considered more 'developer friendly' but this type of decision must be made on a case-by-case basis when designing a library.
I must disagree with you there, Anonymous Brave Guy. There is a difference between your library and IE. One is a library while the other is a user application. Clients of a library are other programs (code) that link to the library and make calls to it. The application programmers that use your library can be given an exact spec on 'defined' and 'undefined' usage of each of the library's functions/methods. Each and every defined usage of the library is guaranteed to produce defined (non-crashing) results. Often undefined usage of the library is EXPECTED to crash the program immediately (this can help with developer testing and debugging.. having errors not crash a program but rather propagate out far beyond an errant call is often considered undesirable because it makes debugging more difficult.)
However, full user appliations are a different story. They are expected to be ultra-robust and (ideally) crashproof. Especially mainstream 'consumer' apps like IE, which just about everyone that has ever used a computer has probably fired up once or twice in their life, if not every day.
Computer programs need to be rock-solid. They need to be able to process input (valid or invalid) indefinitely until they are stopped by the user.
For this reason this IE bug is unacceptable.