And there has not been any exploits for it yet unlike windows itself.
Well, that's a relief. At least the crackers can't get in through IIS then.
I don't understand why you use Windows with IIS if you know that the combination is not secure... It doesn't really matter where in the combination the hole is, now does it?
I (and probably you, too) often match all pdf files with "*pdf". However, Windows users always use "*.pdf". In fact that is more correct, I only leave out the period because there aren't any files which end in "pdf" and not in ".pdf" on my computer (usually).
However, Windows users must see that period, otherwise it means something different. A period on unix is just a normal character, a period on Windows marks the beginning of the file extension, telling them the file type. Windows users know that.
Try telling a windows user that he really should use "*", not "*.*", to mean all (not hidden) files on unix. It'll take you a few days to convince him.
The difference for them between something ending on pdf and.pdf is bigger than the difference between trust_this.exe and virus.exe. And that is Good Thing, too.
Yes, this is indeed FUD. As you can read here, the bug is fixable, even without access to the source code. The fix in this case wasn't really a nice one, but if a malicious fix can be written, then it is very likely that a good one can be written as well.
I wonder why nobody fixes the problems in the patch... The patch was open source, wasn't it? Not that I really care, I don't use Windows:-)
I wasn't talking about a dynamic linked list of tiny bits of memory. I was talking about a dynamically allocated array. Actually, you could allocate it on the stack, if it fits (and I guess it does if making it static is an option) and you'll have exactly the same situation as a static array, except that the size can be determined run-time, removing arbitrary limits.
With dynamic memory you could have to use one extra pointer deref per lookup, but even that can be omitted (if the compiler optimizes it.) You may suggest this to the compiler by telling it that the start of the dynamic memory should be held in a register.
Of course the points about speed and memory don't apply for this situation, it takes a negligible amount of extra memory (about 3 pointers per array (not per entry).)
It appears I wasn't too clear about what I meant. Sorry about that.
You can always use static arrays. But you end up with a text editor which can only handle lines of 256 characters long, or something similar. You gain a little speed, but you lose functionality.
In some cases, you should not delete the original memory, but overwrite it instead. That's not a problem, I'd say.
The point is, software design isn't easy. You can't simply follow some rules and get a good program. The GCS are helpful in reminding you of certain issues. But you should still make the choice of how to implement things, based on your situation.
What I'm saying is that arbitrary limits ("640k should be enough for everyone" kind of things) are always a Bad Thing. You should try to avoid them whenever possible.
This is an interesting point. First of all, the GCS are just a discussion of software design, not a set of rules to follow blindly. They state reasons, and if those reasons don't apply to you, then you shouldn't follow them.
But if it is indeed, as you say, impossible to use dynamic memory in real-time applications, then you have only a few possibilities:
Having arbitrary limits
This is the easiest solution, just don't care about having to increase them and recompile whenever they happen to be too small. This is not nice, and it probably wasts loads of memory because all arrays are always maximum size, but it works.
Having a separate memory management thread which allocates system memory and keeps a buffer which is known to be large enough all the time.
The process can then ask that thread for a piece of the buffer, which should react with a fairly well known timing (as long as the buffer doesn't run out.)
This sounds much nicer, but it's also much more complex, and I'm not sure if I would like to have such complexity in a real-time project.
You are right, but I wasn't saying people should always be using dynamic memory. I said you should not use static arrays if that results in an arbitrary limit. That is by far not the case for all static arrays, some are perfectly valid.
The GCS says to use whatever indentation the program you work on is using. Only if you start a new project, they say you should use their indentation. And they don't even say it's important. The important thing is that the indentation rules are the same for the whole project, and they just defined some rules.
Using C is indeed suggested, for portability reasons. But only if it is a sensible choice. They clearly state that you should use something else if the other language makes it easier for you to finish the project. They just say, that IF you have the choice between languages, and it doesn't matter much to you, then use C, because it's more portable.
I use C++ all the time. And with the STL dynamic memory is used automatically, which means most arbitrary limits don't even show up without me having to worry about them.
The GCS is a nice document which discusses important points in software design. But of course you should always do things because they're good in your situation, not because they are in those "rules".
In the original concept, no-one in our team expected... a tree wider than 6 stages. So I went for 15 in my code.
The GNU coding standards say never to use arbitrary limits. Use dynamic memory, not an array. Much harder to do? Not if you're used to it. It takes a bit of time to learn it, and after that you always write better code, without a recurring time investment. This practice works for other concepts, too. Always make them better than you think you need them, allowing all kinds of things you don't imagine.
that ignores the fact that such complex randomisations demand a whole other interface.
In that case it seems a rewrite (at least of that part of the code) may be justified. Using static arrays is still not.
I know the feeling. But it hardly ever happens anymore, and that is only because I now document every "smart" move I make. If I do something which may look weird, I write a comment about why I don't do it the other way, or that it should have been the other way, but I was too lazy to do it.
If I see something which looks like it shouldn't work, then I study it, and find out why it does, and document it. Or I study it, find out that indeed it doesn't work in some cases, document and fix it, or document that I couldn't see why it works, and that it may be buggy.
Often it will be less work to document (and thus understand) other people's work than to rewrite it. Sometimes, however, this is not possible (because the original is closed source and you're not the owner of the source) or it is clear that it's not going to help much (because the original is really really bad, for example Netscape 4). In those cases is a complete rewrite acceptable.
And of course you may want to rewrite a program which is only available as non-free software. Not because it's buggy, just because it doesn't allow others to study, change and improve it.
And I have no doubt that Microsofts motives will be questioned here.
Personally, I don't have much questions about them;-)
But I'm not sure if this is a good thing. Microsoft is not letting programmers use standards, they merely make programs that use standards anyway run on their computers. That's a big difference. I don't think they will start telling people to use portable constructs, or anything like it. that would be a Good Thing, this is just a (probably unimportant) move in their money machine.
If you actually want to do something with that machine, then you must open a connection to the evil outside world. That is a connection directly from your computer to the internet, since a masquerading host/firewall will send everything through unchecked if your host requests it. If there is an exploitable bug in the program that opens the port (say, KaZaA), than the computer you connect to can exploit it and get direct access to your computer.
Of course things are even worse if you actually want to give a service to the outside world, such as remote RPC. In that case you will specifically make a hole in the firewall, otherwise the service will not work. If I understood you well this specific hole was fixed before it was exploited, but you shouldn't count on that the next time.
In any case, if malicious code gets into your machine, a virus scanner is of course no use, because this would be a worm, not a virus, and the code which is sent over the connection would not be scanned. Only if it infects files, you have a chance to detect it, but even then it would already have had the posibility to damage your system.
Some posts in this thread seem to think that I say all this can't happen with free software. Of course it can. I just don't trust Microsoft with respect to security, and I do trust the free software movement. That means that I think free software programs have less bugs, and that they are fixed faster when found. A firewall is a good thing to have, but your programs can still open the door to crackers and worms. With free software I believe there are less doors open.
Still, I feel much better with a system where there are 100 (although I think 10000 is still a low estimate) people who care and write a fix for a bug when they find one, than something where the people who care can't fix things because they don't have the source, and the people who have the source aren't allowed by their boss to put much time in it.
Of course I'm not sure if the latter is true, but if it isn't then the coders at MS are really bad at their job, and I find that unlikely.
Waiting for bugs to be patched isn't as bad if you trust on the bug being fixed soon.;-)
I didn't plan to be trolling at all, but perhaps I was, I'm not really good at recognizing trolls:-)
You dont put a linux machine on the internet, naked to the world, do you? No, you set up a firewall, and/or you have it running behind something running a firewall and NAT.
Of course, and I expect you to do the same with your boxes, independant of what OS they are running. But I don't claim that my computers are bug-free. It would be nonsense to do that. All I say is that in the case of non-free software, the only solution to an exploitable bug usually is to block the service and wait for it to be fixed. I admit, that's what I usually do with free software as well, but I like the idea that I actually have a choice: If it's really important for me, I could just fix the bug myself.
or you just dont know what you are talking about.
My statement was that it is nonsense to claim to have a bug-free system because of good system management. And it's nonsense to claim to have a virus-immune system if you haven't seen the source (and actually, if you have seen it, too.) Those things would be very nice, but have nothing to do with system management. Unless you count choosing the right OS as system management, that is, but in that case Windows isn't quite the choice for both bug-freeness and virus immunity.
Really, you didn't convince me that I don't know what I'm talking about. I get the feeling perhaps you don't... Although it seems more like a misunderstanding. Or I could be missing the fact that you're a troll?
Hahaha, and you think that is because of good system management? System management is about fixing or working around bugs, not about not having them.
If you don't encounter any bugs, then you probably don't do much on your machine. If you don't encounter any virus on a Windows machine, then that can partly be because of good system management (running a firewall, not using Outlook or ISS), but for the rest, which is not negligible, it is just luck.
If you were actually using the remote RPC stuff, then you would have been vulnerable for the worms exploiting it, even if you are a good system administrator (so you block ports you don't use).
In other words, your argument does not make sense.
Then you could consider doing something yourself. You probably found out before that MS isn't really the place to trust when it comes to putting the customer first. How about a conclusion: Use something else.
And if you take the time to do some thinking anyway, think deeper (perhaps with a bit of help from the philosophy section on gnu.org), and conclude that only free software can give you what you want. Unless there is some strange company that actually cares more for its customers than for money... No, I can't think of one either.
doesn't PAE mode result in significant I/O performance degradation?
No, or at least on older processors it wouldn't, I don't know much about newer processor design. This is done in hardware, and it can be done in parallel with the usual work of the processor. That means it will make the processor an insignificant bit larger, but not slower.
the term "Windows" was already in generic use for over a decade before they even attempted to get a trademark in any country.
Not in Sweden or Finland.
So, how is it attempting to capitialize on goodwill to use a generic term that aplies to both products equally well?
Lindows is quite clearly not named after the english word for glass-filled holes in walls, and not even after the rectangular shapes on a computer monitor, but after a software product made by Microsoft. It is totally obvious, also from their marketing, that they mean "this product combines Linux and Windows."
with the exception of kernel code but this needs root no matter what OS
Not quite true. Of course it is technically, but to develop applications which typically live in kernel space in most operating systems, say device drivers, you don't necessarily need root. On a GNU system (with its native kernel, the Hurd, not Linux) you don't need root for this. Only to change the microkernel you would need root, but the idea of using a microkernel is that it hardly ever needs to be changed.
I don't think a judge will be impressed by that argument. TiVo seems to be within their rights, but perhaps it's not such a smart move. They may lose customers from it, while they don't lose customers from the distribution. Anyway, I'm sure they've thought about it, and they are sure allowed to make the distribution stop.
I'll skip the philosophy section of www.gnu.org, thank you very much as I am a greedy, capitalist running dog who expects to make as much money as possible off the fruit of my labor.
Too bad, you'll make my world a worse place to live. The only thing about it that you may not like is that you happen to live in that same world.
But even if you don't agree, reading what other people think about how the world would be better doesn't harm you, does it? Or are you afraid not to have any valid counterarguments? In that case you might consider joining with us, and try making the world a better place:-)
I wish you, and everyone around you a nice day. You can help that wish come true;-)
I humbly disagree. I have reviewed both my Eneterprise and Select agreements. For all intents and purposes, I own them. There are restrictions, but they can't take it back (unless I violate the restrictions).
As I am sure you understand very well, owning in this context means being able to tinker, to fix bugs, to change things if you don't like them.
nobody forces you to upgrade.
...
How many people (percentages) are still running their flavor of the version of linux that was released circa 95-96? How about since 2000?
Changing the file format so you can't read documents that other people send you is a pretty big force, I think. And how about leaving security holes wide open, not allowing anyone to fix them?
And indeed, I don't know anyone who has a GNU system (with whatever kernel) which is not fairly up to date. But with GNU (or at least with Debian), that is not a question of a system upgrade where the installation takes a day. It's comparable to running Windows update every now and then.
The fact that with Debian this results in a system which is up to date, while with Windows it merely results in not being too vulnerable simply means that Microsoft is doing something wrong (for the customer, that is. They do things very well as far as capitalism is concerned.)
Incompatible file formats? Modulo Access, Office has been compatible from 97-XP and, to my recollection, has always been forwadly compatible.
It takes time to remove forward compatibility, not to preserve it. The interesting point is if new documents open reasonably well in older versions. Read the PDF or PS specifications. They're full of notes saying how to handle undefined things. This means clients designed for version 1.0, not supporting colour, can display coloured documents very well (although without colour, of course). That is what compatibility in file formats is about.
Open Source is no saint when it comes to backward comptability either. There's no commercial requirement to do so. If it's too hard, or gets in the way of killer new functionality, the hell with backwards comptability.
Indeed, and rightfully so. But since the format is open, it is easy to write a program to convert an old file to the new format, if that would be needed. However, if backward compatibility is dropped, then it is probably either not useful to convert the files (for example the save files for a game), or it is not really possible. In the latter case, the functionality of the program changed a lot, and the new version is most probably a fork (for example gimp->filmgimp, although I don't think they broke any file format compatablity, but they could have.)
[Disclaimer: As I have stated numerous times before, I am OS-agnostic, believing in the best tool for the job]
I believe in the best tool for the job as well, but if it's not free software, then it is very unlikely to be a candidate. Note that I am one of the (few?) people who consider long term effects as well. If I use non free software, it may encourage others to do the same thing (or at least it will encourage them less not to), which is bad for the software I have at my disposal. I assumed that free software is better than non free if they are the exact same code as a fact, read the philosophy section of www.gnu.org for details if you haven't already.
Since static memory sticks have no problems with random access, it doesn't make sense to use traditional filesystems which were designed to minimize seek latency involving mechanical components.
You are right, they probably should use a filesystem which is designed to write the same spot as little as possible. However, you are wrong that FAT is designed for speed. It is designed for robustness. Moving the drive head to the first track for every file is not fast at all. However, back in the day when floppies weren't so good, it was a good idea to have the maximum magnatic material per byte for the most important sectors. That's why the boot sector, the fat and the root directory entry (which used to be the only one) are at the beginning of the disk.
And as a side note, that's also why it's not a good idea to use a fat system on a hard disk. For hard disks, as you say, minimum drive head movement is the target. Fat is lousy for that.
This is to say that their "happiness" will compensate his "despair" by mere numbers ?
Of course if you're measuring something, you try to put everything into some number, and compare that, yes.
Push it one step further and now two men may kill the third and get happier owning his posessions.
Ah, the classical argument against this compensation:-) This is exactly why I'm saying that this person being killed should be counted for more than the ones being made happy (the dead person is obviously the "poorest" in this situation). If you do that, then such a killing would result in a lower score for the three of them together.
However, if half the country would be very happy when the killing takes place, then some people argue that it should be done, and it's called a death penalty (assuming that half the country doesn't like people being killed for nothing).
I'd say that OSS movement is all about outsmarting others and collecting money
Hmm, I was thinking of RIAA tactics of suing loads of people and settling with them. I don't really want to be compared with that when I write software;-)
But anyway, you may have a point for some people at least. Personally, I write free software because I want to live in a good world, and with free software I hope to help build it. I don't get money for most of my software, and I don't mind. That's not what it's about for me. Well, as long as I have some income, that is.
Slashdot Mirror
Well, that's a relief. At least the crackers can't get in through IIS then.
I don't understand why you use Windows with IIS if you know that the combination is not secure... It doesn't really matter where in the combination the hole is, now does it?
I (and probably you, too) often match all pdf files with "*pdf". However, Windows users always use "*.pdf". In fact that is more correct, I only leave out the period because there aren't any files which end in "pdf" and not in ".pdf" on my computer (usually).
However, Windows users must see that period, otherwise it means something different. A period on unix is just a normal character, a period on Windows marks the beginning of the file extension, telling them the file type. Windows users know that.
Try telling a windows user that he really should use "*", not "*.*", to mean all (not hidden) files on unix. It'll take you a few days to convince him.
The difference for them between something ending on pdf and .pdf is bigger than the difference between trust_this.exe and virus.exe. And that is Good Thing, too.
Yes, this is indeed FUD. As you can read here, the bug is fixable, even without access to the source code. The fix in this case wasn't really a nice one, but if a malicious fix can be written, then it is very likely that a good one can be written as well.
I wonder why nobody fixes the problems in the patch... The patch was open source, wasn't it? Not that I really care, I don't use Windows :-)
I wasn't talking about a dynamic linked list of tiny bits of memory. I was talking about a dynamically allocated array. Actually, you could allocate it on the stack, if it fits (and I guess it does if making it static is an option) and you'll have exactly the same situation as a static array, except that the size can be determined run-time, removing arbitrary limits.
With dynamic memory you could have to use one extra pointer deref per lookup, but even that can be omitted (if the compiler optimizes it.) You may suggest this to the compiler by telling it that the start of the dynamic memory should be held in a register.
Of course the points about speed and memory don't apply for this situation, it takes a negligible amount of extra memory (about 3 pointers per array (not per entry).)
It appears I wasn't too clear about what I meant. Sorry about that.
You can always use static arrays. But you end up with a text editor which can only handle lines of 256 characters long, or something similar. You gain a little speed, but you lose functionality.
In some cases, you should not delete the original memory, but overwrite it instead. That's not a problem, I'd say.
The point is, software design isn't easy. You can't simply follow some rules and get a good program. The GCS are helpful in reminding you of certain issues. But you should still make the choice of how to implement things, based on your situation.
What I'm saying is that arbitrary limits ("640k should be enough for everyone" kind of things) are always a Bad Thing. You should try to avoid them whenever possible.
This is an interesting point. First of all, the GCS are just a discussion of software design, not a set of rules to follow blindly. They state reasons, and if those reasons don't apply to you, then you shouldn't follow them.
But if it is indeed, as you say, impossible to use dynamic memory in real-time applications, then you have only a few possibilities:
Having arbitrary limits
This is the easiest solution, just don't care about having to increase them and recompile whenever they happen to be too small. This is not nice, and it probably wasts loads of memory because all arrays are always maximum size, but it works.
Having a separate memory management thread which allocates system memory and keeps a buffer which is known to be large enough all the time.
The process can then ask that thread for a piece of the buffer, which should react with a fairly well known timing (as long as the buffer doesn't run out.)
This sounds much nicer, but it's also much more complex, and I'm not sure if I would like to have such complexity in a real-time project.
You are right, but I wasn't saying people should always be using dynamic memory. I said you should not use static arrays if that results in an arbitrary limit. That is by far not the case for all static arrays, some are perfectly valid.
The GCS says to use whatever indentation the program you work on is using. Only if you start a new project, they say you should use their indentation. And they don't even say it's important. The important thing is that the indentation rules are the same for the whole project, and they just defined some rules.
Using C is indeed suggested, for portability reasons. But only if it is a sensible choice. They clearly state that you should use something else if the other language makes it easier for you to finish the project. They just say, that IF you have the choice between languages, and it doesn't matter much to you, then use C, because it's more portable.
I use C++ all the time. And with the STL dynamic memory is used automatically, which means most arbitrary limits don't even show up without me having to worry about them.
The GCS is a nice document which discusses important points in software design. But of course you should always do things because they're good in your situation, not because they are in those "rules".
The GNU coding standards say never to use arbitrary limits. Use dynamic memory, not an array. Much harder to do? Not if you're used to it. It takes a bit of time to learn it, and after that you always write better code, without a recurring time investment. This practice works for other concepts, too. Always make them better than you think you need them, allowing all kinds of things you don't imagine.
In that case it seems a rewrite (at least of that part of the code) may be justified. Using static arrays is still not.
I know the feeling. But it hardly ever happens anymore, and that is only because I now document every "smart" move I make. If I do something which may look weird, I write a comment about why I don't do it the other way, or that it should have been the other way, but I was too lazy to do it.
If I see something which looks like it shouldn't work, then I study it, and find out why it does, and document it. Or I study it, find out that indeed it doesn't work in some cases, document and fix it, or document that I couldn't see why it works, and that it may be buggy.
Often it will be less work to document (and thus understand) other people's work than to rewrite it. Sometimes, however, this is not possible (because the original is closed source and you're not the owner of the source) or it is clear that it's not going to help much (because the original is really really bad, for example Netscape 4). In those cases is a complete rewrite acceptable.
And of course you may want to rewrite a program which is only available as non-free software. Not because it's buggy, just because it doesn't allow others to study, change and improve it.
I always thought that if there were two conditions which are both both necessary and sufficient, then they must be equal.
Personally, I don't have much questions about them ;-)
But I'm not sure if this is a good thing. Microsoft is not letting programmers use standards, they merely make programs that use standards anyway run on their computers. That's a big difference. I don't think they will start telling people to use portable constructs, or anything like it. that would be a Good Thing, this is just a (probably unimportant) move in their money machine.
If you actually want to do something with that machine, then you must open a connection to the evil outside world. That is a connection directly from your computer to the internet, since a masquerading host/firewall will send everything through unchecked if your host requests it. If there is an exploitable bug in the program that opens the port (say, KaZaA), than the computer you connect to can exploit it and get direct access to your computer.
Of course things are even worse if you actually want to give a service to the outside world, such as remote RPC. In that case you will specifically make a hole in the firewall, otherwise the service will not work. If I understood you well this specific hole was fixed before it was exploited, but you shouldn't count on that the next time.
In any case, if malicious code gets into your machine, a virus scanner is of course no use, because this would be a worm, not a virus, and the code which is sent over the connection would not be scanned. Only if it infects files, you have a chance to detect it, but even then it would already have had the posibility to damage your system.
Some posts in this thread seem to think that I say all this can't happen with free software. Of course it can. I just don't trust Microsoft with respect to security, and I do trust the free software movement. That means that I think free software programs have less bugs, and that they are fixed faster when found. A firewall is a good thing to have, but your programs can still open the door to crackers and worms. With free software I believe there are less doors open.
Still, I feel much better with a system where there are 100 (although I think 10000 is still a low estimate) people who care and write a fix for a bug when they find one, than something where the people who care can't fix things because they don't have the source, and the people who have the source aren't allowed by their boss to put much time in it.
Of course I'm not sure if the latter is true, but if it isn't then the coders at MS are really bad at their job, and I find that unlikely.
Waiting for bugs to be patched isn't as bad if you trust on the bug being fixed soon. ;-)
I didn't plan to be trolling at all, but perhaps I was, I'm not really good at recognizing trolls :-)
Of course, and I expect you to do the same with your boxes, independant of what OS they are running. But I don't claim that my computers are bug-free. It would be nonsense to do that. All I say is that in the case of non-free software, the only solution to an exploitable bug usually is to block the service and wait for it to be fixed. I admit, that's what I usually do with free software as well, but I like the idea that I actually have a choice: If it's really important for me, I could just fix the bug myself.
My statement was that it is nonsense to claim to have a bug-free system because of good system management. And it's nonsense to claim to have a virus-immune system if you haven't seen the source (and actually, if you have seen it, too.) Those things would be very nice, but have nothing to do with system management. Unless you count choosing the right OS as system management, that is, but in that case Windows isn't quite the choice for both bug-freeness and virus immunity.
Really, you didn't convince me that I don't know what I'm talking about. I get the feeling perhaps you don't... Although it seems more like a misunderstanding. Or I could be missing the fact that you're a troll?
the computers dont get viruses or bugs
Hahaha, and you think that is because of good system management? System management is about fixing or working around bugs, not about not having them.
If you don't encounter any bugs, then you probably don't do much on your machine. If you don't encounter any virus on a Windows machine, then that can partly be because of good system management (running a firewall, not using Outlook or ISS), but for the rest, which is not negligible, it is just luck.
If you were actually using the remote RPC stuff, then you would have been vulnerable for the worms exploiting it, even if you are a good system administrator (so you block ports you don't use).
In other words, your argument does not make sense.
Then you could consider doing something yourself. You probably found out before that MS isn't really the place to trust when it comes to putting the customer first. How about a conclusion: Use something else.
And if you take the time to do some thinking anyway, think deeper (perhaps with a bit of help from the philosophy section on gnu.org), and conclude that only free software can give you what you want. Unless there is some strange company that actually cares more for its customers than for money... No, I can't think of one either.
doesn't PAE mode result in significant I/O performance degradation?
No, or at least on older processors it wouldn't, I don't know much about newer processor design. This is done in hardware, and it can be done in parallel with the usual work of the processor. That means it will make the processor an insignificant bit larger, but not slower.
the term "Windows" was already in generic use for over a decade before they even attempted to get a trademark in any country.
Not in Sweden or Finland.
So, how is it attempting to capitialize on goodwill to use a generic term that aplies to both products equally well?
Lindows is quite clearly not named after the english word for glass-filled holes in walls, and not even after the rectangular shapes on a computer monitor, but after a software product made by Microsoft. It is totally obvious, also from their marketing, that they mean "this product combines Linux and Windows."
Not quite true. Of course it is technically, but to develop applications which typically live in kernel space in most operating systems, say device drivers, you don't necessarily need root. On a GNU system (with its native kernel, the Hurd, not Linux) you don't need root for this. Only to change the microkernel you would need root, but the idea of using a microkernel is that it hardly ever needs to be changed.
I don't think a judge will be impressed by that argument. TiVo seems to be within their rights, but perhaps it's not such a smart move. They may lose customers from it, while they don't lose customers from the distribution. Anyway, I'm sure they've thought about it, and they are sure allowed to make the distribution stop.
Too bad, you'll make my world a worse place to live. The only thing about it that you may not like is that you happen to live in that same world.
But even if you don't agree, reading what other people think about how the world would be better doesn't harm you, does it? Or are you afraid not to have any valid counterarguments? In that case you might consider joining with us, and try making the world a better place :-)
I wish you, and everyone around you a nice day. You can help that wish come true ;-)
As I am sure you understand very well, owning in this context means being able to tinker, to fix bugs, to change things if you don't like them.
Changing the file format so you can't read documents that other people send you is a pretty big force, I think. And how about leaving security holes wide open, not allowing anyone to fix them?
And indeed, I don't know anyone who has a GNU system (with whatever kernel) which is not fairly up to date. But with GNU (or at least with Debian), that is not a question of a system upgrade where the installation takes a day. It's comparable to running Windows update every now and then.
The fact that with Debian this results in a system which is up to date, while with Windows it merely results in not being too vulnerable simply means that Microsoft is doing something wrong (for the customer, that is. They do things very well as far as capitalism is concerned.)
It takes time to remove forward compatibility, not to preserve it. The interesting point is if new documents open reasonably well in older versions. Read the PDF or PS specifications. They're full of notes saying how to handle undefined things. This means clients designed for version 1.0, not supporting colour, can display coloured documents very well (although without colour, of course). That is what compatibility in file formats is about.
Indeed, and rightfully so. But since the format is open, it is easy to write a program to convert an old file to the new format, if that would be needed. However, if backward compatibility is dropped, then it is probably either not useful to convert the files (for example the save files for a game), or it is not really possible. In the latter case, the functionality of the program changed a lot, and the new version is most probably a fork (for example gimp->filmgimp, although I don't think they broke any file format compatablity, but they could have.)
I believe in the best tool for the job as well, but if it's not free software, then it is very unlikely to be a candidate. Note that I am one of the (few?) people who consider long term effects as well. If I use non free software, it may encourage others to do the same thing (or at least it will encourage them less not to), which is bad for the software I have at my disposal. I assumed that free software is better than non free if they are the exact same code as a fact, read the philosophy section of www.gnu.org for details if you haven't already.
You are right, they probably should use a filesystem which is designed to write the same spot as little as possible. However, you are wrong that FAT is designed for speed. It is designed for robustness. Moving the drive head to the first track for every file is not fast at all. However, back in the day when floppies weren't so good, it was a good idea to have the maximum magnatic material per byte for the most important sectors. That's why the boot sector, the fat and the root directory entry (which used to be the only one) are at the beginning of the disk.
And as a side note, that's also why it's not a good idea to use a fat system on a hard disk. For hard disks, as you say, minimum drive head movement is the target. Fat is lousy for that.
This is to say that their "happiness" will compensate his "despair" by mere numbers ?
Of course if you're measuring something, you try to put everything into some number, and compare that, yes.
Push it one step further and now two men may kill the third and get happier owning his posessions.
Ah, the classical argument against this compensation :-) This is exactly why I'm saying that this person being killed should be counted for more than the ones being made happy (the dead person is obviously the "poorest" in this situation). If you do that, then such a killing would result in a lower score for the three of them together.
However, if half the country would be very happy when the killing takes place, then some people argue that it should be done, and it's called a death penalty (assuming that half the country doesn't like people being killed for nothing).
I'd say that OSS movement is all about outsmarting others and collecting money
Hmm, I was thinking of RIAA tactics of suing loads of people and settling with them. I don't really want to be compared with that when I write software ;-)
But anyway, you may have a point for some people at least. Personally, I write free software because I want to live in a good world, and with free software I hope to help build it. I don't get money for most of my software, and I don't mind. That's not what it's about for me. Well, as long as I have some income, that is.