Many people answered to my previous rant stating that it is upstream's prerogative to refuse integration of external patches. I agree and I never said they must integrate patches if they open their source.
What I find unacceptable, and the only reason for the rant, is the fact that upstream deleted my posts from the forum when it was clear that none of the fake reasons that were given was the real reason, since I answered to all of them with sane, logic and reasonable arguments.
I find acceptable to refuse external patches, although undesirable.
Still, I find it unacceptable to try to erase all tracks of a conversation from which it is clear that you were wrong, and try to keep face by erasing traces.
I would have found it hard to deal with, but still acceptable, if upstream would have said simply "please don't try to make patches for glest with the purpose of integrating them later on, we don't want any patches from outsiders". That would have been a decent thing to do.
Wednesday, 11 March 2009
cd-circleprint - calibration info for c5380
If you're using a HP Photosmart C5380 All-in-One printer to print on a CD, you might find it useful to use the following cd-circleprint configuration file when using mainly A4 paper format.
delta 20.0
begin_from_bottom 7.5
viewer /usr/bin/evince
converter convert
radius_inner 21
tickmarks 1
print_circle_boundaries 1
begin_from_left[0] 1.5
begin_from_left[1] 1.5
number_of_labels 2
debug 0
circle_radius[0][0] 50
circle_radius[0][1] 41
circle_radius[0][2] 41
circle_radius[0][3] 50
circle_radius[1][0] 50
circle_radius[1][1] 41
circle_radius[1][2] 41
circle_radius[1][3] 50
x_scale 1
y_scale 1
I am unsure if usually using A4 paper format changes anything, but the .ps file cd-circleprint creates uses A4 on my system.
Does anyone knows a decent editor for CD artwork?
delta 20.0
begin_from_bottom 7.5
viewer /usr/bin/evince
converter convert
radius_inner 21
tickmarks 1
print_circle_boundaries 1
begin_from_left[0] 1.5
begin_from_left[1] 1.5
number_of_labels 2
debug 0
circle_radius[0][0] 50
circle_radius[0][1] 41
circle_radius[0][2] 41
circle_radius[0][3] 50
circle_radius[1][0] 50
circle_radius[1][1] 41
circle_radius[1][2] 41
circle_radius[1][3] 50
x_scale 1
y_scale 1
I am unsure if usually using A4 paper format changes anything, but the .ps file cd-circleprint creates uses A4 on my system.
Does anyone knows a decent editor for CD artwork?
Thursday, 5 March 2009
Glest: how upstream can be a real dick
At some point in the past, when I was still thinking that Glest can be packaged in a sane way, I had a conversation with upstream developer martinho on the Glest forum (they call it board) about them integrating a patch in order to support big endian machines.
After some messages on their board, it was clear that they don't want to integrate any patches and started to throw out random fake arguments against the integration of my patch and other patches.
When he figured out that I replied and debunked all of his fake arguments, he went on and actually removed my posts from the forum. It was so weird since I have never seen that kind of behaviour before and some of his posts and other people's posts were replies to my posts and things didn't made any sense after the deletion.
At that moment I have managed to save one small bit of the conversation via Google's cache, but now I have finally decided to make it public.
Note: Back then, I kept this post private in the hope that I was maybe too involved in the conversation at that moment to make a rational decision about it, and hoped things would get better in time. They didn't. Meanwhile they migrated to another forum software and they said they lost most/all(?) of the previous content from the old forum.
Here is the conversation bit I managed to save.
Original text is in italic font. Regular font is for my current comments for clearing up the context of the discussion. The text retains the BB syntax and [quote]-d text is martinho's own words.
[quote="martinho"]thebohemian, eddyd,
I think you guys are missing the point, this is not the place for any [/quote]
Congrats, you are avoiding to answer the points I have raised.
[quote]
- The Glest project is made by a bunch of friends for fun, we ask for nothing, we answer to no one. So I beg you not co complain, because it is out of order.
[/quote]
In that case I don't see the point of the "development" forum. care to explain?
And, from my PoV, these are your users you're arrogantly dismissing.
The following was a reply to my request to add big endian support through a patch I provided at that time. The patch wasn't complete to actually make glest work on BE machines, but it didn't broke little endian support at all. He was trying to argue that there were no valid big endian machines on which the game would run. Integrating the patch would have made my life a lot easier in continuing the work on the patch.
[quote]
- Our target plarforms are PCs running Windows (I'm responsible for this) or Linux (matze is the boss here). We don't care if Glest doesn't run in a big endian dishwasher with Solaris.
[/quote]
Linux on PowerPC is a viable platform. So is Mac OS X on PowerPC.
I made the mistake of saying that some parts of the code where not that clean and could be improved. More on that below.
[quote]
- One of the keys of Glest success is how extremely clean our code is. Bringing random people in would break this, and we are not going to do it. [/quote]
So you are the only keepers of true knowledge of clean code? Hahahaha!
There were at least 3 patches that provided this through word/double-word swapping. I don't see how embedding the patch can affect the unity of the code.
BTW, you are aware you can "carve" people into coding in your style before accepting in, aren't you?
I suggested using int8, uint8, int16, uint16 in order to make sure that the parameters are of the expected fixed size since plain char, int, long, long long have different sizes depending on the architecture. The usage of int and int16 was inconsistent and I also suggested using always the numbered variants.
I said the approach that was then taken in code was not portable and that was the reason for the proposed change.
[quote]
- Glest has been coded with portability in mind, some of your comments about portability are really naive (compilers don't care if you declare function parameters with fixed byte length, they just use whatever is the fastest int in the platform). Fixed length data types are used when needed,
[/quote]
What? When did I say anything about that? I said the code uses inconsistently "int" and "int16" and should use the later always because the code assumes the sizes on i386, which are not always applicable - see long on amd64.
If you mean that I can't enforce the width of the parameter, then you should know better, those types are defined in a platform dependent way to be platform independent. Yes, there are cases where [b]on the stack[/b] the size of the passed data is bigger (they might be padded), but that is transparent to the functions and, in spite of that, the functions will see the proper values for the parameters.
Also, the packing behaviour is compiler and architecture dependent, and some compilers produce the weirdest packing (if you are allowed access to such docs, look for Green Hills compilers' for V850 and you'll be stunned).
Please, don't make a fool of yourself by trying to discredit me, just not to loose face.
Later he just removed my posts not to loose face.
As a sane programmer, I made my patch to do the swapping only on big endian platforms, and the code was enabled in through the precompiler, so there was no performance hit on the little endian arches.
Of course, any more-than-newbie programmer would agree that having two data sets for a single game is stupid and is better to do the swapping in the application itself to avoid space wastage and maintaing an alternate big endian data set.
[quote]
no more, no less. About endianness, we don't care. If we wanted to fix the problem anyway, the right way is to do the byte swap in the data, this is how it is done in commercial games, since it is more efficient.
[/quote]
You just proved how much bullshit you can deliver in one phrase just for the sake of winning an argument. All portable games and all applications that have data files prefer to do swapping on the spot just because swapping the data on the disk (or providing BE and LE data) is plain stupid and inefficient from a disk and bandwidth PoV.
For Glest, swapping the data after reading from disk is not even affecting performance in a manner that could be significant or noticed, not even for a processor running at 500MHz, since that would be done only on load, once, and just for the bits of data which are relevant; these are mostly headers, since the actual data, in most cases, is just a long byte vector. This translates in not more than 3 or 4 instructions in assembler (an init, an exchange, an increment and/or a loop instruction), and that would happen before starting a game, which is dead time anyway and wouldn't be noticed unless the data would be huge (order of hundreds of MB or GB) and the whole data set would need swapping.
Even if the data itself (not headers) represents data which needs to be swapped, that is still irrelevant in terms of speed.
BTW, the reason that in commercial games it might be done like that is because there the games are distributed in a package per platform anyway and having two data sets is not an issue since they are using the same amount of CDs/DVDs, but doing the same for a game like Glest would mean doubling the storage used and it would increase the complexity for a release, not to count the confusion of the users.
I still doubt commercial games do this, but I might be wrong.
After some messages on their board, it was clear that they don't want to integrate any patches and started to throw out random fake arguments against the integration of my patch and other patches.
When he figured out that I replied and debunked all of his fake arguments, he went on and actually removed my posts from the forum. It was so weird since I have never seen that kind of behaviour before and some of his posts and other people's posts were replies to my posts and things didn't made any sense after the deletion.
At that moment I have managed to save one small bit of the conversation via Google's cache, but now I have finally decided to make it public.
Note: Back then, I kept this post private in the hope that I was maybe too involved in the conversation at that moment to make a rational decision about it, and hoped things would get better in time. They didn't. Meanwhile they migrated to another forum software and they said they lost most/all(?) of the previous content from the old forum.
Here is the conversation bit I managed to save.
Original text is in italic font. Regular font is for my current comments for clearing up the context of the discussion. The text retains the BB syntax and [quote]-d text is martinho's own words.
[quote="martinho"]thebohemian, eddyd,
I think you guys are missing the point, this is not the place for any [/quote]
Congrats, you are avoiding to answer the points I have raised.
[quote]
- The Glest project is made by a bunch of friends for fun, we ask for nothing, we answer to no one. So I beg you not co complain, because it is out of order.
[/quote]
In that case I don't see the point of the "development" forum. care to explain?
And, from my PoV, these are your users you're arrogantly dismissing.
The following was a reply to my request to add big endian support through a patch I provided at that time. The patch wasn't complete to actually make glest work on BE machines, but it didn't broke little endian support at all. He was trying to argue that there were no valid big endian machines on which the game would run. Integrating the patch would have made my life a lot easier in continuing the work on the patch.
[quote]
- Our target plarforms are PCs running Windows (I'm responsible for this) or Linux (matze is the boss here). We don't care if Glest doesn't run in a big endian dishwasher with Solaris.
[/quote]
Linux on PowerPC is a viable platform. So is Mac OS X on PowerPC.
I made the mistake of saying that some parts of the code where not that clean and could be improved. More on that below.
[quote]
- One of the keys of Glest success is how extremely clean our code is. Bringing random people in would break this, and we are not going to do it. [/quote]
So you are the only keepers of true knowledge of clean code? Hahahaha!
There were at least 3 patches that provided this through word/double-word swapping. I don't see how embedding the patch can affect the unity of the code.
BTW, you are aware you can "carve" people into coding in your style before accepting in, aren't you?
I suggested using int8, uint8, int16, uint16 in order to make sure that the parameters are of the expected fixed size since plain char, int, long, long long have different sizes depending on the architecture. The usage of int and int16 was inconsistent and I also suggested using always the numbered variants.
I said the approach that was then taken in code was not portable and that was the reason for the proposed change.
[quote]
- Glest has been coded with portability in mind, some of your comments about portability are really naive (compilers don't care if you declare function parameters with fixed byte length, they just use whatever is the fastest int in the platform). Fixed length data types are used when needed,
[/quote]
What? When did I say anything about that? I said the code uses inconsistently "int" and "int16" and should use the later always because the code assumes the sizes on i386, which are not always applicable - see long on amd64.
If you mean that I can't enforce the width of the parameter, then you should know better, those types are defined in a platform dependent way to be platform independent. Yes, there are cases where [b]on the stack[/b] the size of the passed data is bigger (they might be padded), but that is transparent to the functions and, in spite of that, the functions will see the proper values for the parameters.
Also, the packing behaviour is compiler and architecture dependent, and some compilers produce the weirdest packing (if you are allowed access to such docs, look for Green Hills compilers' for V850 and you'll be stunned).
Please, don't make a fool of yourself by trying to discredit me, just not to loose face.
Later he just removed my posts not to loose face.
As a sane programmer, I made my patch to do the swapping only on big endian platforms, and the code was enabled in through the precompiler, so there was no performance hit on the little endian arches.
Of course, any more-than-newbie programmer would agree that having two data sets for a single game is stupid and is better to do the swapping in the application itself to avoid space wastage and maintaing an alternate big endian data set.
[quote]
no more, no less. About endianness, we don't care. If we wanted to fix the problem anyway, the right way is to do the byte swap in the data, this is how it is done in commercial games, since it is more efficient.
[/quote]
You just proved how much bullshit you can deliver in one phrase just for the sake of winning an argument. All portable games and all applications that have data files prefer to do swapping on the spot just because swapping the data on the disk (or providing BE and LE data) is plain stupid and inefficient from a disk and bandwidth PoV.
For Glest, swapping the data after reading from disk is not even affecting performance in a manner that could be significant or noticed, not even for a processor running at 500MHz, since that would be done only on load, once, and just for the bits of data which are relevant; these are mostly headers, since the actual data, in most cases, is just a long byte vector. This translates in not more than 3 or 4 instructions in assembler (an init, an exchange, an increment and/or a loop instruction), and that would happen before starting a game, which is dead time anyway and wouldn't be noticed unless the data would be huge (order of hundreds of MB or GB) and the whole data set would need swapping.
Even if the data itself (not headers) represents data which needs to be swapped, that is still irrelevant in terms of speed.
BTW, the reason that in commercial games it might be done like that is because there the games are distributed in a package per platform anyway and having two data sets is not an issue since they are using the same amount of CDs/DVDs, but doing the same for a game like Glest would mean doubling the storage used and it would increase the complexity for a release, not to count the confusion of the users.
I still doubt commercial games do this, but I might be wrong.
Glest FAQ: From the book of 'we want people to think we're open'
The Glest FAQ says (emphasis is mine):
[..] as a rule of thumb we don´t integrate any patches in our mainline, since that would require us to check them first and then maintain them, however feel free to post them at the board.
Glest development sucks. I really hope Glest Advanced Engine effort takes speed and replaces Glest.
This is the main reason I don't feel any incentive to maintain this package in Debian.
[..] as a rule of thumb we don´t integrate any patches in our mainline, since that would require us to check them first and then maintain them, however feel free to post them at the board.
Glest development sucks. I really hope Glest Advanced Engine effort takes speed and replaces Glest.
This is the main reason I don't feel any incentive to maintain this package in Debian.
Subscribe to:
Posts (Atom)