But what is ludicrous is to charge copyright fees on media and at the same time forbid making copies of copyrighted material onto those media. What exactly do I pay for, then?
If a client does not have this limitation (i.e., it is perfectly able to receive unicast BOOTREPLY messages), it SHOULD NOT set the BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0). When last I looked, IETF, not Microsoft, was king of DHCP. Well, the condition is that the implementation is perfectly able to receive unicast BOOTREPLY messages. That is, if Microsoft's implementation isn't perfect, they are not required to clear the BROADCAST flag. And given that it's from MS, it's almost a given that it is not perfect. Thus it's compliant.:-)
If that objective involves many complications (such as for an email client) because people want many calendar functions integrated with email functions and contact functions, well what do we say? You can't have that because it's not good practice? Or do we say, "Hell yes, I'm working on it."
The user wants integration at the interface level. He doesn't care the least bit how the code providing this interface is organized. Well, except when the monolithic code structure bites him, because he has e.g. to maintain his private spellings in several applications, or he can't use his calendar without an email account.
Think about it: Normal operations already involve a lot of applications. If you open an application under Linux, what you see is actually determined by at least three processes: The application process itself, the window manager process (e.g. Metacity), and X. Most people probably are not even aware of that fact, because things fit together quite seamless.
What the user cares about is that he can open his calendar from within the email application, and that data is shared between those applications where meaningful. For that, you don't need to have both in the same process. Also note that having them separate doesn't mean you cannot develop them together (I guess the first web server and the first web browser were developed together, despite the fact that they are different applications which even usually run on different computers).
The real problem with end user GUI open source code projects, such as an Exchange-Outlook replacement, is that the objective is so complicated resulting in lots of "boring" code that no one wants to really write for free.
Well, another problem should be that one would have to know Exchange-Outlook well enough to know what the users actually expect. Something which is especially unlikely for hardcore OSS people, i.e. those who'd be the most likely to write such a thing.
The one gotcha would be that the proprietary code inside the black box can't be derived from the GPL'd code in any way shape or form, otherwise it will need to be GPL'd too. The FSF has a very broad definition of derivative works such that they consider anything that is built to use an interface exclusive to a GPL'd product to be a derivative. Of course what ultimately matters is not the FSF's definition of derivative works, but the copyright law's definition, as interpreted by a judge.
That depends. The following is source code in assembler (encoded in base64, because that's the only way I could get it through the lame(ness) filter; sorry for that, but that filter is just too lame to accept disassembly!):
Note that I got that from disassembling a real (but pointless) C++ source file which compiles and runs fine. Unfortunately the instructions alone don't seem to be sufficient to re-create the file correctly; while most of it was recovered, there were some differences. You definitely wouldn't get the result through the compiler, although you could still guess what the program did.
Linux would benefit greatly from the integration of existing software. What I am thinking primarily of is SMTP. IMAP, groupware, and mail clients. These need to be tightly integrated into TWO applications similar to Outlook and Exchange. I realize there are applications out there that appear to be this, but they are really kludges of existing applications. Don't misunderstand; I like Postfix and Exim, along with the rest of the apps, and we use them now on the gateways. But I would merge all of the code and add a ton of features. One of the first features would be wireless handheld bidirectional integration. Since I'm not a developer, I can't say how this could be done. But is at the top of my wish list. We use Exchange right now, only because of the wireless handheld Blackberry integration and easy contact and calendar. So I am waiting for this to happen
Actually IMHO the solution here would be to remember the Unix tradition: Have your programs do one thing, and do that right. Ok, an email program does one thing, right? Well, no. Let's ignore that current Email programs try to be everything even remotely connected to communication (why the hell do I have to configure an Email account when all I want is to have a calendar, because I'm completely satisfied with the other email client I already use?). Even simple email today consists of several separate services: There's the communication with the server, there's local storage and management of mail, there's displaying mail, and there's things like spam filtering mail etc. Now what if I like the Evolution GUI. but consider the Thunderbird spam filter superior? (Disclaimer: That example is simply made up and should not be construed as statement about the quality of those applications) Well, I obviously have the choice if I prefer the better GUI, or the better spam filter. But why? Those parts are largely independent from each other. There should be a standardized spam filter API, and then I could mix and match any spam filter implementation with any GUI implementation.
Also, think of the spell checker. Firefox has a spell checker. OpenOffice has another spell checker. Then there's ispell. And I'm sure you'll find other applications which come with their own spell checker each. Every application has its own dictionaries. All will find different spelling errors, and if I teach a certain spelling to one app, none of the others will know it. Ideally, there would be a simple, well-developed spell checking API, which every program from Firefox to ispell would use. There could certainly be several implementations of that API, and I'd be able to select the one I like best, knowing that every application I'll use will then get that same spell checking. If I teach the spell checker a new word in OpenOffice, it will be available in Firefox as well, and if I spell-check in XEmacs, then again it will know the new word.
Note that having several programs doesn't mean no integration. For the user it doesn't matter at all if the calendar window opened comes from the email program or from a separate calendar program communicating with the email program through a standardized calendar API. From the user's view, he tells his email viewer to open a calendar window, and that calendar window appears. However, with modularity, if the user decides to use another email program tomorrow, he still can use the same calendar. He'll not even have to import the data, because it's, after all, the same application which actually manages the calendar data. Of course, he can also switch calendars if he likes another one better, without the need to learn another email interface, because he doesn't need to change the email program just to use another calendar.
And MySpace was always something for middle-aged people.
Oh, and of course Wikipedia was always the prime source of information (and the loss of the edit history in the 2017 disk crash didn't hurt too much anyway, because after all, it's obvious that facts never change, e.g. Wikipedia always had stated that the Bible was right, and that evolution is a pseudo-scientific theory that was held only by a few non-mainstream biologists of the 19th and 20th century; those people who want to prove otherwise by showing "old database dumps" are just crackpots who don't need to be taken seriously; everyone knows that such data can easily be made up by the current commonly available AI programs).
GNU/Linux finally has a total of 9000 different distros. M$ is not longer in existance. All games are created for GNU/Linux and everyones happy....:P ... except for RMS, because most people still don't say "GNU/Linux". Moreover the fact that after more than 20 years Linux still isn't GPLv3 bothers him a lot.
And Windows Vista still won't run on any existing hardware... You do know that Vista is capable of running quite well on some existing hardware, right? Your shot at Vista doesn't hold true even now, what'll make it become true in 2029? DirectX13. The one which no single graphics card manufacturer will get right.:-)
i actually figured out what the hell GPL is. Interesting. Up to now I only knew about the GNU GPL and the Affero GPL. I guess the hell GPL differs from the GNU GPL that you have not only to give away your source, but also your soul?
Sort of like after Einstein gave us E=mc2 he ceased to be of any more use.
So you think his works about specific heat, Brownian motion, stimulated emission, General Relativity and the EPR paradox are all worthless? (And no, I don't claim that list is exhaustive)
Slashdot Mirror
But what is ludicrous is to charge copyright fees on media and at the same time forbid making copies of copyrighted material onto those media. What exactly do I pay for, then?
Not to mention the vacuum cleaners. They all suck!
Well, just tell GWB that the voyagers might find hidden WMDs out there. That should ensure proper financing. :-)
To be monitored and maintained?
If you know it was stolen, wouldn't it still be illegal in the US? I'm pretty sure it would be illegal here in Germany.
The user wants integration at the interface level. He doesn't care the least bit how the code providing this interface is organized. Well, except when the monolithic code structure bites him, because he has e.g. to maintain his private spellings in several applications, or he can't use his calendar without an email account.
Think about it: Normal operations already involve a lot of applications. If you open an application under Linux, what you see is actually determined by at least three processes: The application process itself, the window manager process (e.g. Metacity), and X. Most people probably are not even aware of that fact, because things fit together quite seamless.
What the user cares about is that he can open his calendar from within the email application, and that data is shared between those applications where meaningful. For that, you don't need to have both in the same process. Also note that having them separate doesn't mean you cannot develop them together (I guess the first web server and the first web browser were developed together, despite the fact that they are different applications which even usually run on different computers).
Well, another problem should be that one would have to know Exchange-Outlook well enough to know what the users actually expect. Something which is especially unlikely for hardcore OSS people, i.e. those who'd be the most likely to write such a thing.
Well, it gives a completely new meaning to the term "uptime" ...
But it also sucks if just before landing you find out that your kernel doesn't have the right drivers for your landing airbrakes ...
Actually IMHO the solution here would be to remember the Unix tradition: Have your programs do one thing, and do that right. Ok, an email program does one thing, right? Well, no. Let's ignore that current Email programs try to be everything even remotely connected to communication (why the hell do I have to configure an Email account when all I want is to have a calendar, because I'm completely satisfied with the other email client I already use?). Even simple email today consists of several separate services: There's the communication with the server, there's local storage and management of mail, there's displaying mail, and there's things like spam filtering mail etc. Now what if I like the Evolution GUI. but consider the Thunderbird spam filter superior? (Disclaimer: That example is simply made up and should not be construed as statement about the quality of those applications) Well, I obviously have the choice if I prefer the better GUI, or the better spam filter. But why? Those parts are largely independent from each other. There should be a standardized spam filter API, and then I could mix and match any spam filter implementation with any GUI implementation.
Also, think of the spell checker. Firefox has a spell checker. OpenOffice has another spell checker. Then there's ispell. And I'm sure you'll find other applications which come with their own spell checker each. Every application has its own dictionaries. All will find different spelling errors, and if I teach a certain spelling to one app, none of the others will know it. Ideally, there would be a simple, well-developed spell checking API, which every program from Firefox to ispell would use. There could certainly be several implementations of that API, and I'd be able to select the one I like best, knowing that every application I'll use will then get that same spell checking. If I teach the spell checker a new word in OpenOffice, it will be available in Firefox as well, and if I spell-check in XEmacs, then again it will know the new word.
Note that having several programs doesn't mean no integration. For the user it doesn't matter at all if the calendar window opened comes from the email program or from a separate calendar program communicating with the email program through a standardized calendar API. From the user's view, he tells his email viewer to open a calendar window, and that calendar window appears. However, with modularity, if the user decides to use another email program tomorrow, he still can use the same calendar. He'll not even have to import the data, because it's, after all, the same application which actually manages the calendar data. Of course, he can also switch calendars if he likes another one better, without the need to learn another email interface, because he doesn't need to change the email program just to use another calendar.
Getting your full name?
And MySpace was always something for middle-aged people.
Oh, and of course Wikipedia was always the prime source of information (and the loss of the edit history in the 2017 disk crash didn't hurt too much anyway, because after all, it's obvious that facts never change, e.g. Wikipedia always had stated that the Bible was right, and that evolution is a pseudo-scientific theory that was held only by a few non-mainstream biologists of the 19th and 20th century; those people who want to prove otherwise by showing "old database dumps" are just crackpots who don't need to be taken seriously; everyone knows that such data can easily be made up by the current commonly available AI programs).
But he really wasn't killed by Oswald. He was killed by a bullet!
Yes, and providing free air will be made criminal, because it hurts the business of the bottled air producers.
Just think about what will happen if that other kid discovers copyright law and demands royalties from the first kid?
What happens to the entropy pool when bash writes its history into
Or he could have offered them to port the tracking tool to Linux. :-)
There's some heat in the 200 THz spectrum as well.
So you think his works about specific heat, Brownian motion, stimulated emission, General Relativity and the EPR paradox are all worthless? (And no, I don't claim that list is exhaustive)