Listen retard, first of all, it was my sole opinion on why FreeBSD boxes could show long uptimes. You have your opinion, I have my. I did not say "this is exactly why FreeBSD is better than Linux."
No problem. It's just that in these BSD stories, you get a lot of masturbating about how BSD is and has always been the best, and sneering at any mention of Linux or anything related to Linux. It's probably because there isn't enough traffic in this section for the angsty teenagers and elitists to vent regularly.
Take a look at any distro and you'll see that it is nothing but a kernel patched with a bunch of libraries and utilities that may or may not vary from one distribution to another.
So pick one good distribution and ignore the 100 shitty ones (including some commercial ones). If a FreeBSD fork showed up called CrapBSD and did everything wrong, could I then infer that BSD's suck because of my experience with CrapBSD?
I have no idea if an unused module can present an immediate danger; however, why the fuck would you want to have useless code to begin with?
Why the fuck would you want to maintain your own custom kernels on each machine and have to rebuild every time you have to change hardware to the vendor's chip-of-the-day?
I prefer kernel security updates in the form of nice binary packages without having to worry about a locally-maintained mess. Sure, there's a bunch of modules that I don't use and will probably never use. They take up disk space and filesystem entries. If you can think of anything else negative that their mere presence poses, I'm all ears. I happen to like being able to swap a network card with what is handed to me and not be bothered with which chip is on it.
FreeBSD and OpenBSD (do not know about NetBSD) undergo massive audition projects.
Then there are kernel security levels in additional to system run levels.
I don't know what you're talking about here. Are you referring to capabilities?
As far as I know, there are no public CVS servers avaiable for Linux users who wish to get the latest updates of their distros.
For Debian and Gentoo users there are. But who cares about CVS? I thought we were talking about servers here? I have a nice tool called cron-apt running on all of my servers to grab binary security update packages every 12 hours. The only time any of my servers reboot is for a hardware failure or new kernel. I've never been rooted (yet).
I do not feel warm and fuzzy about running beta drivers on my servers so I can notify the rest of the world about the bugs that I may find.
Where did I recommend or even suggest running a beta driver on a deployed server? Where does any Linux kernel developer recommend doing such a thing? Beta drivers are for us to beat up in our test environments, not to roll out into production without any validation. So I still don't see why it hurts to have beta drivers available for testing and feedback when they are clearly marked as such.
Perhaps if you learned to read, you'd be able to comprehend the difference between "following the development of the Linux kernel" and "loose coupling". Let me help you.
"Following the development of the Linux kernel" means that the glibc and userland people continually track changes in the Linux kernel and fix bugs or implement new features as necessary.
"loose coupling" means that Linux-related development on these tools does not cause the functionality of these tools on non-Linux platforms to be affected. Another way to put that is that the functionality of said tools does not depend on Linux, even if Linux is the target that gets the most attention these days.
My question is would you have to give the source to Bob in marketing and or the customer you gave the sample too?
Yes. Unless you want to extend them a written offer instead, which means that offer must be valid for anyone.
If I wrote a web based CMS and put it on the internet would I have to release the source code?
If you _wrote_ it (i.e. the copyright is in your name), you are not obliged to do anything. The obligation is only incurred when you redistribute a copy of others' code under the GPL. If it is someone else's web app that you are making copies of and distributing, then unless you have extra permissions from them, you have to abide by the GPL; it is the only thing that gives you the right to redistribute that particular code.
I am just wondering have they modified the GPL to cover things like web apps yet?
No, not in the way you are probably thinking of. With a web app or other thin client environment, the program is on the server side and is never distributed to the client; only a presentation layer is sent to the client. In this case, what have you distributed? Certainly the author of the CMS system cannot claim a copyright on the generated pages. And even if the CMS itself was licensed under the GPL, you are free to ignore the GPL because you are distributing no portion of it to the people accessing your site via a thin client (i.e. a web browser).
Patents are a big problem. Mike Harris has stated this numerous times on the DRI development list.
The problem is that manufacturers like ATI or NVidia feel safer legally if they release no source code and do not publish specifications for their hardware. By not doing so, a nosy competitor can't possibly notice anything in NV's hardware design or their source code that infringes on a patent owned by the competitor. If such a nosy competitor did notice something, NV would end up in court over it at significant expense, and would probably have to end up cross-licensing their own patents just for a protection deal rather than for royalties.
It's simply easier legally to keep the source closed and the specs secret. The bonus is that adopting such a policy doesn't hurt sales one bit, because consumers have shown with their wallets that they really just don't want things like driver source code or programming manuals. It's a win-win for the companies involved.
Also, remember when Matrox and 3Dfx were all about open source and NV/ATI were the nasty closed source folks? All it takes is to do a "where are they now" to see what policy a conservative company would take. Nobody got rich open sourcing their drivers and publishing their specs, and at least two companies sank or nearly sank as a correlative effect (not necessarily caused by their openness). The strategic approach is to do whatever the companies that sank didn't do, so as a result NV and ATI are as closed as can be, with the exception of ATI providing some documentation under strict NDA.
The only way to change this is to hit opencores.org and start hacking on your FPGAs. Open, extensible, capable video hardware would go a long way towards humbling the secretive industry players. Once it's designed and mockups are working, real ASIC hardware can be fabbed in quantity. The FPGA gate configuration can be made freely available with the caveat that anyone who manufactures hardware using it and distributes the hardware must pass along the "source code" for the hardware, in the form of the gate configuration as well as the host-visible registers. This wouldn't exactly fit under software licenses, but maybe some contract can be drawn up to handle it.
If a company writes an internal program and puts in on a 1000 computers do they need to release the code? If so do they only need to release the code to the employees? I would say no but others might dissagree.
Huh? You only need to provide the source code to whomever you distributed the binary to. There is nothing that obliges you to make the source code available to world+dog just because you gave a copy of the binary to Bob over in marketing or a sample to a customer. The GPL obligation only extends to those people who received copies of the binary from you.
If you elect not to give them the source and give a written offer for the source instead, that offer has to be valid for any third party. But that can be avoided by just giving them the source in the first place. Seriously, just read the GPL instead of asking these silly rhetorical questions.
Sorry, you are still missing a key reason for the existence of projects like WINE and DOSEMU.
Think proprietary business applications which talk to proprietary business hardware with binary-only drivers.
Think about running these applications and hardware on a free operating system.
Then think about using the facilities of that free operating system to reverse engineer the hardware interface from the driver.
Then think about implementing a free business application which talks to that free driver.
Suddenly the free software platform has increased in capability.
Or look at this scenario:
Proprietary application saves data in a proprietary data format.
Some curious hacker runs said application under WINE/DOSEMU and hooks the functions which write to the file.
Said hacker writes up a spec and sample programs to access that database.
Next release of OpenOffice supports opening that database natively.
Enabling this sort of development is the primary reason why these projects will not go away as long as there are people interested in promoting free platforms. People who want immediate practical benefits such as being able to play their binary-only games on a more stable and user-friendly system happen to get what they want too, as a side-effect of the more general push towards removing the chains of unsupported proprietary systems from users.
BSD development is conservative. Before new additions to the base system are available as a part of STABLE (production release), they undergo severe testing; therefore, BSDs lack a great variety of flaky drivers and questionable stuff that is all arond the Linux kernel
Yeah. Remind me of one "flaky driver" or "questionable stuff" that was recently added to a stable Linux kernel release. The 2.4 maintainer is EXTREMELY hesitant to include anything new, to the point of frustrating people (see XFS).
BSDs have a broader sense of the base system. In particular, BSD integrate kernel, libraries and some binaries together to make the base.
Give me a break. Are you familiar with GNU/Linux? Are you telling me that the development of the GNU C library and POSIX userland are not closely following the development of the Linux kernel? If it weren't for Linux, what else would they bother with? The Hurd is decades away.
You could say that the idea of a "base" where the same group of developers work on all the code provides greater coherence to the user, because you don't have different developers pulling in different directions with respect to the usability of the base system. But that is an aesthetic preference which you are pretending is a practical one.
Closer integration means more polishing; that leads to greater stability.
Please indicate what you mean by "polishing", and why it implies greater stability. My opinion is that loosely coupled code can be perfectly stable as well, if one follows proper software engineering principles in its construction.
The bonus that you get with loose coupling is a greater degree of reusability (hence, the GNU userland runs on just about every Unix-like kernel on the planet). But that in no way implies that the development of the GNU userland with respect to Linux is a second-rate effort. The fact is that Linux is where the money and the fame is today, so Linux gets first class treatment, but the aims of the GNU project ensure that other platforms are not left out in the cold.
I don't understand why the FreeBSD ideal (one kernel, one libc, one/bin) leads people to believe that FreeBSD is a superior or more flexible system than Linux/GNU. You can have your opinion, but it's not convincing in a practical sense.
If you go through the configuration file and comment out everything that you do not need, you will have a very tiny kernel. That can increase a chance of having longer uptimes.
Riiiight. And pray tell, if one built a bunch of modules but left them unused, how does this affect stability one bit compared to a kernel where the unused modules were pruned out by hand in the configuration? Sorry, I don't buy it. System stability is unrelated to code that is available but never called into.
When Linux developers try to include an absolute enormous amount of hardware support provided by default kernels, BSD developers provide only what is needed for basic functionality; that is truly a big plus.
Have it your way. I think being able to use my hardware (even with a beta-quality driver, if forewarned) and send any bugs I find upstream is "a big plus". But then again I like having useful computers, as opposed to engaging in minimalism zealotry as some seem to prefer.
Sorry, but I think you are wrong here... If a friend of mine burns a copy of Windows XP, he has violated copyright to do so, and MS could pursue him for copyright infringement.
But of course.
But, under your argument, I might say that I am allowed to use this copy of Windows XP, and make a backup copy.
Absolutely. You cannot be prosecuted for copyright infringement unless it can be shown that you willingly received an illegal copy. However, if you did know beforehand that the copy was illegal, you are then liable for conspiracy or contributory infringement.
( a) Making of Additional Copy or Adaptation by Owner of Copy. -
Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
(1)
that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner, or
(2)
that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful.
Before you can use any GPL'ed piece of software, you have to agree to the terms of the GPL. (If you don't, you don't have the right to copy the software, under copyright law).
No, you're absolutely wrong. The person who made the copy FOR you had to agree to the GPL in order to copy the software. But there is absolutely nothing that you must agree to in order to use that copy that was distributed to you. At your option, you can reject the terms of the GPL, and you have the same copying rights that default copyright law gives you - the right to make one backup copy for personal use only.
What if a lossless codec were included in the test - and it came in dead last?
I still don't understand why a lossless codec must even be considered in a survey that is comparing lossy codecs. A file compressed with a lossless codec will be indistinguishable from the uncompressed original audio files (which I assume he included for comparison, else it's a rotten test).
What I can't seem to find out is if the original file was both supplied for comparison as well as made part of the double blind test. That would be the best methodology in my opinion.
Are you done with your holier-than-thou charade yet? Imagine this -- other people just might have different needs and desires than yourself when it comes to compressing audio. That's why it's great to have choices. Comprende?
WTF? Why would you even need a listening test if codecs are lossless? By definition, lossless compression produces final sound identical to the source. If it didn't, it would be lossy.
Most developers I know don't have to make "half-assed guesses" about the language they work with, they know it.
Most developers I know learn languages as they go, because there isn't the time nor money for a formal background in any particular language. A good CS degree or software/systems engineering background tends to make the choice of language irrelevant outside of what's the appropriate tool for the job.
Of course there is the occasionally shooting yourself in the foot when inexperienced with a language or a particular implementation of a language. But that's why QA cycles are integral to solid engineering practice. Even "experts" have brain malfunctions from time to time.
All of your analogies diverge from the matter in that they include demonstrable harm to the subject. There is no demonstrable harm to you downloading spam from your mailbox on your ISP's mail server. If anything, it is the ISP who is harmed by the storage, CPU cycles, and bandwidth that is being eaten by the spam they receive. To the user, it is merely an inconvenience, like a commercial on TV or a billboard on the road. It's the ISP's machines that spammers are exploiting for their own gain, not yours. Only when someone compromises your machine directly (such as using a security vulnerability in your mailer to install spyware) can the responsibility be laid in others' hands.
The thing is, you also have a choice to use a ISP who actively polices for spam and spammers. Such an ISP will cost more (since they are not being subsidized by spammers), but the fact that you have a choice in the matter means that the claim that one is "forced" one way or the other is nothing more than whining hyperbole. Face it. Most people actively make a choice to use a bargain-basement ISP, and they get what they pay for in that regard.
As I said, they don't have to give the source code to everyone else if their proprietary modifications are used only in-house. To suggest otherwise demonstrates a fundamental misunderstanding of the GPL.
Who is forcing anything on you? You choose to use the Internet. With that choice, you accept the drawbacks as well as the advantages it brings you. I fail to see where force is even suggested in that.
What they don't like is the GPL because it doesn't give them the ability to modify the code in proprietary ways, as BSD's license does.
They can modify GPL code in as many proprietary ways as they feel like. They just can't make it available for free or for sale without either offering the source code under the GPL, or {asking,paying for} extra permissions from the copyright holder.
It's not liberal. It claims to cover any use of the software, which puts it in the class of licenses known as 'EULA', as opposed to simply being a permissive copyright license.
Why don't you just look at Linus's announcements? He does exactly what you want, summarizes what is new without going into the nitty gritty of every patch. -----
From: Linus Torvalds [email blocked] To: Kernel Mailing List [email blocked] Subject: Linux 2.6.6 Date: Sun, 9 May 2004 19:58:01 -0700 (PDT)
Ok, there it is (well, the tar-file and patches are still being up-loaded, but should be there soon).
NTFS, XFS, FAT and CIFS updates. IDE cache-flush at shutdown fixes. ppc, sparc, s390 and ARM updates (and a few x86-64 fixes).
Slashdot Mirror
I prefer kernel security updates in the form of nice binary packages without having to worry about a locally-maintained mess. Sure, there's a bunch of modules that I don't use and will probably never use. They take up disk space and filesystem entries. If you can think of anything else negative that their mere presence poses, I'm all ears. I happen to like being able to swap a network card with what is handed to me and not be bothered with which chip is on it.
http://www.debian.org/security/audit/ I don't know what you're talking about here. Are you referring to capabilities? For Debian and Gentoo users there are. But who cares about CVS? I thought we were talking about servers here? I have a nice tool called cron-apt running on all of my servers to grab binary security update packages every 12 hours. The only time any of my servers reboot is for a hardware failure or new kernel. I've never been rooted (yet). Where did I recommend or even suggest running a beta driver on a deployed server? Where does any Linux kernel developer recommend doing such a thing? Beta drivers are for us to beat up in our test environments, not to roll out into production without any validation. So I still don't see why it hurts to have beta drivers available for testing and feedback when they are clearly marked as such."Following the development of the Linux kernel" means that the glibc and userland people continually track changes in the Linux kernel and fix bugs or implement new features as necessary.
"loose coupling" means that Linux-related development on these tools does not cause the functionality of these tools on non-Linux platforms to be affected. Another way to put that is that the functionality of said tools does not depend on Linux, even if Linux is the target that gets the most attention these days.
The problem is that manufacturers like ATI or NVidia feel safer legally if they release no source code and do not publish specifications for their hardware. By not doing so, a nosy competitor can't possibly notice anything in NV's hardware design or their source code that infringes on a patent owned by the competitor. If such a nosy competitor did notice something, NV would end up in court over it at significant expense, and would probably have to end up cross-licensing their own patents just for a protection deal rather than for royalties.
It's simply easier legally to keep the source closed and the specs secret. The bonus is that adopting such a policy doesn't hurt sales one bit, because consumers have shown with their wallets that they really just don't want things like driver source code or programming manuals. It's a win-win for the companies involved.
Also, remember when Matrox and 3Dfx were all about open source and NV/ATI were the nasty closed source folks? All it takes is to do a "where are they now" to see what policy a conservative company would take. Nobody got rich open sourcing their drivers and publishing their specs, and at least two companies sank or nearly sank as a correlative effect (not necessarily caused by their openness). The strategic approach is to do whatever the companies that sank didn't do, so as a result NV and ATI are as closed as can be, with the exception of ATI providing some documentation under strict NDA.
The only way to change this is to hit opencores.org and start hacking on your FPGAs. Open, extensible, capable video hardware would go a long way towards humbling the secretive industry players. Once it's designed and mockups are working, real ASIC hardware can be fabbed in quantity. The FPGA gate configuration can be made freely available with the caveat that anyone who manufactures hardware using it and distributes the hardware must pass along the "source code" for the hardware, in the form of the gate configuration as well as the host-visible registers. This wouldn't exactly fit under software licenses, but maybe some contract can be drawn up to handle it.
If you elect not to give them the source and give a written offer for the source instead, that offer has to be valid for any third party. But that can be avoided by just giving them the source in the first place. Seriously, just read the GPL instead of asking these silly rhetorical questions.
Think proprietary business applications which talk to proprietary business hardware with binary-only drivers.
Think about running these applications and hardware on a free operating system.
Then think about using the facilities of that free operating system to reverse engineer the hardware interface from the driver.
Then think about implementing a free business application which talks to that free driver.
Suddenly the free software platform has increased in capability.
Or look at this scenario:
Proprietary application saves data in a proprietary data format.
Some curious hacker runs said application under WINE/DOSEMU and hooks the functions which write to the file.
Said hacker writes up a spec and sample programs to access that database.
Next release of OpenOffice supports opening that database natively.
Enabling this sort of development is the primary reason why these projects will not go away as long as there are people interested in promoting free platforms. People who want immediate practical benefits such as being able to play their binary-only games on a more stable and user-friendly system happen to get what they want too, as a side-effect of the more general push towards removing the chains of unsupported proprietary systems from users.
You could say that the idea of a "base" where the same group of developers work on all the code provides greater coherence to the user, because you don't have different developers pulling in different directions with respect to the usability of the base system. But that is an aesthetic preference which you are pretending is a practical one.
Please indicate what you mean by "polishing", and why it implies greater stability. My opinion is that loosely coupled code can be perfectly stable as well, if one follows proper software engineering principles in its construction.The bonus that you get with loose coupling is a greater degree of reusability (hence, the GNU userland runs on just about every Unix-like kernel on the planet). But that in no way implies that the development of the GNU userland with respect to Linux is a second-rate effort. The fact is that Linux is where the money and the fame is today, so Linux gets first class treatment, but the aims of the GNU project ensure that other platforms are not left out in the cold.
I don't understand why the FreeBSD ideal (one kernel, one libc, one /bin) leads people to believe that FreeBSD is a superior or more flexible system than Linux/GNU. You can have your opinion, but it's not convincing in a practical sense.
Riiiight. And pray tell, if one built a bunch of modules but left them unused, how does this affect stability one bit compared to a kernel where the unused modules were pruned out by hand in the configuration? Sorry, I don't buy it. System stability is unrelated to code that is available but never called into.Have it your way. I think being able to use my hardware (even with a beta-quality driver, if forewarned) and send any bugs I find upstream is "a big plus". But then again I like having useful computers, as opposed to engaging in minimalism zealotry as some seem to prefer.What I can't seem to find out is if the original file was both supplied for comparison as well as made part of the double blind test. That would be the best methodology in my opinion.
Of course there is the occasionally shooting yourself in the foot when inexperienced with a language or a particular implementation of a language. But that's why QA cycles are integral to solid engineering practice. Even "experts" have brain malfunctions from time to time.
The thing is, you also have a choice to use a ISP who actively polices for spam and spammers. Such an ISP will cost more (since they are not being subsidized by spammers), but the fact that you have a choice in the matter means that the claim that one is "forced" one way or the other is nothing more than whining hyperbole. Face it. Most people actively make a choice to use a bargain-basement ISP, and they get what they pay for in that regard.
Why don't you just look at Linus's announcements? He does exactly what you want, summarizes what is new without going into the nitty gritty of every patch.
-----
From: Linus Torvalds [email blocked]
To: Kernel Mailing List [email blocked]
Subject: Linux 2.6.6
Date: Sun, 9 May 2004 19:58:01 -0700 (PDT)
Ok, there it is (well, the tar-file and patches are still being up-loaded,
but should be there soon).
NTFS, XFS, FAT and CIFS updates. IDE cache-flush at shutdown fixes. ppc,
sparc, s390 and ARM updates (and a few x86-64 fixes).
Holler if I missed anything,
Linus
#define end }
OMFG. Are these guys for real? What's next:
#define procedure void
Or better yet := =
#define
#define = ==