The current generation of consoles has writable persistant storage and network connectivity. I suspect that they can do a much better job of games like The Sims and Spore than the previous generation did.
Re:Non-Tech Percent of Web Traffic from Chrome
on
Google Chrome, Day 2
·
· Score: 4, Informative
The OS can be used to provide a download specific to your OS.
Or, in the case of Google Chrome, it can be used to make it far more difficult to download the Windows version when you're not on a Windows system.
I suspect that the comic page was just a rush-job because they were taken by surprise when their comic accidentally got leaked. I wouldn't read too much into it.
That's possible, but since true DRM is a logical fallacy (you can't simultaneously give someone access to data and not give them access to it at the same time) your argument seems kinda moot.
As an example, I point to Second Life where they tried to use a form of DRM to create a market for textures and 3D models. Some people went as far as taking the data directly out of their computer's video memory in order to create unauthorized copies of this data. Unless you can control everything from your server right to the user's neurons then someone will find a way to create copies, and it only takes one person to publish how to do it before everyone and his dog is doing it. See DVD CSS for another example.
The sprites in the BUILD engine could only be angled in one dimension, so it wasn't possible to tilt things up and down. Given that the original engine used flat sprites this wasn't a big limitation, but the more recent enhancements to the engine which allow full 3D models to be used in place of sprites really show off this limitation every time you fire a rocket diagonally up or down.
My favourite BUILD engine trick was using multiple rendering passes to defeat the limitations of the engine. DN3D did it for mirrors, but the subsequent games such as Blood used it to do room-over-room, water you could actually see into and various other things that we take for granted in today's fully-3D engines.
This is basically the only reason why I pirate games these days. The only exception is on Steam, where I've yet to be burned by this; they use the same "DRM" bits for both demos and full games and they seem to work just fine under Wine. That just leaves the question of whether the game itself is compatible, which is where the demo comes in. If I download the demo on Steam and it works, then I'm pretty confident that the full version will as well.
I actually ended up paying for Peggle Deluxe twice because I bought it from PopCap directly, found that their shitty copy protection doesn't get on with Wine, and then ended up buying it on Steam later. That left a bad taste in my mouth. I contacted PopCap about it but they wouldn't help me. I might have made more fuss if it was something more expensive than Peggle.
I'm far from an expert on Windows, but my understanding is that in the Windows model it is the client rather than the "server" that does the brunt of the work in printing to a network printer. The client needs a driver installed to format the output into an appropriate raw data stream that can be fed to the printer. If you've got a postscript printer then this is relatively easy under Linux, but for anything else you need to have a bunch of random filters on the client to translate postscript to PCL or whatever other random language the printer supports.
This does make setting up the opposite -- a Windows machine printing to a printer plugged into a Linux box -- quite easy, though. You can just tell CUPS to accept raw data from clients and let the Windows machines run the proprietary driver.
I was in much the same situation as the original poster about a year ago, and I set out to do something about it. I started off doing simple things like push-ups in the privacy of my home, and once I'd got into that habit, and made myself a little fitter in the process, I considered my next move.
Much like the OP, I get self-concious when jogging in public. However, I observed that cycling gets much less attention than jogging, so I went and bought myself a nice new bike and started a regime of cycling every day after work. (I did try cycling to work a few times, but there isn't really a good bike route to take and I don't like cycling on major roads.)
I found after I'd got into cycling maybe 5-10 miles around my neighbourhood that I was getting bored and demotivated, so I slacked off for a while and started to get tubby again. Recently I've re-awakened my interest in contributing to OpenStreetMap, which has proven to be the perfect excuse to bike around with a goal in mind other than just biking for biking's sake. For those who aren't familiar with the OpenStreetMap thing, basically I bike around with a GPS logger fixed to my handlebars and use the tracklogs collected as the basis for maps of my local area. These last few weeks I've been doing more miles per day than I ever did before because I'm thinking about something else while I'm doing it.
If OpenStreetMap already has coverage for your area then this isn't a very helpful suggestion, but I'm sure you could find other excuses to get out and about and get exercise without that being your primary goal.
Despite all of the arguments for the different styles, really in most cases it just comes down to what you learnt first. The projects I started with used the opening-braces-on-the-same-line style, so that's the style I'm most comfortable with.
If you pressed me to justify it, I'd probably respond that I only add newlines before or after bracketing delimeters, which means that you can just scan down the right of all lines to see whether they introduce a block or list ({, (), end a statement (;, }) or end an item in a list (,). This falls down in languages that don't let you end the terminal item in a list with its own comma, of course.
Really though, you could easily make a counter-argument that'd be just as valid. ("The lack of any symbol indicates the start of a block", for example.) It's just a matter of what you're used to.
In the case you describe in your first paragraph, the builder is no longer acting as a builder. I can buy a house that I didn't build and charge people to live in it. The act of building and the act of renting are different things: building is a one-time expense in time and materials (which may lead to other one-time expenses in building maintenence) while renting is an ongoing compensation for the fact that the person living in my house will inevitably be damaging it and is also depriving me of the ability to live in my house.
The bureau de la langue française proposes "le système dans lequel les réseaux informatiques sont reliés entre eux pour former un plus grand réseau mondial", but those unreasonable peasants insist on using the English word. What's wrong with them, I ask you?
What would be useful is a shim in Wine that can make Win32 apps that use.NET and.NET apps that use Win32 work when running under Wine. I imagine this being similar in principle to the shim that makes the Internet Explorer embedding API map to Mozilla.
Several times I've had grief from apps that have both native Win32 and.NET components due to the fact that Wine and Mono can't talk to one another. One hypothetical example that springs to mind is a.NET game being distributed via Valve's Steam: the.NET game can't run under Mono because it can't talk to Steam, but the.NET game also can't run under Wine because Wine has no support for.NET.
That situation doesn't change that much if you substitute most professional software engineers; although in theory I could make my own modifications to open source software, in practice I don't have time to.
Of course, when I say "I don't have time to" what I really mean is "the changes I want aren't valuable enough to me to justify the time spent", which isn't that different to "the changes I want aren't valuable enough to justify the cost to pay someone else to make them". Both users are still better off than they were with closed-source software: at least now they actually get to make that decision, rather than depend entirely on the whims of the original vendor.
The fact that you had to come up with these interesting workarounds proves the original poster's point: options interact in unintended ways, so adding a single new option is rarely as simple as it seems. The more options you have, the more combinations you have to consider and test. The developer of the "MacOS-style menus" feature had to go and alter the "focus follows mouse" feature in order to make his option work.
Microsoft Live Labs is working on a similar project to translate CIL (.NET bytecode) to JavaScript as part of their Volta project. It's part of a larger effort to allow you to write both the client-side and the server-side code in the same project and then have a post-processor split the resulting assemblies and generate all of the boilerplate RPC code to make the client-side bits run on the client and the server-side bits run on the server.
I don't really care who's suggesting it; I've been thinking similar things myself. The amount of content in HTML5 is getting ridiculous. If none of it can be declared final until it's all done then there's going to be uncertainty surrounding it for a long time to come, and that'll either put off implementors or lead to the spec hanving to be backward-compatible with earlier drafts of itself and it'll be years before there's interop between browsers.
Wouldn't it be better to have a single document standard that is the union of the features of OOXML and ODF?
It's not like they are radically different problem domains. We're talking about representing wordprocessor, spreadsheet and presentation documents here. How different can the featureset possibly be? This is especially true if you bear in mind that the applications in question are Microsoft Office and several suites (OpenOffice, KOffice, etc) whose express goal seems to be to do everything Microsoft Office does.
Once you reach the point where Microsoft Office, OpenOffice and KOffice (and, for shits and giggles, Apple's office suite too) all completely support OOXML and ODF, each app must support all of the features of both formats, so having two different formats is worthless.
The usual example of an advantage is that, assuming what you're contributing is generally useful, others will make use of it and improve it too. They may or may not share their improvements back with you, of course. Lots of companies contribute code to Linux, for example, and they (and we) all benefit from each other's work. Individual contributors may do valuable work that you might not have had time to do yourself, too; several open source projects that I've contributed to are "owned" (in the sense of who has the canonical repository) by some company that had the foresight to release some or all of their source code to the community. In return, they got bugfixes and improvements from me.
I think Java's proven that "write once, run anywhere" is a non-starter for desktop apps because no-one has managed to design a sufficiently abstract UI API that allows applications to "feel at home" across Windows, Mac and Linux while still remaining flexible. Most abstraction layers work only at the widget level, so they get caught out by such issues as the fact that Windows tends to prefer MDI -- at least traditionally -- while MacOS prefers lots of top-level windows that are grouped by application in the z-order. Or even something as simple as MacOS's separate menu bar.
The only realistic goal right now is to write your core application logic with the subset of the.NET Framework supported by both Mono and Microsoft's implementation, and then implement a separate frontend for each platform. You can ease the pain here by writing an abstraction layer with knowledge of your application so that only absolute minimum code is different across platforms.
If you're writing non-GUI apps then there's little technical reason not to go ahead and do this now. Since you're talking about your own projects you can easily just stick to the 2.0 API subset that Mono already supports and have cross-platform compatibilty. No-one's forcing you to use WCF and all of that other crazy stuff. Implementation bugs notwithstanding, any app that sticks to the stuff that's common between Mono and Windows -- which is quite a lot -- should work just fine across both implementations.
A better analog for C's fopen would probably be System.IO.File.Open. It even has essentially the same signature as fopen, and returns the moral equivalent of a fileno.
Regarding treating syntax trees as data, the latest version of C# has a feature which shows a movement in this direction. It's called Expression Trees and it allows the code to capture a representation of the compiler's parse tree for an expression and use it as data. It's used to implement Language Integrated Query against external data sources; for example, Microsoft has code that'll transform an expression tree into an SQL expression.
Of course, you are still constrained by the C# expression syntax and compile-time type checking. That's by design, though: the goal here was to ratain type checking, IDE autocomplete and so forth while being able to "remote" your expression evaluation.
Slashdot Mirror
The current generation of consoles has writable persistant storage and network connectivity. I suspect that they can do a much better job of games like The Sims and Spore than the previous generation did.
Or, in the case of Google Chrome, it can be used to make it far more difficult to download the Windows version when you're not on a Windows system.
I suspect that the comic page was just a rush-job because they were taken by surprise when their comic accidentally got leaked. I wouldn't read too much into it.
That's possible, but since true DRM is a logical fallacy (you can't simultaneously give someone access to data and not give them access to it at the same time) your argument seems kinda moot.
As an example, I point to Second Life where they tried to use a form of DRM to create a market for textures and 3D models. Some people went as far as taking the data directly out of their computer's video memory in order to create unauthorized copies of this data. Unless you can control everything from your server right to the user's neurons then someone will find a way to create copies, and it only takes one person to publish how to do it before everyone and his dog is doing it. See DVD CSS for another example.
The sprites in the BUILD engine could only be angled in one dimension, so it wasn't possible to tilt things up and down. Given that the original engine used flat sprites this wasn't a big limitation, but the more recent enhancements to the engine which allow full 3D models to be used in place of sprites really show off this limitation every time you fire a rocket diagonally up or down.
My favourite BUILD engine trick was using multiple rendering passes to defeat the limitations of the engine. DN3D did it for mirrors, but the subsequent games such as Blood used it to do room-over-room, water you could actually see into and various other things that we take for granted in today's fully-3D engines.
This is basically the only reason why I pirate games these days. The only exception is on Steam, where I've yet to be burned by this; they use the same "DRM" bits for both demos and full games and they seem to work just fine under Wine. That just leaves the question of whether the game itself is compatible, which is where the demo comes in. If I download the demo on Steam and it works, then I'm pretty confident that the full version will as well.
I actually ended up paying for Peggle Deluxe twice because I bought it from PopCap directly, found that their shitty copy protection doesn't get on with Wine, and then ended up buying it on Steam later. That left a bad taste in my mouth. I contacted PopCap about it but they wouldn't help me. I might have made more fuss if it was something more expensive than Peggle.
Quick! Get out while you still can!
I'm far from an expert on Windows, but my understanding is that in the Windows model it is the client rather than the "server" that does the brunt of the work in printing to a network printer. The client needs a driver installed to format the output into an appropriate raw data stream that can be fed to the printer. If you've got a postscript printer then this is relatively easy under Linux, but for anything else you need to have a bunch of random filters on the client to translate postscript to PCL or whatever other random language the printer supports.
This does make setting up the opposite -- a Windows machine printing to a printer plugged into a Linux box -- quite easy, though. You can just tell CUPS to accept raw data from clients and let the Windows machines run the proprietary driver.
The distribution would create the categorisation, of course!
Oh, wait...
I was in much the same situation as the original poster about a year ago, and I set out to do something about it. I started off doing simple things like push-ups in the privacy of my home, and once I'd got into that habit, and made myself a little fitter in the process, I considered my next move.
Much like the OP, I get self-concious when jogging in public. However, I observed that cycling gets much less attention than jogging, so I went and bought myself a nice new bike and started a regime of cycling every day after work. (I did try cycling to work a few times, but there isn't really a good bike route to take and I don't like cycling on major roads.)
I found after I'd got into cycling maybe 5-10 miles around my neighbourhood that I was getting bored and demotivated, so I slacked off for a while and started to get tubby again. Recently I've re-awakened my interest in contributing to OpenStreetMap, which has proven to be the perfect excuse to bike around with a goal in mind other than just biking for biking's sake. For those who aren't familiar with the OpenStreetMap thing, basically I bike around with a GPS logger fixed to my handlebars and use the tracklogs collected as the basis for maps of my local area. These last few weeks I've been doing more miles per day than I ever did before because I'm thinking about something else while I'm doing it.
If OpenStreetMap already has coverage for your area then this isn't a very helpful suggestion, but I'm sure you could find other excuses to get out and about and get exercise without that being your primary goal.
If it's a function declaration rather than a function call that's wrapping over multiple lines, you've got too many arguments!
Despite all of the arguments for the different styles, really in most cases it just comes down to what you learnt first. The projects I started with used the opening-braces-on-the-same-line style, so that's the style I'm most comfortable with.
If you pressed me to justify it, I'd probably respond that I only add newlines before or after bracketing delimeters, which means that you can just scan down the right of all lines to see whether they introduce a block or list ({, (), end a statement (;, }) or end an item in a list (,). This falls down in languages that don't let you end the terminal item in a list with its own comma, of course.
Really though, you could easily make a counter-argument that'd be just as valid. ("The lack of any symbol indicates the start of a block", for example.) It's just a matter of what you're used to.
In the case you describe in your first paragraph, the builder is no longer acting as a builder. I can buy a house that I didn't build and charge people to live in it. The act of building and the act of renting are different things: building is a one-time expense in time and materials (which may lead to other one-time expenses in building maintenence) while renting is an ongoing compensation for the fact that the person living in my house will inevitably be damaging it and is also depriving me of the ability to live in my house.
The bureau de la langue française proposes "le système dans lequel les réseaux informatiques sont reliés entre eux pour former un plus grand réseau mondial", but those unreasonable peasants insist on using the English word. What's wrong with them, I ask you?
Yes.
What would be useful is a shim in Wine that can make Win32 apps that use .NET and .NET apps that use Win32 work when running under Wine. I imagine this being similar in principle to the shim that makes the Internet Explorer embedding API map to Mozilla.
Several times I've had grief from apps that have both native Win32 and .NET components due to the fact that Wine and Mono can't talk to one another. One hypothetical example that springs to mind is a .NET game being distributed via Valve's Steam: the .NET game can't run under Mono because it can't talk to Steam, but the .NET game also can't run under Wine because Wine has no support for .NET.
That situation doesn't change that much if you substitute most professional software engineers; although in theory I could make my own modifications to open source software, in practice I don't have time to.
Of course, when I say "I don't have time to" what I really mean is "the changes I want aren't valuable enough to me to justify the time spent", which isn't that different to "the changes I want aren't valuable enough to justify the cost to pay someone else to make them". Both users are still better off than they were with closed-source software: at least now they actually get to make that decision, rather than depend entirely on the whims of the original vendor.
The fact that you had to come up with these interesting workarounds proves the original poster's point: options interact in unintended ways, so adding a single new option is rarely as simple as it seems. The more options you have, the more combinations you have to consider and test. The developer of the "MacOS-style menus" feature had to go and alter the "focus follows mouse" feature in order to make his option work.
Microsoft Live Labs is working on a similar project to translate CIL (.NET bytecode) to JavaScript as part of their Volta project. It's part of a larger effort to allow you to write both the client-side and the server-side code in the same project and then have a post-processor split the resulting assemblies and generate all of the boilerplate RPC code to make the client-side bits run on the client and the server-side bits run on the server.
I don't really care who's suggesting it; I've been thinking similar things myself. The amount of content in HTML5 is getting ridiculous. If none of it can be declared final until it's all done then there's going to be uncertainty surrounding it for a long time to come, and that'll either put off implementors or lead to the spec hanving to be backward-compatible with earlier drafts of itself and it'll be years before there's interop between browsers.
Wouldn't it be better to have a single document standard that is the union of the features of OOXML and ODF?
It's not like they are radically different problem domains. We're talking about representing wordprocessor, spreadsheet and presentation documents here. How different can the featureset possibly be? This is especially true if you bear in mind that the applications in question are Microsoft Office and several suites (OpenOffice, KOffice, etc) whose express goal seems to be to do everything Microsoft Office does.
Once you reach the point where Microsoft Office, OpenOffice and KOffice (and, for shits and giggles, Apple's office suite too) all completely support OOXML and ODF, each app must support all of the features of both formats, so having two different formats is worthless.
The usual example of an advantage is that, assuming what you're contributing is generally useful, others will make use of it and improve it too. They may or may not share their improvements back with you, of course. Lots of companies contribute code to Linux, for example, and they (and we) all benefit from each other's work. Individual contributors may do valuable work that you might not have had time to do yourself, too; several open source projects that I've contributed to are "owned" (in the sense of who has the canonical repository) by some company that had the foresight to release some or all of their source code to the community. In return, they got bugfixes and improvements from me.
I think Java's proven that "write once, run anywhere" is a non-starter for desktop apps because no-one has managed to design a sufficiently abstract UI API that allows applications to "feel at home" across Windows, Mac and Linux while still remaining flexible. Most abstraction layers work only at the widget level, so they get caught out by such issues as the fact that Windows tends to prefer MDI -- at least traditionally -- while MacOS prefers lots of top-level windows that are grouped by application in the z-order. Or even something as simple as MacOS's separate menu bar.
The only realistic goal right now is to write your core application logic with the subset of the .NET Framework supported by both Mono and Microsoft's implementation, and then implement a separate frontend for each platform. You can ease the pain here by writing an abstraction layer with knowledge of your application so that only absolute minimum code is different across platforms.
If you're writing non-GUI apps then there's little technical reason not to go ahead and do this now. Since you're talking about your own projects you can easily just stick to the 2.0 API subset that Mono already supports and have cross-platform compatibilty. No-one's forcing you to use WCF and all of that other crazy stuff. Implementation bugs notwithstanding, any app that sticks to the stuff that's common between Mono and Windows -- which is quite a lot -- should work just fine across both implementations.
A better analog for C's fopen would probably be System.IO.File.Open. It even has essentially the same signature as fopen, and returns the moral equivalent of a fileno.
Regarding treating syntax trees as data, the latest version of C# has a feature which shows a movement in this direction. It's called Expression Trees and it allows the code to capture a representation of the compiler's parse tree for an expression and use it as data. It's used to implement Language Integrated Query against external data sources; for example, Microsoft has code that'll transform an expression tree into an SQL expression.
Of course, you are still constrained by the C# expression syntax and compile-time type checking. That's by design, though: the goal here was to ratain type checking, IDE autocomplete and so forth while being able to "remote" your expression evaluation.