Well, actually. I've always wondered if with advances in chip-making technology, we shouldn't be able to produce, say, computers with the computational power of last decade's machines, but with a tenth or even a hundredth of the power consumption. I would be very happy with a computer with the capabilities of the PCs of the late 1990s with a 20 hour battery life!
You misunderstand. Software freedom ends where the software ends. I don't really care how the hardware works, as long as I can write my own software to run on it. The idea isn't that strange: after all, we have the same thing with CPUs. I don't really know how my CPU works, but I know it groks AMD64 instructions. I'm not asking for the CPU design to be open source, it being elaborated with open source tools, etc. etc. I just want to know how to program the piece of hardware that I bought.
Of course, hardware can be useful without me knowing how to program it. In fact, there is a lot of hardware that I don't presently know how to program, yet which I still use regularly. However, it is important to recognize that not knowing how to program the hardware restricts the software it can be used with. In case of binary drivers for video cards, this means that the video card can only be used with other software the driver works with. That may be Windows, or OS X, or Linux, or even all of them, but what will it take to get the next revolutionary OS to work with that video card? The effect may be small, but proprietary interfaces stifle freedom, and therefore innovation.
``One thing to ask your self is would Apple (or other unnamed companies operating in the OS space) allow such a case of the above screen flickering, or would it be dealt with even if the X server had to be replaced (if that is the problem)''
Don't know the flicker you're referring to, but I've owned Apple computers whose screens flickered on startup, and Windows at least used to do that, too (haven't seen versions after ~2001).
Nice, another trade barrier. You can't use this protocol unless you pay $x. At least, if you live in the USA. If you live in a country where interoperability is a right, you now have documentation to help you attain it. If you live in a country where the $x barrier to entry doesn't exist or isn't enforced, you can now make your product $x cheaper than your competitors in the USA.
Interoperability: brought to you by the European Union and the People's Republic of China while companies in the USA fought expensive legal battles over chump change.
``A modern graphics card, for example, is actually a complete computer. It's got RAM, a processor, a bunch of peripherals, a complete miniature operating system... and you don't even know what type of processor it is. A lot of peripherals work like this; a wireless card is typically an ARM processor with some RAM attached on one end to the radio and on the other to an I/O controller that talks to the computer.''
The big difference here is that we usually think of as a computer typically has enough specifications published that you can program them, and there are really just a couple of flavors. By comparison, even though each wireless network card does pretty much the same things as the next one, they are usually programmed completely differently and we're not told how. We have standards and heaps of documentation when it comes to CPUs, but when it comes to graphics accelerators or wireless network cards, it's a mess of undocumented, proprietary, incompatible interfaces.
Review the code that gets checked in (you are using version control, are you?). If it doesn't obviously do what it is supposed to do (including the case where it is not obvious what it is supposed to do), something is wrong.
You can spend any amount of time writing best practices, but that doesn't ensure they are good, workable, and actually applied. In the end, what matters is if other people can understand the code. And you can measure that by just having them do that. As an added bonus, you get more people familiar with the code.
Fair enough, but just because Windows does things a certain way doesn't really say anything about whether that is good, or even acceptable, in my opinion.
``Ideally, if giving up Trytophan is beneficial with no negative side effects, they'd create a pill that prevents your body from digesting it.''
Interestingly, there are actually pills that contain tryptophan. Tryptophan is an essential amino acid and is one of the precursors to serotonine. Serotonine is a neurotransmitter, and low serotonine levels are associated with such conditions as depression and anxiety disorders. So people take extra tryptophan (or, more commonly, 5-HTP, the direct precursor to serotonine) to boost serotonine levels.
``When it comes to support in the cloud, it kind of looks like you might get what you pay for.''
Oh, please. The connection of "you get what you pay for" with support is only used to discredit whatever technology the speaker doesn't happen to like.
There are free products with great support just as there are expensive products with crappy or nonexistent support. The phrase "you get what you pay for" was widely used to discredit open-source software, but it turns out that such software is now actually preferred over commercial software in many instances. And you often get quite a lot of support that you didn't pay for if you browse the fora.
"When it comes to support, you get what you pay for" is a cheap, meaningless slingshot.
There are real disadvantages to cloud computing, but bad support isn't one of them. You get the support that the provider gives you, and that can be great or horrible, regardless of whether they charge for it and regardless of whether or not they provide cloud computing.
``It's evil to build your huge business on a technology made from community contributions, then take more than you give back while shutting down some community projects.''
I don't agree. If the license allows it, it's fair game. If you didn't want that to happen to your software, you shouldn't have released it under a license that allows it.
If you want licensees to have to make available improvements they make to your code, you may want to take a look at the Affero General Public License. This license requires modifications to be made available not only to receivers of the software, but also to people who use hosted software over a network.
I agree with the general message of your post. Supporting "Linux" with non-open source software is a lot of work.
The reason is that there really isn't such a thing as the Linux operating system. Or rather, there are hundreds if not thousands of different operating systems based on Linux. Ubuntu and OpenWRT are different operating systems just like OpenBSD and QNX are different operating systems.
In that light, I think it makes perfect sense for an organization to support, say, Fedora Core, but no other Linux distros. After all, every Linux distro they add means extra work and extra expertise and extra support capacity are required. The source code may compile without any issues on numerous other distros, but compiling the source is only part of the work. You need to test the program, integrate it with the distro, package it in the appropriate package format, have people who can help users of the distro along, etc. etc. So even though you can make a binary blob that will run on any distro of the right machine architecture that has the right libraries installed (and several companies do this), that doesn't really equate supporting all those distros.
If your software is open-source, the software can be packaged by the distro, or packages can be contributed by volunteers. If the software is not open-source, the burden on packagers is much greater, and the chances of anyone packaging it for a specific distro are correspondingly slimmer. So what you see in practice is that popular open-source software is available for practically all Unix-like systems, or at least GNU systems, but that closed-source software works only on specific hardware architectures and specific Linux distros, and not on other Linux distros, let alone the BSDs or proprietary Unices.
In my experience, a lot of these "tools that are perfect for new programmers because they don't have to learn so much" really mean that you spend a lot of time learning the tool, and _then_ have to still learn what's really happening if you ever want to make it to the level of the "old programmers", and dog forbid you are ever required to use a different tool.
To add insult to injury, the focus on the tool usually means there is so much boilerplate before you actually get to understanding the programs you write that it gets _harder_ to figure out what's really happening; you end up with "programmers" to whom programming remains some kind of black magic; they can only program things if there is a tutorial that tells them how to do it, a wizard that generates the code for them, or some sample code that they can copy paste. At best, they'll be able to glue together ready made code to make something that more or less works, but you won't find these people coming up with innovative solutions themselves, and you really don't want to let them anywhere _near_ code that requires an understanding of concurrent programming or security.
Now, I am not saying that people who start by learning a tool will never make great programmers or that people who start with a text editor and an assembler will always make great programmers. I just think that the idea that the former have an advantage over the latter is mistaken. At it's core, programming is actually not that hard. So why not let people start out by giving them a good understanding of the core, and then let them focus their energy on the hard part: translating Real World requirements to units that are trivial to implement and test?
In my opinion, a good tool is one that helps you do things you already know how to do, while not getting in the way if - for whatever reason - you want to do them yourself. No significant learning curve (you don't _have_ to use the tool's facilities), no black magic, and no breakage if you mix in code that isn't from the tool. A bad tool is one that gets in the way: requires significant effort to learn, does things you don't understand, chokes on code that doesn't fit its model, etc. A good tool doesn't make you a better programmer, just a more productive one. A bad tool doesn't make you a better programmer, either; it just provides a boost to bad programmers and cripples good programmers so both seem about equally bad.
``You might find the C/C++ crowd commonly accuse the Java or Ruby crowd of this overhead. Indeed, Java has a garbage collector designed to protect you from memory leaks''
And those who have done their homework know that garbage collection does not necessarily mean more overhead than no garbage collection.
``and Ruby is an interpreted language that pays a mild additional overhead since it cannot be optimized upon compilation.''
There is no such thing as an "interpreted language". Interpretation or compilation are properties of the implementation, not the language itself.
Also, I wouldn't classify the overhead of current Ruby implementations as "mild".
``What follows from this logic is to screw the optimizers (or 'misers, if you will) and make the servant learn the language of the master''
You mean, if you can choose between humans doing the work or computers doing the work, choose computers. Yes, this is the whole point of automation, after all.
``And yet if an implementation of a language incurs on average of 10% overhead, your hardware will catch up in a matter of months.
And yet if you run a data center the size of Google's and have several applications in said implementation running on hundreds of thousands of machines, a cycle here and a cycle there isn't so laughable to work toward saving. And isn't it the big players that ensure the lengthy life of a language and its implementations?''
Yes. This is why both the people who say "it doesn't matter that language X is slow, because, soon, computers will be faster, anyway" and the people who say "language X is slower than language Y is slow, therefore, language X is not worth using" are wrong. First of all, because they are confusing languages and implementations, and secondly, because there is room in the world for more than one programming language and more than one implementation of each.
My selection criterion is always to use the most productive language for which an implementation exists that will give you the required performance. So for a task where performance isn't overly important, you may use your favorite high-level, high-productivity language and get the job done with little effort and time. And if you need to wring every drop of performance out of your hardware, you may need to go with something low-level, like C or FORTRAN or assembly.
``The problem with Magento is not that it is too complex for a non-technical user. The problem with Magento is that is not properly documented or commented for technical users.''
So, some smart guy decided to step into the void and improve the situation, but, rather than writing documentation that is distributed with the software, he wrote a book that people have to pay for.
``why do we need a relational database to store our data? I find developing with Java / Hibernate against a relational database very time consuming and was it not that I invested so much time and effort in learning these technologies''
Eh? What does the fact that you find developing with Java and Hibernate time consuming have to do with the utility of relational databases?
I've also found developing with Java and Hibernate against relational databases time consuming, because (1) I had to learn a new framework (Hibernate), (2) developing _anything_ in Java is more time consuming than what I'm used to, and (3) I spent a lot of time tracking down performance issues and eventually solved them by bypassing Hibernate and using JDBC instead.
After all this, I am still convinced that relational databases are a good idea. Why would my experience with Java and Hibernate have changed that?
``By that logic wouldn't those same people then wait for AMD's next offering which will be yet faster?''
Well, some people actually do that. I'm waiting for the budget card that comes out with a fully functional open-source driver available. Until then, my fanless GeForce 6600 is chugging along just fine. I don't even remember what I had before that, but it was something fanless with the open-source r300 driver... a Radeon 9200 or similar.
But then, I don't buy games unless they run on Linux, either. Which usually means they have to wait until Wine supports them, and, by that time, the hardware I have is usually good enough for them, too.
Slashdot Mirror
Well, actually. I've always wondered if with advances in chip-making technology, we shouldn't be able to produce, say, computers with the computational power of last decade's machines, but with a tenth or even a hundredth of the power consumption. I would be very happy with a computer with the capabilities of the PCs of the late 1990s with a 20 hour battery life!
You misunderstand. Software freedom ends where the software ends. I don't really care how the hardware works, as long as I can write my own software to run on it. The idea isn't that strange: after all, we have the same thing with CPUs. I don't really know how my CPU works, but I know it groks AMD64 instructions. I'm not asking for the CPU design to be open source, it being elaborated with open source tools, etc. etc. I just want to know how to program the piece of hardware that I bought.
Of course, hardware can be useful without me knowing how to program it. In fact, there is a lot of hardware that I don't presently know how to program, yet which I still use regularly. However, it is important to recognize that not knowing how to program the hardware restricts the software it can be used with. In case of binary drivers for video cards, this means that the video card can only be used with other software the driver works with. That may be Windows, or OS X, or Linux, or even all of them, but what will it take to get the next revolutionary OS to work with that video card? The effect may be small, but proprietary interfaces stifle freedom, and therefore innovation.
``One thing to ask your self is would Apple (or other unnamed companies operating in the OS space) allow such a case of the above screen flickering, or would it be dealt with even if the X server had to be replaced (if that is the problem)''
Don't know the flicker you're referring to, but I've owned Apple computers whose screens flickered on startup, and Windows at least used to do that, too (haven't seen versions after ~2001).
Does that answer your question?
Nice, another trade barrier. You can't use this protocol unless you pay $x. At least, if you live in the USA. If you live in a country where interoperability is a right, you now have documentation to help you attain it. If you live in a country where the $x barrier to entry doesn't exist or isn't enforced, you can now make your product $x cheaper than your competitors in the USA.
Interoperability: brought to you by the European Union and the People's Republic of China while companies in the USA fought expensive legal battles over chump change.
``A modern graphics card, for example, is actually a complete computer. It's got RAM, a processor, a bunch of peripherals, a complete miniature operating system... and you don't even know what type of processor it is. A lot of peripherals work like this; a wireless card is typically an ARM processor with some RAM attached on one end to the radio and on the other to an I/O controller that talks to the computer.''
The big difference here is that we usually think of as a computer typically has enough specifications published that you can program them, and there are really just a couple of flavors. By comparison, even though each wireless network card does pretty much the same things as the next one, they are usually programmed completely differently and we're not told how. We have standards and heaps of documentation when it comes to CPUs, but when it comes to graphics accelerators or wireless network cards, it's a mess of undocumented, proprietary, incompatible interfaces.
With all the depressed and suicidal elderly in my country (The Netherlands), I would say that, yes, that is the case.
Review the code that gets checked in (you are using version control, are you?). If it doesn't obviously do what it is supposed to do (including the case where it is not obvious what it is supposed to do), something is wrong.
You can spend any amount of time writing best practices, but that doesn't ensure they are good, workable, and actually applied. In the end, what matters is if other people can understand the code. And you can measure that by just having them do that. As an added bonus, you get more people familiar with the code.
Actually, you might just find that eating any kind of meat in overly large quantities shortens your expected lifespan.
Fair enough, but just because Windows does things a certain way doesn't really say anything about whether that is good, or even acceptable, in my opinion.
``Ideally, if giving up Trytophan is beneficial with no negative side effects, they'd create a pill that prevents your body from digesting it.''
Interestingly, there are actually pills that contain tryptophan. Tryptophan is an essential amino acid and is one of the precursors to serotonine. Serotonine is a neurotransmitter, and low serotonine levels are associated with such conditions as depression and anxiety disorders. So people take extra tryptophan (or, more commonly, 5-HTP, the direct precursor to serotonine) to boost serotonine levels.
``Do they a tutorial on making yet another mediocre FPS ...''
I think they used to, but they accidentally it.
Will this be anything like the Be Focus Shift at all?
``When it comes to support in the cloud, it kind of looks like you might get what you pay for.''
Oh, please. The connection of "you get what you pay for" with support is only used to discredit whatever technology the speaker doesn't happen to like.
There are free products with great support just as there are expensive products with crappy or nonexistent support. The phrase "you get what you pay for" was widely used to discredit open-source software, but it turns out that such software is now actually preferred over commercial software in many instances. And you often get quite a lot of support that you didn't pay for if you browse the fora.
"When it comes to support, you get what you pay for" is a cheap, meaningless slingshot.
There are real disadvantages to cloud computing, but bad support isn't one of them. You get the support that the provider gives you, and that can be great or horrible, regardless of whether they charge for it and regardless of whether or not they provide cloud computing.
``It's evil to build your huge business on a technology made from community contributions, then take more than you give back while shutting down some community projects.''
I don't agree. If the license allows it, it's fair game. If you didn't want that to happen to your software, you shouldn't have released it under a license that allows it.
If you want licensees to have to make available improvements they make to your code, you may want to take a look at the Affero General Public License. This license requires modifications to be made available not only to receivers of the software, but also to people who use hosted software over a network.
I agree with the general message of your post. Supporting "Linux" with non-open source software is a lot of work.
The reason is that there really isn't such a thing as the Linux operating system. Or rather, there are hundreds if not thousands of different operating systems based on Linux. Ubuntu and OpenWRT are different operating systems just like OpenBSD and QNX are different operating systems.
In that light, I think it makes perfect sense for an organization to support, say, Fedora Core, but no other Linux distros. After all, every Linux distro they add means extra work and extra expertise and extra support capacity are required. The source code may compile without any issues on numerous other distros, but compiling the source is only part of the work. You need to test the program, integrate it with the distro, package it in the appropriate package format, have people who can help users of the distro along, etc. etc. So even though you can make a binary blob that will run on any distro of the right machine architecture that has the right libraries installed (and several companies do this), that doesn't really equate supporting all those distros.
If your software is open-source, the software can be packaged by the distro, or packages can be contributed by volunteers. If the software is not open-source, the burden on packagers is much greater, and the chances of anyone packaging it for a specific distro are correspondingly slimmer. So what you see in practice is that popular open-source software is available for practically all Unix-like systems, or at least GNU systems, but that closed-source software works only on specific hardware architectures and specific Linux distros, and not on other Linux distros, let alone the BSDs or proprietary Unices.
In my experience, a lot of these "tools that are perfect for new programmers because they don't have to learn so much" really mean that you spend a lot of time learning the tool, and _then_ have to still learn what's really happening if you ever want to make it to the level of the "old programmers", and dog forbid you are ever required to use a different tool.
To add insult to injury, the focus on the tool usually means there is so much boilerplate before you actually get to understanding the programs you write that it gets _harder_ to figure out what's really happening; you end up with "programmers" to whom programming remains some kind of black magic; they can only program things if there is a tutorial that tells them how to do it, a wizard that generates the code for them, or some sample code that they can copy paste. At best, they'll be able to glue together ready made code to make something that more or less works, but you won't find these people coming up with innovative solutions themselves, and you really don't want to let them anywhere _near_ code that requires an understanding of concurrent programming or security.
Now, I am not saying that people who start by learning a tool will never make great programmers or that people who start with a text editor and an assembler will always make great programmers. I just think that the idea that the former have an advantage over the latter is mistaken. At it's core, programming is actually not that hard. So why not let people start out by giving them a good understanding of the core, and then let them focus their energy on the hard part: translating Real World requirements to units that are trivial to implement and test?
In my opinion, a good tool is one that helps you do things you already know how to do, while not getting in the way if - for whatever reason - you want to do them yourself. No significant learning curve (you don't _have_ to use the tool's facilities), no black magic, and no breakage if you mix in code that isn't from the tool. A bad tool is one that gets in the way: requires significant effort to learn, does things you don't understand, chokes on code that doesn't fit its model, etc. A good tool doesn't make you a better programmer, just a more productive one. A bad tool doesn't make you a better programmer, either; it just provides a boost to bad programmers and cripples good programmers so both seem about equally bad.
In theory, we can make good computer games, too.
But how many open-source games can you name that have great graphics? And how many closed-source games with great graphics are there?
I don't think Hollywood is dying just yet.
The funny thing is, when I read the tutorial, they lost me on the "Getting Started" page.
As soon as they start with GUIs and toolbars with icons that you need to click, I don't understand what is happening anymore.
``Seems pretty roundabout... to make youtube work they needed Flash. To make Flash work they got Fedora 10 compatibly going.''
The joys of proprietary software ...
A few comments on your post:
``You might find the C/C++ crowd commonly accuse the Java or Ruby crowd of this overhead. Indeed, Java has a garbage collector designed to protect you from memory leaks''
And those who have done their homework know that garbage collection does not necessarily mean more overhead than no garbage collection.
``and Ruby is an interpreted language that pays a mild additional overhead since it cannot be optimized upon compilation.''
There is no such thing as an "interpreted language". Interpretation or compilation are properties of the implementation, not the language itself.
Also, I wouldn't classify the overhead of current Ruby implementations as "mild".
``What follows from this logic is to screw the optimizers (or 'misers, if you will) and make the servant learn the language of the master''
You mean, if you can choose between humans doing the work or computers doing the work, choose computers. Yes, this is the whole point of automation, after all.
``And yet if an implementation of a language incurs on average of 10% overhead, your hardware will catch up in a matter of months.
And yet if you run a data center the size of Google's and have several applications in said implementation running on hundreds of thousands of machines, a cycle here and a cycle there isn't so laughable to work toward saving. And isn't it the big players that ensure the lengthy life of a language and its implementations?''
Yes. This is why both the people who say "it doesn't matter that language X is slow, because, soon, computers will be faster, anyway" and the people who say "language X is slower than language Y is slow, therefore, language X is not worth using" are wrong. First of all, because they are confusing languages and implementations, and secondly, because there is room in the world for more than one programming language and more than one implementation of each.
My selection criterion is always to use the most productive language for which an implementation exists that will give you the required performance. So for a task where performance isn't overly important, you may use your favorite high-level, high-productivity language and get the job done with little effort and time. And if you need to wring every drop of performance out of your hardware, you may need to go with something low-level, like C or FORTRAN or assembly.
``The problem with Magento is not that it is too complex for a non-technical user. The problem with Magento is that is not properly documented or commented for technical users.''
So, some smart guy decided to step into the void and improve the situation, but, rather than writing documentation that is distributed with the software, he wrote a book that people have to pay for.
``Will this be another scheme wasting taxpayer dollars in lieu of parental supervison''
Yes.
``or could it actually work?''
Yes. They will claim "5 fantasillion emergency calls per month! The system is a great success!"
And then they will write in their re-election programme "Passed legislation that enhanced the safety of children."
And the suppliers of the technology will make money.
And that's all the proposal is meant to accomplish.
Perhaps, as a nice bonus, parents will feel the safety of their children has improved, too.
Real safety matters only in the mind of a small minority.
I think you have that backwards.
In the USA, The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.
In the EU, EU law has direct effect within the legal systems of its Member States, and overrides national law in many areas, especially in areas covered by the Single Market.
The Treaty establishing a Constitution for Europe would have limited the competences of the EU to only those areas voluntarily conferred to it by member states (similar to the 10th amendment of the US constitution), but the treaty was not ratified by France and the Netherlands, and therefore not implemented.
``why do we need a relational database to store our data? I find developing with Java / Hibernate against a relational database very time consuming and was it not that I invested so much time and effort in learning these technologies''
Eh? What does the fact that you find developing with Java and Hibernate time consuming have to do with the utility of relational databases?
I've also found developing with Java and Hibernate against relational databases time consuming, because (1) I had to learn a new framework (Hibernate), (2) developing _anything_ in Java is more time consuming than what I'm used to, and (3) I spent a lot of time tracking down performance issues and eventually solved them by bypassing Hibernate and using JDBC instead.
After all this, I am still convinced that relational databases are a good idea. Why would my experience with Java and Hibernate have changed that?
``By that logic wouldn't those same people then wait for AMD's next offering which will be yet faster?''
Well, some people actually do that. I'm waiting for the budget card that comes out with a fully functional open-source driver available. Until then, my fanless GeForce 6600 is chugging along just fine. I don't even remember what I had before that, but it was something fanless with the open-source r300 driver ... a Radeon 9200 or similar.
But then, I don't buy games unless they run on Linux, either. Which usually means they have to wait until Wine supports them, and, by that time, the hardware I have is usually good enough for them, too.