WINE is an open API that runs on a number of unix platforms. They compiled the game with a relatively small number of changes against this other open API.
Would you rather they spent an inordinate amount of extra time and resources porting the game to SDL and other APIs to make a game that runs like the current one does? What worthwhile difference does it make to you whether the game uses the WINE or SDL API?
You might have got to say, 'this game uses SDL', while the porting company could have ported another few games in the same time and had a better chance of surviving. And in the process you would have even more games to play natively in Linux.
Why would a gaming company put money in porting it, Linux users _can_ play their game.
Because now they can do it far more cheaply by recompiling their games for winelib with relatively few changes. And they'll be using an open *nix application API: WINE.
There may be very few Linux users, but if it is very cheap to produce a native (in a compiled-for sense) Linux game then with a slick installer that sells, then it may still be worth it for the publisher.
WINE lowers the barrier to entry for game companies to Linux.
com1, com2, com3, lpt1, etc... are special ('virtual'?) files in Windows for referencing serial and parallel ports, therefore you can't create a 'real' file or directory with that name.
Note: my reply is not specifically about Perl, but about the concepts embodied in the parent post. I do not have enough experience to comment on Perl.
It's one of the language's strongest suits. And it closely approximates a typical spoken language, like English.
So it is easy to be ambiguous to the reader? How is this a good thing when maintaining a program?
Where you see piled-on hacks, I see evolution at work. Perl is richly expressive, and allows you to code in whatever style works best for the task at hand, rather than trying to force the solution-space of the problem into the modeling-space of the language.
That is not the problem. The problem is where you have a few equally good ways of solving a solution, that as a whole detract from the language because of the need to learn and decide between a number of them. Also the need to learn all of them because other people have used different solutions to you.
If you have a computing problem that cannot be cleanly solved by a current language because it uses different concepts you can create a language that is domain specific.
That's why Java and other B&D languages suck so badly - they trade flexability for orthadoxy.
Why is orthadoxy bad? Does it not waste enough resources for you? Being creative in producing new and better algorithms I think is good. Being creative in producing slightly new ways to produce the old algorithms and programs is just a waste I think.
But spoken languages have proven to be stubbornly resistant to the imposition of bondage and discipline in the name of "simplicity", and attempts at creating new, simpler spoken languages from scratch - like Esperanto - have failed miserably. The parallel with programming language should hold true as well. What is a programming language but a way of communicating with your computer, your users, and other programmers?
It should be at least as expressive as your spoken tongue, not less.
The purpose of a language is to communicate. Spoken languages are extremely expressive because they need to express a massive range of things. A computer only has an extremely limited range of concepts that it can understand, so languages for a computer only need to be able to express a limited range of concepts. This is why C only has about 30 keywords, yet it is extrememly useful in the domain of computing, and also why I think the previous two paragraphs are false in the conclusions that they are trying to reach.
A programming language is generally not used to communicate with your users. This would be like saying the metal ore you use in creating the spanner is being used by the tool company to communicate with the mechanic.
At the moment, the reason that new spoken languages have not take root is not because they are simpler. Reasons I can think of are:
invested time in learning old language
current user base
dificulty of learning a new language (even a simple new language for humans would be complex)
culture
While a programming language that allows you multiple ways of doing the same thing will allow you to program in the style that you currently think, probably improving efficiency for you, this style is almost certainly not the same as other programmers. Furthermore if you learn and improve, it is unlikely that it will stay the same for you either. You have basically said the equivalent of: more languages and dialects on the earth increase the ease of communication between people. Actually reducing the number of languages is what is needed to help communication between people because people can now read your code without having to invest time in learning a new language/dialect and your way of thinking.
"A foolish consistancy is the hobgoblin of little minds" and nothing illustrates that point better than a discussion of Perl by those who don't actually use it.
Please note the word 'foolish'.
I think you have taken a stand on simplicity vs. creativity (complexity) in the subject of computer languages without evalutating the consequences.
I think code readability is a product of being concise and keeping things simple. At a certain point, increasing the concision of code increases complexity (by removing obvious meaning about what the code is trying to accomplish).
For example, the following includes explicit information that tells the reader that a choice is being made:
Almost every single time I try to install an X-based program it chokes because I'm missing some library or another. In fact more than once I have tried to run a program and it says that I am missing a library that I already have!
I think this is a distribution problem rather than a problem intrinsic to dynamicaly linked executables.
Its also one of the reasons I run debian (the new 'versions' - not the last official stable release). If you're running an RPM based distro and if apt-rpm is anything near as good as what I've seen on debian then try that - you'll never look back. If you're running Mandrake I think you should already have an equivalent in urpmi. Any troubles you have are then down to Mandrake's packaging.
This is especially a problem with any audio/video software, and it's all because of staticly linked libraries.
I think you mean 'dynamically linked libraries'. Dynamically linked libraries are where the library is in a seperate file to the program. This is the normal method in both Windows and Linux (and I assume most other Unices).
Statically linked libraries are where the library is included in the program.
Statically linking is not a waste when you consider the cheapness and size of today's storage solutions.
This is so easy to say when you have money.
Additionally, you get a performance increase with statically linked libraries
If you were to only ever run one program you would get a performance increase. But say you decided to statically link glibc into all your programs. Every time you run a program you have to load the copy of glibc statically linked into your program from disk, instead of just using the dynamic version that has already been loaded into memory. Reading from disk when loading a program degrades performance (far more than dynamically resolving libraries, as far as I can see).
That said, you are probably right about the expediency of bug fixes through libraries. Still, when you consider the rapid pace of development of some projects, I think this isn't as much of an issue as you might think it is.
Wouldn't it exacerbate the issue? With a faster development of projects more libraries would get updated more often and more packages would need to be downloaded.
Furthermore bandwidth is not nearly as widely available or cheap as storage. Have you seen the dependancy list for a library like glibc or zlib? Can you imagine having to re-download large parts of, or your entire distro whenever these get a critical security or bug fix? All that updating of programs with statically compiled libs will bulk up the packages a 'little' too.
When a distribution's installation hinges on the installation of the Perl RPM, for example, you are virtually guaranteeing that you will break something and potentially assfuck your system if you remove or don't install the Perl package in favor of compiling from a tarball.
Possible solution: Can't you install the new version of perl you want to a different path/prefix and make sure that these appear before any standard paths in the environments you want to use this version of perl?
I've tried garnome (http://www.gnome.org/~jdub/garnome/), and its worked really well for me. (I don't know if its been fixed now, but you may have to copy a glade-convert script - although probably not exactly that name - to a bin directory at some point.)
I use Debian, and while testing Gentoo next to it I find that I am capable of burning a CD-R by using 'cdrecord dev=ATAPI:0,0,0 speed=16 -v' (have to figure out how to enable BurnFREE someday)... under Debian, I still can't get it to recognize a standard ATAPI burner!
Pass the parameter hdx=ide-scsi to the kernel when it boots, where hdX is your ATAPI cd-r drive.
Load the ide-scsi module on boot and I *think* the scsi cdrom module (sr_mod?).
You should now be able to access your ATAPI cd-r drive as a scsi drive (/dev/scdX, X being a number) and details of the drive should appear in/proc/scsi/scsi (or a file named like that).
(I don't have my Linux box handy, therefore lots of 'I think').
I don't know whether it would be so hard for programs to have a font selection thing that let you choose them similar to the way Windows does it and then translates the selections into X's standard font naming format. It could be made into a widget, or mebbe a library with a widget built on top of it. Something like that.
How can you state what people in the US want? You, judging from the your article, come from a country with 50 states, all of which are equivalent or larger in size than a not insignicant number of other countries, which contains a large and diverse population. I don't see how you can make the statements that you did about a population like that.
Not everyone wants to know what is happening. And people do blindly believe what the media tells them.
I think you were annoyed at blanket statements made against the US (that sounds like racist stereotyping from outsiders). A more useful response would have been something to the effect that, there are people in the US that do question and care about the validity of what the media reports - and also englighten us 'foreigners' about news sources in the US that are less sensational and more thoughtful than some of the mainstream US reporting we see from outside.
While religion has occasionally been used as an excuse for horrible acts, it is much more often provides hope, stability and ethical values to work from (I think many of these values from major religions would be considered a good thing by most people).
You really have to look at individuals, communities and people (small things - often hard to see) to see where religions really works well.
I think the age limits have at least as much to do with what harm you can cause to others, as with what harm you can do to yourself.
I guess the expectation is that in general people are significantly more responsible and less likely to cause harm to others and themselves due to alcohol at 21, than at 18.
It also reduces the chance of situations such as inexperienced drivers under the influence of alcohol.
There have been a few replies to this thread trying to explain why there seems to be little good art, compared with code. How about this for a possible answer (I know that contained within are sweeping generalisations):
Free/Open source has not reached great penetration onto the desktop and general use, and mostly attracts programmers, heavy duty and/or highly technically literate computer users at the moment (the people for which the advantages are most relevant to).
Artists are generally not programmers and tend not to be highly technically literate, or care excessively about the freedom of the software they use.
There are few high quality graphics programs for Free/Open source systems.
Artists are generally satisfied, and possibly fanatically loyal to their current desktop system.;-)
So the set of people who are artists does not intersect by a great amount with the set of OSS/Free software users.
Which could be why you see a disproportionate amount of good code, to good art.
I remember recently reading about a signal booster in an electronics magazine (CPC in the UK) that had a little note next to the product description saying in effect it would circumvent Macrovision. I think the effect was unintentional. I have no idea of the resultant quality though.
In GTK (the version used in Gnome 1.4 and I think in Gnome 1.2) you can select text with the right mouse button. This text is not copied, but it is replaced when you paste text using the middle mouse button (it is highlighted in gray rather than blue, with the default theme).
Reading through the comments, has caused me to fire off some "practically" random thoughts:
The better the compression ratio, the smaller the data set that can be compressed to this size is.
One piece of random data is not the worst case, as it may represent the best case for a compression ratio.
The average compression ratio for a fixed length of random data in general is not the worst case for an algorithm, but merely the average compression ratio for the algorithm over all data sets.
Algorithms and formulae contain a lot of information, much/most of it implied. e.g. the addition operator has an implied meaning, which when fully stated takes up much more space than '+'.
The statment "Cyan, magenta and yellow are primary colours in negative colour mixing." implies lots of information about the structure of our eyes and of light. The amount of information that is implied increases as the readers understanding of the words grow.
If the universe is built on a few small pieces of information, then maybe everything has patterns coming from these that allow it to be compressed back to something very small in size.
Small excercise I thought through:
100:1 compression ratio on 1000 bits:
1000 bits have 2^1000 combinations.
10 bits have 2^10 combinations.
So each combination of 10 bits would need to represent 2^100 combinations of 1000 bits.
BUT, say we have 2^100 compression algorithms, each are optimal at compressing 2^100 seperate patterns of 1000 bits of data to 100 bits. The patterns do not overlap.
We add 100 bits to the compressed data to tell us which algorithm to choose. Therefore final compressed data becomes: 110 bits long.
New compression ratio is:
1000/110 = 9.1 (1 d.p.)
This can be achieved on any 1000 bits we have. 9.1:1 compression is a pretty good general compression ratio for all cases.
BIG PROBLEM: compressor/decompressor would need knowledge of each algorithm. If each algortihm only took up 1 byte, 1,125,899,906,842,624 Petabytes of storage would be needed.
Suicidal optimism: There may be one algorithm that can generate all these other algorithms from a very small data set though.
Re:Issues with the euro in day-to-day life
on
The Euro
·
· Score: 1
'European' kids? I'm not too sure if there is such an entity. Probably a little like me (England) saying "you kids from the continents west of me".
Abiword is cross platform application using native widgets (GTK on Unix). You might want to have a look at how they did it. They must have sorted out cross platform printing as well and some other none GUI issues.
There is already a working GTK2 port to win32. I've got the libraries and used an application based on it (of course this includes, glib, pango, etc.)
Look for a Win32 Radeon tweaker on sourceforge and its got links (at least the install programs has) to the precompiled Win32 dlls for a prerelease GTK2.
Slashdot Mirror
'ported' is the right term.
WINE is an open API that runs on a number of unix platforms. They compiled the game with a relatively small number of changes against this other open API.
Would you rather they spent an inordinate amount of extra time and resources porting the game to SDL and other APIs to make a game that runs like the current one does? What worthwhile difference does it make to you whether the game uses the WINE or SDL API?
You might have got to say, 'this game uses SDL', while the porting company could have ported another few games in the same time and had a better chance of surviving. And in the process you would have even more games to play natively in Linux.
Why would a gaming company put money in porting it, Linux users _can_ play their game.
Because now they can do it far more cheaply by recompiling their games for winelib with relatively few changes. And they'll be using an open *nix application API: WINE.
There may be very few Linux users, but if it is very cheap to produce a native (in a compiled-for sense) Linux game then with a slick installer that sells, then it may still be worth it for the publisher.
WINE lowers the barrier to entry for game companies to Linux.
I think the point implied is that the GUI has regressed in OSX, even if it looks more colourful.
com1, com2, com3, lpt1, etc... are special ('virtual'?) files in Windows for referencing serial and parallel ports, therefore you can't create a 'real' file or directory with that name.
Note: my reply is not specifically about Perl, but about the concepts embodied in the parent post. I do not have enough experience to comment on Perl.
It's one of the language's strongest suits. And it closely approximates a typical spoken language, like English.
So it is easy to be ambiguous to the reader? How is this a good thing when maintaining a program?
Where you see piled-on hacks, I see evolution at work. Perl is richly expressive, and allows you to code in whatever style works best for the task at hand, rather than trying to force the solution-space of the problem into the modeling-space of the language.
That is not the problem. The problem is where you have a few equally good ways of solving a solution, that as a whole detract from the language because of the need to learn and decide between a number of them. Also the need to learn all of them because other people have used different solutions to you.
If you have a computing problem that cannot be cleanly solved by a current language because it uses different concepts you can create a language that is domain specific.
That's why Java and other B&D languages suck so badly - they trade flexability for orthadoxy.
Why is orthadoxy bad? Does it not waste enough resources for you? Being creative in producing new and better algorithms I think is good. Being creative in producing slightly new ways to produce the old algorithms and programs is just a waste I think.
But spoken languages have proven to be stubbornly resistant to the imposition of bondage and discipline in the name of "simplicity", and attempts at creating new, simpler spoken languages from scratch - like Esperanto - have failed miserably. The parallel with programming language should hold true as well. What is a programming language but a way of communicating with your computer, your users, and other programmers?
It should be at least as expressive as your spoken tongue, not less.
The purpose of a language is to communicate. Spoken languages are extremely expressive because they need to express a massive range of things. A computer only has an extremely limited range of concepts that it can understand, so languages for a computer only need to be able to express a limited range of concepts. This is why C only has about 30 keywords, yet it is extrememly useful in the domain of computing, and also why I think the previous two paragraphs are false in the conclusions that they are trying to reach.
A programming language is generally not used to communicate with your users. This would be like saying the metal ore you use in creating the spanner is being used by the tool company to communicate with the mechanic.
At the moment, the reason that new spoken languages have not take root is not because they are simpler. Reasons I can think of are:
While a programming language that allows you multiple ways of doing the same thing will allow you to program in the style that you currently think, probably improving efficiency for you, this style is almost certainly not the same as other programmers. Furthermore if you learn and improve, it is unlikely that it will stay the same for you either. You have basically said the equivalent of: more languages and dialects on the earth increase the ease of communication between people. Actually reducing the number of languages is what is needed to help communication between people because people can now read your code without having to invest time in learning a new language/dialect and your way of thinking.
"A foolish consistancy is the hobgoblin of little minds" and nothing illustrates that point better than a discussion of Perl by those who don't actually use it.
Please note the word 'foolish'.
I think you have taken a stand on simplicity vs. creativity (complexity) in the subject of computer languages without evalutating the consequences.
I think code readability is a product of being concise and keeping things simple. At a certain point, increasing the concision of code increases complexity (by removing obvious meaning about what the code is trying to accomplish).
For example, the following includes explicit information that tells the reader that a choice is being made:
While this implies some matrix or arithmatic operation instead:
I think an extreme example is the concise perl code examples for DeCSS decoding.
Almost every single time I try to install an X-based program it chokes because I'm missing some library or another. In fact more than once I have tried to run a program and it says that I am missing a library that I already have!
I think this is a distribution problem rather than a problem intrinsic to dynamicaly linked executables.
Its also one of the reasons I run debian (the new 'versions' - not the last official stable release). If you're running an RPM based distro and if apt-rpm is anything near as good as what I've seen on debian then try that - you'll never look back. If you're running Mandrake I think you should already have an equivalent in urpmi. Any troubles you have are then down to Mandrake's packaging.
This is especially a problem with any audio/video software, and it's all because of staticly linked libraries.
I think you mean 'dynamically linked libraries'. Dynamically linked libraries are where the library is in a seperate file to the program. This is the normal method in both Windows and Linux (and I assume most other Unices).
Statically linked libraries are where the library is included in the program.
I'm hate M$ as much as the next geek
LOL. How much is that and who is the next geek?
Statically linking is not a waste when you consider the cheapness and size of today's storage solutions.
This is so easy to say when you have money.
Additionally, you get a performance increase with statically linked libraries
If you were to only ever run one program you would get a performance increase. But say you decided to statically link glibc into all your programs. Every time you run a program you have to load the copy of glibc statically linked into your program from disk, instead of just using the dynamic version that has already been loaded into memory. Reading from disk when loading a program degrades performance (far more than dynamically resolving libraries, as far as I can see).
That said, you are probably right about the expediency of bug fixes through libraries. Still, when you consider the rapid pace of development of some projects, I think this isn't as much of an issue as you might think it is.
Wouldn't it exacerbate the issue? With a faster development of projects more libraries would get updated more often and more packages would need to be downloaded.
Furthermore bandwidth is not nearly as widely available or cheap as storage. Have you seen the dependancy list for a library like glibc or zlib? Can you imagine having to re-download large parts of, or your entire distro whenever these get a critical security or bug fix? All that updating of programs with statically compiled libs will bulk up the packages a 'little' too.
When a distribution's installation hinges on the installation of the Perl RPM, for example, you are virtually guaranteeing that you will break something and potentially assfuck your system if you remove or don't install the Perl package in favor of compiling from a tarball.
Possible solution: Can't you install the new version of perl you want to a different path/prefix and make sure that these appear before any standard paths in the environments you want to use this version of perl?
e.g. lets see them actually use gcc3.1 before redhat
Why are you asking (taunting?) them to duplicate work, and waste time and money?
Whats wrong with using someone elses work in this context? I think it should be encouraged.
Only 15?!
I've tried garnome (http://www.gnome.org/~jdub/garnome/), and its worked really well for me. (I don't know if its been fixed now, but you may have to copy a glade-convert script - although probably not exactly that name - to a bin directory at some point.)
I use Debian, and while testing Gentoo next to it I find that I am capable of burning a CD-R by using 'cdrecord dev=ATAPI:0,0,0 speed=16 -v' (have to figure out how to enable BurnFREE someday)... under Debian, I still can't get it to recognize a standard ATAPI burner!
You should now be able to access your ATAPI cd-r drive as a scsi drive (/dev/scdX, X being a number) and details of the drive should appear in /proc/scsi/scsi (or a file named like that).
(I don't have my Linux box handy, therefore lots of 'I think').
Last i checked wasnt sun moving to KDE?
I think its was Gnome.
So do you think http://gstreamer.net/ is working in the right direction to do the equivalent of QuickTime?
I don't know whether it would be so hard for programs to have a font selection thing that let you choose them similar to the way Windows does it and then translates the selections into X's standard font naming format. It could be made into a widget, or mebbe a library with a widget built on top of it. Something like that.
Gnome 2 does this.
(Never used KDE, so I don't know about that.)
How can you state what people in the US want? You, judging from the your article, come from a country with 50 states, all of which are equivalent or larger in size than a not insignicant number of other countries, which contains a large and diverse population. I don't see how you can make the statements that you did about a population like that.
Not everyone wants to know what is happening. And people do blindly believe what the media tells them.
I think you were annoyed at blanket statements made against the US (that sounds like racist stereotyping from outsiders). A more useful response would have been something to the effect that, there are people in the US that do question and care about the validity of what the media reports - and also englighten us 'foreigners' about news sources in the US that are less sensational and more thoughtful than some of the mainstream US reporting we see from outside.
If it were the "preferred" method a country like the US would probably be currently involved in a bloody civil war.
And if you were to take the statistics on this page, http://www.religioustolerance.org/worldrel.htm, to be even close to the truth there would probably be few humans left alive.
While religion has occasionally been used as an excuse for horrible acts, it is much more often provides hope, stability and ethical values to work from (I think many of these values from major religions would be considered a good thing by most people).
You really have to look at individuals, communities and people (small things - often hard to see) to see where religions really works well.
Hrmm... have I just been trolled?
I think the age limits have at least as much to do with what harm you can cause to others, as with what harm you can do to yourself.
I guess the expectation is that in general people are significantly more responsible and less likely to cause harm to others and themselves due to alcohol at 21, than at 18.
It also reduces the chance of situations such as inexperienced drivers under the influence of alcohol.
-
Free/Open source has not reached great penetration onto the desktop and general use, and mostly attracts programmers, heavy duty and/or highly technically literate computer users at the moment (the people for which the advantages are most relevant to).
-
Artists are generally not programmers and tend not to be highly technically literate, or care excessively about the freedom of the software they use.
-
There are few high quality graphics programs for Free/Open source systems.
- Artists are generally satisfied, and possibly fanatically loyal to their current desktop system.
;-)
So the set of people who are artists does not intersect by a great amount with the set of OSS/Free software users. Which could be why you see a disproportionate amount of good code, to good art.I remember recently reading about a signal booster in an electronics magazine (CPC in the UK) that had a little note next to the product description saying in effect it would circumvent Macrovision. I think the effect was unintentional. I have no idea of the resultant quality though.
In GTK (the version used in Gnome 1.4 and I think in Gnome 1.2) you can select text with the right mouse button. This text is not copied, but it is replaced when you paste text using the middle mouse button (it is highlighted in gray rather than blue, with the default theme).
We have the right to complain about anything we want to, free or not.
While you may have the right to complain, just because you can doesn't mean you should.
Rights, rights, rights, rights... where did the duties go?
Reading through the comments, has caused me to fire off some "practically" random thoughts:
The better the compression ratio, the smaller the data set that can be compressed to this size is.
One piece of random data is not the worst case, as it may represent the best case for a compression ratio.
The average compression ratio for a fixed length of random data in general is not the worst case for an algorithm, but merely the average compression ratio for the algorithm over all data sets.
Algorithms and formulae contain a lot of information, much/most of it implied. e.g. the addition operator has an implied meaning, which when fully stated takes up much more space than '+'.
The statment "Cyan, magenta and yellow are primary colours in negative colour mixing." implies lots of information about the structure of our eyes and of light. The amount of information that is implied increases as the readers understanding of the words grow.
If the universe is built on a few small pieces of information, then maybe everything has patterns coming from these that allow it to be compressed back to something very small in size.
Small excercise I thought through:
100:1 compression ratio on 1000 bits:
1000 bits have 2^1000 combinations.
10 bits have 2^10 combinations.
So each combination of 10 bits would need to represent 2^100 combinations of 1000 bits.
BUT, say we have 2^100 compression algorithms, each are optimal at compressing 2^100 seperate patterns of 1000 bits of data to 100 bits. The patterns do not overlap.
We add 100 bits to the compressed data to tell us which algorithm to choose. Therefore final compressed data becomes: 110 bits long.
New compression ratio is:
1000/110 = 9.1 (1 d.p.)
This can be achieved on any 1000 bits we have. 9.1:1 compression is a pretty good general compression ratio for all cases.
BIG PROBLEM: compressor/decompressor would need knowledge of each algorithm. If each algortihm only took up 1 byte, 1,125,899,906,842,624 Petabytes of storage would be needed.
Suicidal optimism: There may be one algorithm that can generate all these other algorithms from a very small data set though.
'European' kids? I'm not too sure if there is such an entity. Probably a little like me (England) saying "you kids from the continents west of me".
Abiword is cross platform application using native widgets (GTK on Unix). You might want to have a look at how they did it. They must have sorted out cross platform printing as well and some other none GUI issues.
There is already a working GTK2 port to win32. I've got the libraries and used an application based on it (of course this includes, glib, pango, etc.)
Look for a Win32 Radeon tweaker on sourceforge and its got links (at least the install programs has) to the precompiled Win32 dlls for a prerelease GTK2.