One of the major selling points of GNU/Linux and the rest of Open Source Software is that it's FREE as in speech, not beer.
Harping on about TCO, in _money_ terms is not addressing some of the concerns that some big business' have about using Microsoft's (and other closed source) software. It's about vendor freedom, freedom to choose and change the software. Freedom to customize software on an organization's own terms.
As the City of Munich's decision demonstrated when they chose a more expensive Linux package over Microsoft's, it aint necessarily about cash!
OSDL analysis or not, favouring Linux or not, we might just find that TCO isn't all that relevant anyway.
I used to think that because all devs released their binaries as RPM that RPM distros were the way to go too. I've since learned that they don't bother releasing DEBs because somebody's already maintaining a DEB package for them already, and it's in the Debian/Ubuntu/* repository.
Devs only release their RPMs because Redhat won't host them.
When considering optimizing software, the first thing you should do is get metrics, use a profiler, find out exactly what's slow, and what needs to be fast.
It seems to me that before *optimising* the Debian release strategy, either by removing architectures and/or shortening the release cycle, one should consider the metrics: * How many servers/workstations use stable, testing and unstable (and for what reasons). * How many users of each architecture are there? (and for each of stable/testing/unstable)
With this information, the Debian crew can make informed decisions on where their focus should be, what needs to be fixed, and who for. We might find, for example, that Debian stable (as it stands) is used quite heavily, and to keep good support for it (call it "really-stable" or something). We might also find that the majority of Sid users are on x86/PPC/AMD64 and to scrap support for other architectures in Sid.
And what's missing from the analysis is that even though there's no money in *writing* open source, there's plenty to be made in implementing and maintaining open-source based solutions.
Precisely! The *money* in open source moves up the stack, into applications, maintenance, assembly, implementation etc; whereever there's something that's "Not good enough". In the open source software world the "Not good enough" area at the moment is not the software itself, but in configuring, assembling and maintaining installations of open source software.
But, back to the article: Torvalds wisely stated that *developers* looking getting into open source software shouldn't do it for the money, because very few people actually make money out of *developing* open source software. He never mentioned that you couldn't make money from *using* (configuring, assembling, etc) open source software.
I'm not sure that the differences in phylosophy between CLI and GUI can be so easily identified as this. As usual, things are a lot more complicated.
It all comes down to how best to represent the underlying concepts. An extremely flexible way to represent concepts is to describe them using a natural language (like English), but almost always English is overkill, and can often be ambiguous and cumbersome. This is where Mathematicians start to invent notations for certain mathematical concepts like algebra, matrices and so on. These notations can concisely represent instances of these concepts without being ambiguous or verbose. Many other languages and notations have been invented for the many other concepts and calculuses used with computers. One such language is C, another Haskell, and another Bash or TCSH.
Graphical User Interfaces might be viewed as the odd man out here, but they also have cousins like UML (which is also graphical), paint programs like GIMP and Photoshop, and WYSIWIG document editing, among many others. Each of these were designed to best represent their respective underlying concepts, and each have a place and a job to do.
The problem with the standard GUI notation & widgetry is that it is highly overused. This is probably because it was such a good idea in the first place - it's just that some movers and shakers in the IT industry have used it as a silver bullet for all UIs. This is a short sighted, but not surprising. Many of us have become so accusomed to the mighty GUI that it becomes very difficult to think of UI without it. To think what's outside of the box is difficult when you've been living in it for so long.
Slashdot Mirror
Again, Apple just show how innovative they can be...
If it's get ridiculous enough and enough people care about, it will change.
Lessig obviously thinks it's ridiculous enough, he's just trying to get enough people to care about it. And then, with good fortune, it will change.
Go read some of what he says and maybe you'll care too.
One of the major selling points of GNU/Linux and the rest of Open Source Software is that it's FREE as in speech, not beer.
Harping on about TCO, in _money_ terms is not addressing some of the concerns that some big business' have about using Microsoft's (and other closed source) software. It's about vendor freedom, freedom to choose and change the software. Freedom to customize software on an organization's own terms.
As the City of Munich's decision demonstrated when they chose a more expensive Linux package over Microsoft's, it aint necessarily about cash!
OSDL analysis or not, favouring Linux or not, we might just find that TCO isn't all that relevant anyway.
I used to think that because all devs released their binaries as RPM that RPM distros were the way to go too. I've since learned that they don't bother releasing DEBs because somebody's already maintaining a DEB package for them already, and it's in the Debian/Ubuntu/* repository. Devs only release their RPMs because Redhat won't host them.
When considering optimizing software, the first thing you should do is get metrics, use a profiler, find out exactly what's slow, and what needs to be fast.
It seems to me that before *optimising* the Debian release strategy, either by removing architectures and/or shortening the release cycle, one should consider the metrics:
* How many servers/workstations use stable, testing and unstable (and for what reasons).
* How many users of each architecture are there? (and for each of stable/testing/unstable)
With this information, the Debian crew can make informed decisions on where their focus should be, what needs to be fixed, and who for. We might find, for example, that Debian stable (as it stands) is used quite heavily, and to keep good support for it (call it "really-stable" or something). We might also find that the majority of Sid users are on x86/PPC/AMD64 and to scrap support for other architectures in Sid.
Who can say until we have the metrics.
And what's missing from the analysis is that even though there's no money in *writing* open source, there's plenty to be made in implementing and maintaining open-source based solutions.
Precisely! The *money* in open source moves up the stack, into applications, maintenance, assembly, implementation etc; whereever there's something that's "Not good enough". In the open source software world the "Not good enough" area at the moment is not the software itself, but in configuring, assembling and maintaining installations of open source software.
But, back to the article: Torvalds wisely stated that *developers* looking getting into open source software shouldn't do it for the money, because very few people actually make money out of *developing* open source software. He never mentioned that you couldn't make money from *using* (configuring, assembling, etc) open source software.
I'm not sure that the differences in phylosophy between CLI and GUI can be so easily identified as this. As usual, things are a lot more complicated.
It all comes down to how best to represent the underlying concepts. An extremely flexible way to represent concepts is to describe them using a natural language (like English), but almost always English is overkill, and can often be ambiguous and cumbersome. This is where Mathematicians start to invent notations for certain mathematical concepts like algebra, matrices and so on. These notations can concisely represent instances of these concepts without being ambiguous or verbose. Many other languages and notations have been invented for the many other concepts and calculuses used with computers. One such language is C, another Haskell, and another Bash or TCSH.
Graphical User Interfaces might be viewed as the odd man out here, but they also have cousins like UML (which is also graphical), paint programs like GIMP and Photoshop, and WYSIWIG document editing, among many others. Each of these were designed to best represent their respective underlying concepts, and each have a place and a job to do.
The problem with the standard GUI notation & widgetry is that it is highly overused. This is probably because it was such a good idea in the first place - it's just that some movers and shakers in the IT industry have used it as a silver bullet for all UIs. This is a short sighted, but not surprising. Many of us have become so accusomed to the mighty GUI that it becomes very difficult to think of UI without it. To think what's outside of the box is difficult when you've been living in it for so long.