Well, I actually code for big endian platforms (current gen - until recently still called "next-gen":) - consoles) and I am aware of the issues. But I don't really think that accounting for this means introducing "kludges and workarounds". It's like accounting for network byte order or for platform-specific file format, something that you would probably do in Java as well if you needed to read files on that platform quickly (i.e. without any "parsing" stage, just loading chunks from disk into memory directly).
Maybe I should have been more clear when talking why "C is more cross-platform than Java" - not because you need less changes in code in order to run it on any new platform, but because you have *way* better chances to get it to run at all:)
So what? Unless you are coding for 16-bit and smaller devices, those differences are negligible for getting your code to work. There are almost no devices left these days which would use fancy memory addressing model, and even those that remain offer no alternative for C other than assembler.
With Java/C#, it's worse - you won't get your program running on hardware that Oracle/Microsoft or wider community does not want to support (see Raspberry Pi as a high profile example).
Yes. There's good tools for that sort of thing, and they're actually easier to use than with C and C++.
Can I use it from within a program or do I have to assume that memory allocation never returns NULL? How do I measure and control memory fragmentation? Can I have my own memory manager for certain classes whose allocation patterns I know of?
Can I guarantee repeatable runtime behavior?
If you stick to deterministic constructs and software patterns, the behavior of the program will be repeatable. If you don't, it won't. That's true for all languages. In terms of memory management, generational garbage collection is the big thing that makes the difference: most allocated objects have very short lifespans (because Java doesn't use stack allocation at all) and so can be disposed of very rapidly
Is it possible to control VM behavior (JIT or no JIT) and its performance characteristics, like, forcing to compile all the code to native before the first run? And for JIT, can you coalesce the code so parts close to each other temporally are also close spatially and thus fit instruction cache? Can you issue cache prefetches when you are about to read spatially distant data?
RAII is not only C++'s concept, it's very important when dealing with open files, connections or memory on graphics card. You want to know *exactly* when these resources are released because you often have global limit on them and/or need to guarantee the order of operations. I understand the motivation to avoid explicit resource management, but the truth is that we run our software in a limited environment and often cannot - nor should not - abstract from much of its limitations.
As for multiple threads, there still is some predictability. E.g. you separate work on multiple worker threads in a "wavefront" pattern, yet you still want to end it by the end of the video frame so you can guarantee fairly constant framerate.
Java is designed to be predictable? Can I have RAII with it? Can I know how memory I use at any given moment? Can I guarantee repeatable runtime behavior?
Think about what your input and output data is, and what operations are needed to transform the former into the latter. Then choose the most suitable approach how to represent all that.
E.g. you don't really want a single class of Image as a container of Pixel classes for each bit depth, that's rather wrong classification. It may make more sense to stop subdivision at image level and have a number of classes that represent images of different bit depth/ number of channels. Or, it may be even better to take data organization into account and treat bitmaps that hold uncompressed data as different entities than textures that hold e.g. S3TC-compressed pixels. Or, you may think about each image as of a set of independent channels (R, G, B) and turn your data from AoS into SoA. There are multiple ways to think about the same data, you need to pick one based on what transformations are needed.
It's refreshing to see a comeback of a language that doesn't require you to start with classifying your data.
Program is a data-to-data mapping and language should be flexible enough to support this view. If a language requires you to classify your data (especially using such an unstable classifier as decision tree, which is essentially what class hierarchy in OO languages is) before you start to program, it's a wrong approach.
More importantly, OOP requires that you start with class hierarchy - wrong approach. Class hierarchy is de facto a decision tree, a very unstable classifier. If you build it on insufficient number of observations (which is nearly always the case when you start writing software from scratch), you will need to throw away your decision tree and rebuild it anew. That's what we call "refactoring" in OOP.
Let me shout it loud: Premature classification is the root of all evil!:) Think about your program as of data-to-data mapping primarily, and then build the abstractions.
Certainly C is more cross-platform. I can compile and run C program on my PowerPC-based MyBookLive NAS, on my ARM-based Raspberry Pi, on my MIPS-based Dingoo A320 and on my again PowerPC-based PlayStation 3. Building a GCC toolchain for all those platforms is a piece of cake with crosstool-ng. Now, can I build a Java runtime for all those devices? How much effort is that compared to building GCC?
Not to mention that it's totally uninteresting to be writing software for someone's VM. You don't get to know the hardware, you could very well program in something like Javascript.
Anyway, accusing me of selfishness for explaining how I think one could make a living from writing an open source product is quite strange.
Selfishness is demanding someone else's software to be open in the first place, without any compensation, just because it's "the right thing". May I demand that you start teaching your craft (whatever you do for a living) for free using the same reasoning?
No. Just starting a new software, or even a new version of an existing software you previously didn't focus on, doesn't mean reinventing yourself. If your whole company's success rests on a single product, you're doomed anyway.
There are plenty of successful companies that have only a single successful product. While they may be "doomed anyway" in the long run, introducing artificial reasons to give up their advantage of knowledge (sources and what not) certainly is not going to help them survive.
I believe I'm better at what I'm doing than at writing software.
Quite possibly. I am afraid that also makes your opinion about modern software industry idealistic and naive. The said industry went a very long road from being art and never was a science, nowadays it's getting closer to being a craft just like real estate development. There is a lot of people involved in it these days and most of them aren't young anymore, have families and don't really care about "what is the right thing". The right thing is whatever puts bread on the table.
Because it's the right thing. You know, not everyone sees profit as the highest value.
It's not even about profit being the highest value, but about getting anything in return. You are asking for a favor - to hand you results of someone's hard work, and your reasoning is because it's the right thing? Pretty selfish.
At least the most important thing: how to keep your programmers' jobs after it has gone open source (which is supposedly majority of its planned lifetime) is not covered.
Simple: Have them write new code, which you then can sell again. This may, but need not be a improved version of the same program. If there's not enough improvement possible to compete against the previous version after open-sourcing it, then you should focus on another project instead.
Basically you are asking software companies to reinvent themselves periodically for no apparent reason. No matter that new market may be different, their staff might have specialized in certain areas, and started families so they cannot switch to 72h/week startup mode anymore.
Pretty selfish and naive approach. Do you create software for a living? Or is it not "the right thing" for you?
2) I don't think this is a sustainable model for monetizing open source software. At least the most important thing: how to keep your programmers' jobs after it has gone open source (which is supposedly majority of its planned lifetime) is not covered. Unless you are thinking about a scheme where software gets open sourced after it lost market value.
There is yet to be a release day DRM system that lasts a few days, let alone a month. Bioshock, Assassins Creed, all those bollocks online only systems were broken within days if not before release day.
Just to counter that with a simple fact: Assasin's Creed II has been cracked after more than a month of its PC release (3/4/10, cracked around 4/26/10).
This is because of the way most Triple A games are designed. 1/3 of the budget goes on marketing, not to mention that console games in general don't make money as they have to pay a per disk fee as well as extra fees to push patches out via Xbox Live or PSN. The PC version is more profitable per unit, the problem is they do everything to prevent people from buying the game on PC.
True, PC version is more profitable, but it also sells like 1/10 compared to console versions. Why? Certainly not because of lack of marketing...
"Triple A games" are build on a fundamentally flawed system that will fall over in the near future. Too much is spent on marketing and costs that add nothing to the game itself, like DRM.
Try releasing a game without marketing. Advertise it on company website only, or only using company-associated social network accounts. Come on... You know that even viral marketing (the holy grail - word of mouth) isn't free these days, right?
And if that wasn't enough, the games company can even provide a bootable Linux DVD or USB stick which boots into linux and starts the game. Can't have much more control over the OS software than that!
It is a GPL violation to create such bundle, assuming that they use binary drivers (and open source ones aren't really capable at this point).
After a technology breakthrough, it is easier. But within each "stage", it gets harder. E.g. 30 years ago you could produce a decent game alone (for ZX Spectrum). 20 years ago you could produce a decent game with a few of your friends. 10 years ago you could produce a decent game with 20-30 people. Nowadays it takes hundreds of people.
The same with movies, except that movies are a bit older industry and it lived through a few technology changes. But generally, do not expect homebrew stuff to grow to Hollywood level of quality.
As for music, this may be different, because people still like low-tech (e.g. acoustic guitar) music, but I am sure that capital investments required grow for this industry as well. After all, Pro Tools have their high price tag for a reason.
Can't agree. I use a lot of open source software myself (even as I write these words, in Kubuntu) and it reminds me of Soviet cars: you always have problems where others don't and you need to know the guts of the car in order to drive it. But I won't argue about that. I'm rather sympathetic to "open source" (but not exactly Free Software) myself (more evidence can be found in my blog), it's just that I don't believe that solid development practices can arise where there's no monetary feedback - and FOSS seems to be hard to monetize. Again, let market decide - currently it looks like FOSS is on decline (together with "unlocked" hardware platforms like PC, where freedom to run random binaries is about to be sacrificed to gods of Security), but maybe - and hopefully - the situation will change.
I see your point. It all boils down which market you want to implement - integrating over time, developers will get the same money, but in different ways. If you outlaw certain licensing models or even whole property rights altogether, software market will look like one currently seen in countries with a weak law enforcement, i.e. a lot of low-quality cheap/free products which suck your money gradually, by nagging you with ads or asking to pay on each step (in the first case you become a product yourself). If law system is strong enough to support advanced licensing models, it opens up possibilities for upfront payments, so you don't have to pay each time you click.
However, it looks like the world is sliding into "el cheapo" approach and micropayments will become ubiquitous.
You sound as if I complained while I only pointed out why respecting property rights is essential in such a risky market.
By your logic, if you don't want to license certain property just for a limited time, simply don't. Nobody is forcing you to do that. Try to negotiate a price for an unlimited license (which is your only option due to your country's laws), which will offset possible resale, but until they do that, refrain from illegal (according to local laws) deals on Steam. Although I can foresee how Steam may be unwilling or unable to provide you with that if your country is not a large enough market, it may be easier to simply drop support for that territory.
But still, try to. It's business, there's should be no emotions.
I'm a game developer who happens to work in Poland and I track CD Projekt (GOG parent) stock close enough. GOG did bring them profit (a bit less than 1 mln USD for 1H2012), Wiedzmin (Witcher) for 360 got them even more (about 5 mln USD) but they are losing money on traditional retail market, their primary source of income up to now (source in Polish). Also, compare those numbers, which may be good for Poland, to 40 mln USD needed to create a modern AAA game.
Also, DRM is essential to delay piracy for the first month of game release. Games only really sell in the first few weeks after launch, if you didn't know - after that, people move on to something else and the "long tail" of sales begins (see just about any game's charts: [1], [2], [3]). So the games need to make up for that large upfront investment in first 4 to 6 weeks, if they don't break even, they are dead. Alan Wake, L.A. Noire, Max Payne 3 - all those arguably known and high profile titles are commercial failures. Most current triple A games flop or barely make even, but unless explicitly asked, publishers rarely admit it. However, if you work in gamedev you probably saw the closures of Grin, Pandemic, 38 Studios, and in general, it starts to happen too frequently.
So no, it's not just about "having control". There would be no need in control if existing model provided a sustainable way to earn money. Truth is, nowadays interactive entertainment market is a gamble.
Well, I see. But I think the easier resolution is making Steam illegal in your country. The problem isn't with DRM alone... if people treated software licenses in a responsible way, there would be no need to make "rights management" so strict. Traditional way (with which in mind your country's laws were written) simply is not sustainable. When games had book-sized budgets and the sale of a few hundred "copies" was enough to be profitable, this could work. With games having movie-sized budgets and millions of "copies" needed to break even, not so much. And it's not easy to scale down when people's expectations are so way up.
I'm a game developer myself. I do want to find an easy and affordable way for people to play my games. But this cannot be an one-sided relationship, we need a sustainable model of creating quality, AAA games. Traditional market is crashing into the ground, and the future looks... well, maybe not grim, but certainly differently.
I predict domination of "pay4win" free2play games, ad-supported games and MMO-like "thin client" games in the near future - precisely because there's no mutual trust between game developers/publishers and gamers. Valve seems to be the closest to it, yet it still gets bashed here.
Slashdot Mirror
walk into any modern office, and count the number of Linux desktops
I'm interested in your estimate. I think it is 0 or close to 0, but I work in a specific industry (gamedev) and can have MS bias.
Well, I actually code for big endian platforms (current gen - until recently still called "next-gen" :) - consoles) and I am aware of the issues. But I don't really think that accounting for this means introducing "kludges and workarounds". It's like accounting for network byte order or for platform-specific file format, something that you would probably do in Java as well if you needed to read files on that platform quickly (i.e. without any "parsing" stage, just loading chunks from disk into memory directly).
:)
Maybe I should have been more clear when talking why "C is more cross-platform than Java" - not because you need less changes in code in order to run it on any new platform, but because you have *way* better chances to get it to run at all
So what? Unless you are coding for 16-bit and smaller devices, those differences are negligible for getting your code to work. There are almost no devices left these days which would use fancy memory addressing model, and even those that remain offer no alternative for C other than assembler.
With Java/C#, it's worse - you won't get your program running on hardware that Oracle/Microsoft or wider community does not want to support (see Raspberry Pi as a high profile example).
Too hard to transcend the pattern of thought you got used to, eh? Fear not, I also code in OOP way - at the level at which it makes sense.
Can I know how memory I use at any given moment?
Yes. There's good tools for that sort of thing, and they're actually easier to use than with C and C++.
Can I use it from within a program or do I have to assume that memory allocation never returns NULL? How do I measure and control memory fragmentation? Can I have my own memory manager for certain classes whose allocation patterns I know of?
Can I guarantee repeatable runtime behavior?
If you stick to deterministic constructs and software patterns, the behavior of the program will be repeatable. If you don't, it won't. That's true for all languages. In terms of memory management, generational garbage collection is the big thing that makes the difference: most allocated objects have very short lifespans (because Java doesn't use stack allocation at all) and so can be disposed of very rapidly
Is it possible to control VM behavior (JIT or no JIT) and its performance characteristics, like, forcing to compile all the code to native before the first run? And for JIT, can you coalesce the code so parts close to each other temporally are also close spatially and thus fit instruction cache? Can you issue cache prefetches when you are about to read spatially distant data?
RAII is not only C++'s concept, it's very important when dealing with open files, connections or memory on graphics card. You want to know *exactly* when these resources are released because you often have global limit on them and/or need to guarantee the order of operations. I understand the motivation to avoid explicit resource management, but the truth is that we run our software in a limited environment and often cannot - nor should not - abstract from much of its limitations.
As for multiple threads, there still is some predictability. E.g. you separate work on multiple worker threads in a "wavefront" pattern, yet you still want to end it by the end of the video frame so you can guarantee fairly constant framerate.
So why base that language on Java at all?
Java is designed to be predictable? Can I have RAII with it? Can I know how memory I use at any given moment? Can I guarantee repeatable runtime behavior?
Think about what your input and output data is, and what operations are needed to transform the former into the latter. Then choose the most suitable approach how to represent all that.
E.g. you don't really want a single class of Image as a container of Pixel classes for each bit depth, that's rather wrong classification. It may make more sense to stop subdivision at image level and have a number of classes that represent images of different bit depth/ number of channels. Or, it may be even better to take data organization into account and treat bitmaps that hold uncompressed data as different entities than textures that hold e.g. S3TC-compressed pixels. Or, you may think about each image as of a set of independent channels (R, G, B) and turn your data from AoS into SoA. There are multiple ways to think about the same data, you need to pick one based on what transformations are needed.
It's refreshing to see a comeback of a language that doesn't require you to start with classifying your data.
Program is a data-to-data mapping and language should be flexible enough to support this view. If a language requires you to classify your data (especially using such an unstable classifier as decision tree, which is essentially what class hierarchy in OO languages is) before you start to program, it's a wrong approach.
Premature classification is the root of all evil.
More importantly, OOP requires that you start with class hierarchy - wrong approach. Class hierarchy is de facto a decision tree, a very unstable classifier. If you build it on insufficient number of observations (which is nearly always the case when you start writing software from scratch), you will need to throw away your decision tree and rebuild it anew. That's what we call "refactoring" in OOP.
:) Think about your program as of data-to-data mapping primarily, and then build the abstractions.
Let me shout it loud: Premature classification is the root of all evil!
Probably because that's what they were taught in school. I never could understand why academia are so fond of Java.
Certainly C is more cross-platform. I can compile and run C program on my PowerPC-based MyBookLive NAS, on my ARM-based Raspberry Pi, on my MIPS-based Dingoo A320 and on my again PowerPC-based PlayStation 3. Building a GCC toolchain for all those platforms is a piece of cake with crosstool-ng. Now, can I build a Java runtime for all those devices? How much effort is that compared to building GCC?
Not to mention that it's totally uninteresting to be writing software for someone's VM. You don't get to know the hardware, you could very well program in something like Javascript.
Anyway, accusing me of selfishness for explaining how I think one could make a living from writing an open source product is quite strange.
Selfishness is demanding someone else's software to be open in the first place, without any compensation, just because it's "the right thing". May I demand that you start teaching your craft (whatever you do for a living) for free using the same reasoning?
No. Just starting a new software, or even a new version of an existing software you previously didn't focus on, doesn't mean reinventing yourself. If your whole company's success rests on a single product, you're doomed anyway.
There are plenty of successful companies that have only a single successful product. While they may be "doomed anyway" in the long run, introducing artificial reasons to give up their advantage of knowledge (sources and what not) certainly is not going to help them survive.
I believe I'm better at what I'm doing than at writing software.
Quite possibly. I am afraid that also makes your opinion about modern software industry idealistic and naive. The said industry went a very long road from being art and never was a science, nowadays it's getting closer to being a craft just like real estate development. There is a lot of people involved in it these days and most of them aren't young anymore, have families and don't really care about "what is the right thing". The right thing is whatever puts bread on the table.
1) If it sells as closed source, why open it?
Because it's the right thing. You know, not everyone sees profit as the highest value.
It's not even about profit being the highest value, but about getting anything in return. You are asking for a favor - to hand you results of someone's hard work, and your reasoning is because it's the right thing? Pretty selfish.
At least the most important thing: how to keep your programmers' jobs after it has gone open source (which is supposedly majority of its planned lifetime) is not covered.
Simple: Have them write new code, which you then can sell again. This may, but need not be a improved version of the same program. If there's not enough improvement possible to compete against the previous version after open-sourcing it, then you should focus on another project instead.
Basically you are asking software companies to reinvent themselves periodically for no apparent reason. No matter that new market may be different, their staff might have specialized in certain areas, and started families so they cannot switch to 72h/week startup mode anymore.
Pretty selfish and naive approach. Do you create software for a living? Or is it not "the right thing" for you?
1) If it sells as closed source, why open it?
2) I don't think this is a sustainable model for monetizing open source software. At least the most important thing: how to keep your programmers' jobs after it has gone open source (which is supposedly majority of its planned lifetime) is not covered. Unless you are thinking about a scheme where software gets open sourced after it lost market value.
There is yet to be a release day DRM system that lasts a few days, let alone a month. Bioshock, Assassins Creed, all those bollocks online only systems were broken within days if not before release day.
Just to counter that with a simple fact: Assasin's Creed II has been cracked after more than a month of its PC release (3/4/10, cracked around 4/26/10).
This is because of the way most Triple A games are designed. 1/3 of the budget goes on marketing, not to mention that console games in general don't make money as they have to pay a per disk fee as well as extra fees to push patches out via Xbox Live or PSN. The PC version is more profitable per unit, the problem is they do everything to prevent people from buying the game on PC.
True, PC version is more profitable, but it also sells like 1/10 compared to console versions. Why? Certainly not because of lack of marketing...
"Triple A games" are build on a fundamentally flawed system that will fall over in the near future. Too much is spent on marketing and costs that add nothing to the game itself, like DRM.
Try releasing a game without marketing. Advertise it on company website only, or only using company-associated social network accounts. Come on... You know that even viral marketing (the holy grail - word of mouth) isn't free these days, right?
And if that wasn't enough, the games company can even provide a bootable Linux DVD or USB stick which boots into linux and starts the game. Can't have much more control over the OS software than that!
It is a GPL violation to create such bundle, assuming that they use binary drivers (and open source ones aren't really capable at this point).
After a technology breakthrough, it is easier. But within each "stage", it gets harder. E.g. 30 years ago you could produce a decent game alone (for ZX Spectrum). 20 years ago you could produce a decent game with a few of your friends. 10 years ago you could produce a decent game with 20-30 people. Nowadays it takes hundreds of people.
The same with movies, except that movies are a bit older industry and it lived through a few technology changes. But generally, do not expect homebrew stuff to grow to Hollywood level of quality.
As for music, this may be different, because people still like low-tech (e.g. acoustic guitar) music, but I am sure that capital investments required grow for this industry as well. After all, Pro Tools have their high price tag for a reason.
Can't agree. I use a lot of open source software myself (even as I write these words, in Kubuntu) and it reminds me of Soviet cars: you always have problems where others don't and you need to know the guts of the car in order to drive it. But I won't argue about that. I'm rather sympathetic to "open source" (but not exactly Free Software) myself (more evidence can be found in my blog), it's just that I don't believe that solid development practices can arise where there's no monetary feedback - and FOSS seems to be hard to monetize. Again, let market decide - currently it looks like FOSS is on decline (together with "unlocked" hardware platforms like PC, where freedom to run random binaries is about to be sacrificed to gods of Security), but maybe - and hopefully - the situation will change.
I see your point. It all boils down which market you want to implement - integrating over time, developers will get the same money, but in different ways. If you outlaw certain licensing models or even whole property rights altogether, software market will look like one currently seen in countries with a weak law enforcement, i.e. a lot of low-quality cheap/free products which suck your money gradually, by nagging you with ads or asking to pay on each step (in the first case you become a product yourself). If law system is strong enough to support advanced licensing models, it opens up possibilities for upfront payments, so you don't have to pay each time you click.
However, it looks like the world is sliding into "el cheapo" approach and micropayments will become ubiquitous.
You sound as if I complained while I only pointed out why respecting property rights is essential in such a risky market.
By your logic, if you don't want to license certain property just for a limited time, simply don't. Nobody is forcing you to do that. Try to negotiate a price for an unlimited license (which is your only option due to your country's laws), which will offset possible resale, but until they do that, refrain from illegal (according to local laws) deals on Steam. Although I can foresee how Steam may be unwilling or unable to provide you with that if your country is not a large enough market, it may be easier to simply drop support for that territory.
But still, try to. It's business, there's should be no emotions.
I'm a game developer who happens to work in Poland and I track CD Projekt (GOG parent) stock close enough. GOG did bring them profit (a bit less than 1 mln USD for 1H2012), Wiedzmin (Witcher) for 360 got them even more (about 5 mln USD) but they are losing money on traditional retail market, their primary source of income up to now (source in Polish). Also, compare those numbers, which may be good for Poland, to 40 mln USD needed to create a modern AAA game.
Also, DRM is essential to delay piracy for the first month of game release. Games only really sell in the first few weeks after launch, if you didn't know - after that, people move on to something else and the "long tail" of sales begins (see just about any game's charts: [1], [2], [3]). So the games need to make up for that large upfront investment in first 4 to 6 weeks, if they don't break even, they are dead. Alan Wake, L.A. Noire, Max Payne 3 - all those arguably known and high profile titles are commercial failures. Most current triple A games flop or barely make even, but unless explicitly asked, publishers rarely admit it. However, if you work in gamedev you probably saw the closures of Grin, Pandemic, 38 Studios, and in general, it starts to happen too frequently.
So no, it's not just about "having control". There would be no need in control if existing model provided a sustainable way to earn money. Truth is, nowadays interactive entertainment market is a gamble.
Well, I see. But I think the easier resolution is making Steam illegal in your country. The problem isn't with DRM alone... if people treated software licenses in a responsible way, there would be no need to make "rights management" so strict. Traditional way (with which in mind your country's laws were written) simply is not sustainable. When games had book-sized budgets and the sale of a few hundred "copies" was enough to be profitable, this could work. With games having movie-sized budgets and millions of "copies" needed to break even, not so much. And it's not easy to scale down when people's expectations are so way up.
I'm a game developer myself. I do want to find an easy and affordable way for people to play my games. But this cannot be an one-sided relationship, we need a sustainable model of creating quality, AAA games. Traditional market is crashing into the ground, and the future looks ... well, maybe not grim, but certainly differently.
I predict domination of "pay4win" free2play games, ad-supported games and MMO-like "thin client" games in the near future - precisely because there's no mutual trust between game developers/publishers and gamers. Valve seems to be the closest to it, yet it still gets bashed here.