Whoa, thanks for the link! I'd never heard of that stuff. I shame it wasn't mainlined already or we could have saved ourselves some pain. It always surprises me just how much cool stuff is out there for Linux that you don't see.
How long until the APIs provided by CUSE are used to implement an arbitrary-character-devices-over-network protocol? That would be pretty cool and useful. Should be doable, from what I understand of how it works.
The description of the in-kernel changes on LWN's article on the subject (http://lwn.net/Articles/308445/) made it sound like the infrastructure could also be used for stuff like network filesystems whose/dev contains *remote* character devices (currently NFS device nodes are always serviced by local device drivers, so you can't use NFS to export devices). This might be especially useful for 9P, which is actually designed for device remoting since that's what Plan 9 did as a matter of course.
Before we all moved on to worrying about PulseAudio it was traditional for us to complain about legacy apps using OSS, the difficulties associated with wrapping them, the nastiness associated with OSS emulation being implemented in the kernel, etc. Those apps won't have gone away.
Previous attempts to emulate OSS using ALSA have included the aoss tool, which I believe did some mildly ungodly tricks to intercept calls that would usually go to the OSS APIs. It didn't always work, for me, as it depends on what the (often weird and proprietary) app is doing to access the OSS API in the first place. PulseAudio has to provide a tool to help you redirect legacy OSS apps to talk to PulseAudio instead. It's all Made Of Ick.
CUSE (character devices in userspace) allows a userspace program to provide a character device node in/dev and implement it using custom code, rather than relying on an in-kernel driver. When apps open the device node they'll *really* be talking to the userspace daemon implementing the device emulation, rather than to an in-kernel driver (though, of course, the kernel will be involved in relaying the communications through the device interface). This is very similar to what FUSE does for filesystems. The neat thing here is that weird tricks to catch OSS accesses by applications are not needed - the OSS device can simply be "faked" by the real sound daemon. Because it's implemented at device level, it doesn't matter what nasty hacks the OSS application is doing to access the soundcard - you'll *always* be able to grab its sound output from the fake device and do the right thing. No more running legacy apps with an OSS-related wrapper - and no more having the wrapper fail to work!
The end result should be that sound Just Works, even for awkward proprietary apps. CUSE will not automagically fix this on it's own, though - we need to wait for the sound daemons like PulseAudio to catch up and implement the emulation. This might also allow OSS emulation to be removed from the kernel, which AFAIK also supports some variant of OSS-on-ALSA.
How was the parent modded troll, it's completely valid!
It's a good idea. There have been networking over USB devices (by which I mean plugging both machines USB ports into the device, not "merely" a USB ethernet adaptor). The problem with doing this with USB, rather than Firewire is that USB has a really strong concept of "host" and "device". The cables are made to only plug into certain combinations of endpoints because, sadly, only certain combinations of endpoints can possibly work. You can't plug the host controller of one PC into another, since they're only expecting to talk to devices, not another controller. This is in contrast to Firewire, which is peer-to-peer and (in principle) anything could talk to anything over it.
The unfortunate consequence is that you don't just get to do networking over a nice, cheap cable as you do with Firewire. You actually need a little device box in between so that both hosts can believe they're talking to a peripheral, not another host. This approach, on its own, wouldn't let you plug in "remote" devices either so you'd have to set some other protocol up (plenty of existing options here) to talk to devices at the other end. You have to be a bit careful because most devices would barf horribly if there are multiple users - uncontrolled shared access to a disk device is a good way to lose all your data, for instance.
Although it's fun to do IP over Firewire, I'm not familiar with exactly how it's implemented. What intrigues me is the prospect of running increasingly sophisticated high-performance protocols over Firewire. As I understand it you can basically get remote DMA access to the "other end's" memory. This obviously has severe security implications but it could be quite nice in a mutually-trusting cluster. There are various protocols (e.g. used by Infiniband) for having communications over remote DMA. I wonder if anyone could put together an "infiniband lite" that just ran over Firewire. It'd be cool, though I don't know if it would be particularly useful;-) (plus it would lack the user accessible networking Infiniband has)
An interesting problem is when you have a jerk-genius who is *occasionally* wrong but is used to being right all the time simply because they are very clever. Sometimes they don't seem to recognise the unfamiliar sensation of wrongness that some of us feel a bit more often;-) Plenty of examples of this if you read the Daily WTF or even just the LKML!
Obviously, people are going to prefer to work with somebody who's effective at their work than somebody who is always wrong and creates problems for other people. But it's not like there's a choice only between "Good at work but nasty" and "Bad at work but nice". There are people who are nasty and also mediocre at their jobs, there are pleasant people who are highly skilled. So you might just luck out and get a nice, skilled person (or, if your recruiting process is not good, the reverse). Also, it's really not the whole picture. A skilled employee who won't / can't work with his colleagues (or one who nobody will work with because of his bad attitude) is not necessarily going to save work overall. I hate the phrase "team player" as it sometimes has connotations of weasel-speak. But the basic idea that a skilled worker can nevertheless not be a net gain *in a particular scenario* is true enough.
Many of us will have come across "uber hackers" who are vastly more productive in technical work than the programmers around them but who, through inconsiderate or unhelpful behaviour, slow down all the people around them as well as creating an unhappy working atmosphere. It's not that they're not valuable employees - they are. But they need to be deployed in the places where they'll make the biggest productivity win. In my opinion, laying down some specific guidelines about how their work relates to the rest of the team is also helpful, though not always possible.
Really you always want the best person for the job. Sometimes a friendly "people person" will be better in certain roles - management or technical. Sometimes a more abrasive personality may be a more effective manager or coder. What frustrates me is when I say an elite coder being coddled and allowed to disrupt all of the junior programmers' work, just because the management is not strong enough to direct him or her into more productive behaviours. By all means hold on to your elite technical staff and keep them happy - but don't let them drag everyone down in your efforts to please them - find a task they can work on alone, if necessary. The same would apply if you had an easy-going, friendly person who wasn't good at their job - find a better use for their talents or let them go if you can't fit them in.
Maybe I'm just old but I preferred when "Pentium n" is the new processor and probably better than my "Pentium n-1".
Not to troll, but the Pentium 4 line was a distinct step backwards from the Pentium III in many respects.
Of course, that's not trollish at all, as it's simply true! The Pentium 4s were still, in some sense, "better" as they (eventually! The first Pentium 4s were slower than PIII in some benchmarks, I think) exceeded the raw performance of the PIII. But in terms of microarchitecture, the Pentium 4 was a bit of a dead end. A shame in a way, as it did seem like Intel were thinking toward the future in some respects with that design and then instead ended up wasting a lot of time. The Pentium M, which begat the Core etc was much closer to the PIII than the Pentium 4 was to either of them.
Some good tech from he Pentium 4 has made its way into other Intel chips, though, so it's not a dead loss. It was a disappointing period, though.
I don't understand how Core was an improvement on Pentium. Pentium was iconic and a household name (which is pretty difficult to achieve in such a low-level field, especially as Intel typically doesn't sell direct to consumers). Core is boring and misleading. For instance, Core 2 Duo... whuh?! Doesn't sound that impressive but definitely sounds muddled.
Now there's this i7 and i5 business. Maybe I'm just old but I preferred when "Pentium n" is the new processor and probably better than my "Pentium n-1". I can understand they may have wanted to avoid the Sexium but at least that would be distinctive. Core is about as boring as traditional IBM naming.
Their hardware is excellent these days. They went through some doldrums but generally seemed to sort themselves out pretty effectively and come out with ace stuff. Their Linux support is usually great too. Maybe one of these will be my new PC...
Agreed on immersion using all the available features: when I was playing through Bioshock I got so used to listening for creaking floorboards, doors and footsteps that every time I heard a noise in the house whilst working I would have the urge to spin around wielding a wrench.
Oblivion is interesting in that it's a first-person (you can play 3rd person but reviews say it's not so good) RPG, including some ongoing conversations with characters who give you quests and sometimes help you. To a certain extent that makes you feel a connection to them that you wouldn't necessarily get in an FPS. But the connection I feel with the characters is nowhere near the level I'd got from playing Mass Effect, though that's primarily due to the cinematic nature of the (3rd person) dialogue scenes as opposed to the rest of the 3rd person gameplay. The presentation of these, plus people's reactions to the different characteristics you could display (i.e. whether you were being paragon or renegade) made the characters really come alive for me.
On the other hand, Halo is a true FPS where I nevertheless like and have sympathy for the other characters. Maybe it's partly because I really like the game but I think it's also due to the cinematic presentation, the good voice acting and the fun characters and plot. There's no control over the interaction with the other characters, dialogue-wise but they nevertheless have distinctive personalities, so it matters what happens to them.
I agree, Mass Effect was awesome and well worth repeat playthroughs. What it perhaps lost, compared so some RPGs, in the multitude of paths through the game (although there was still a decent amount of choice here) it more than won back through the cinematic presentation, well-directed cutscenes and great voice acting + dialogue. It felt like playing through a great movie. And your choices could have pretty epic effects on the fate of your party and the galaxy - effects which will be carried through to ME2 and ME3, continuing to affect the plot!
Both the DLCs, on Xbox Live, were very competitively priced - you paid less and got more than most DLC available on there. It's a shame Pinnacle Station didn't have more plot, I'd heard it hyped up (though this was subsequently somewhat withdrawn) as more than that. However, the combat in Mass Effect was pretty fun, esp with advanced use of powers. Being able to indulge in combat whenever I want rather than just when the missions allow it is probably worth the amount I paid - it's just perhaps not quite such good value as the more substantial plot-based additions from Bring Down The Sky. I really like the way they simply enlarged the game world with the DLC, rather than tacking on extra missions for those who had completed the game. It would be slightly unfortunate to have to play through the game again to get to the DLC except for the fact that the game is *worth* playing through again!
I've heard that the DRM on Mass Effect harmed its adoption on the PC platform and annoyed a lot of people. On the Xbox the DRM is no more obnoxious than for any other game, thankfully - no phoning home, unlike the PC version and no install limits.
Yeah, I agree that Britain is a good place to start - apart from anything else, there's a reasonable acknowledgement amongst many British people that we can / should do better.
And Turing should be a good place to campaign because his position is so egregious - he deserved to be commended as a key wartime figure and a prominent scientist, yet the treatment he received was inhuman.
My main objection to the comment I originally replied to was that I sometimes see Britain's past held up as a particular example of a country whose policies have been harmful. I think that's accurate enough - Britain has been involved in some awful stuff - but I just don't think it's fair or representative to suggest that they're an outlier in this respect.
I basically just objected to what I saw as an implication that other countries are / have been somehow less bad, rather than the concept that Britain ought to do better.
And agreed - justifications based on what other people are doing are rarely relevant to an argument, at least if you like to think of yourself as doing the right thing rather than just being part of the scrum. A lot of countries try to have it both ways and that doesn't really work - I'm not even sure it pays off for them from a purely selfish perspective in the end.
Bettering yourself is great. I just suggested that basically all the nations in the world have things to be sorry for, not just the ones who are widely known or widely disliked.
I can see why you might have thought I was offering this as justification but I'm really just saying "Why focus only on Britain's wrongs when there are so many other countries who are equally guilty?"
Not disagreeing with you on the British policies of the past and the damage they've done. But while they're about it, they could do with saying sorry for the current damaging policies.
And while we're about that, how about all the other nations of the world do the same - I don't think any of the major players in world politics have a history that's free from disgusting episodes and damaging policies. I don't think any of the major players in world politics lack *current* policies that aren't doing harm for self-interested reasons. And I can't imagine the nations we don't hear about are any better.
Actually, I now remember the other thing which I should resembled the "release early, release often" aspects of OSS - IIRC part of the point of scrum is a continual re-evaluation of what features are ready, what needs to be done next, etc. Except that, again, in OSS this is distributed.
I find it pretty interesting the way software development in companies increasingly seems to resemble the processes that have semi-naturally evolved in distributed open source projects.
OK, so the distinction is that scrum has agreed goals (from an outside source) that the team will work on getting done in time for the deadline? Whereas in OSS generally the developers decide the goals themselves. Makes sense. There's quite a similarity but the OSS stuff relatively undirected I guess!
I had a friend tell me how great and productive scrum development worked. His description, though, sounded basically like the model that many OSS projects evolve towards: instead of monolithically specifying the product, you do things in a set of short-term development sprints focused on finishing off selected features. Sounds very much like the operation of all the OSS projects (Linux being a particularly strong example) which do short, deadline-based releases and include whatever features are done.
To me this seems more like a formal version of what many programmers are naturally inclined to do, as opposed to imposing a structure of what they "should" do, as in waterfall for instance. Is this a good thing? I don't know.
"Russel Smith, one of Australia's principal criminologists, is pushing for first-time computer users to be required to earn a license"
"He said that education was secondary to better technology solutions."
I know, I know, I must be new here... Sounds like Russel Smith is saying maybe it's worth considering in the future, once better technology is in place. Which in my book is different to "pushing" for it. To be fair the original article was a bit sensationalist about this but on this occasion the user's submission to Slashdot appears not to have been - it's the editor commentary that misleads slightly and makes it all sound very melodramatic.
It makes for a "better" story but not better journalism.
Really? Interesting, that hadn't clicked with me. What do you lose, time-travel wise?
I just remembered the problem that time cloning units has the disadvantage of damage propagating - I suppose the appropriate tactic would be to station the "later" unit in the front lines with the "original" providing support. Conversely you'd want to try to figure out (or maybe it tells you) what the original units of your enemy are and kill them.
I don't know if damage propagation is instant or occurs via the time waves.
My understanding is that because the game propagates cause and effect through "meta time" (player time), the game will oscillate between just the factory and just the unit existing. Eventually there's a cut-off point after a certain amount of... something (meta time, presumably), at which point you end up keeping whichever of them is currently in existence.
IIRC the effects of a factory being taken out in the past (and maybe ditto for the resources thing, don't really know) are the following:
When the factory is destroyed in the past, you'll stop being able to build units when working in the past. The units you'd built with the factory *originally* (i.e. earlier in *player time*, not game time) will still exist in the present, they won't just vanish.
The destruction of the factory will propagate as a "time wave", through meta time. Which is to say that the effects of destroying the factory will eventually (from the player's PoV) appear in the present. At that point, yes, your units (and the factory) will probably disappear.
In the meantime you may have gone back in time with those units (!) and saved the factory (!!). According to my understanding, you may then have to wait until *that* change propagates through meta-time to the present. Until this happens you will not have access to that factory or the units it made when playing in the present.
Slashdot Mirror
Whoa, thanks for the link! I'd never heard of that stuff. I shame it wasn't mainlined already or we could have saved ourselves some pain. It always surprises me just how much cool stuff is out there for Linux that you don't see.
How long until the APIs provided by CUSE are used to implement an arbitrary-character-devices-over-network protocol? That would be pretty cool and useful. Should be doable, from what I understand of how it works.
The description of the in-kernel changes on LWN's article on the subject (http://lwn.net/Articles/308445/) made it sound like the infrastructure could also be used for stuff like network filesystems whose /dev contains *remote* character devices (currently NFS device nodes are always serviced by local device drivers, so you can't use NFS to export devices). This might be especially useful for 9P, which is actually designed for device remoting since that's what Plan 9 did as a matter of course.
Before we all moved on to worrying about PulseAudio it was traditional for us to complain about legacy apps using OSS, the difficulties associated with wrapping them, the nastiness associated with OSS emulation being implemented in the kernel, etc. Those apps won't have gone away.
Previous attempts to emulate OSS using ALSA have included the aoss tool, which I believe did some mildly ungodly tricks to intercept calls that would usually go to the OSS APIs. It didn't always work, for me, as it depends on what the (often weird and proprietary) app is doing to access the OSS API in the first place. PulseAudio has to provide a tool to help you redirect legacy OSS apps to talk to PulseAudio instead. It's all Made Of Ick.
CUSE (character devices in userspace) allows a userspace program to provide a character device node in /dev and implement it using custom code, rather than relying on an in-kernel driver. When apps open the device node they'll *really* be talking to the userspace daemon implementing the device emulation, rather than to an in-kernel driver (though, of course, the kernel will be involved in relaying the communications through the device interface). This is very similar to what FUSE does for filesystems. The neat thing here is that weird tricks to catch OSS accesses by applications are not needed - the OSS device can simply be "faked" by the real sound daemon. Because it's implemented at device level, it doesn't matter what nasty hacks the OSS application is doing to access the soundcard - you'll *always* be able to grab its sound output from the fake device and do the right thing. No more running legacy apps with an OSS-related wrapper - and no more having the wrapper fail to work!
The end result should be that sound Just Works, even for awkward proprietary apps. CUSE will not automagically fix this on it's own, though - we need to wait for the sound daemons like PulseAudio to catch up and implement the emulation. This might also allow OSS emulation to be removed from the kernel, which AFAIK also supports some variant of OSS-on-ALSA.
How was the parent modded troll, it's completely valid!
It's a good idea. There have been networking over USB devices (by which I mean plugging both machines USB ports into the device, not "merely" a USB ethernet adaptor). The problem with doing this with USB, rather than Firewire is that USB has a really strong concept of "host" and "device". The cables are made to only plug into certain combinations of endpoints because, sadly, only certain combinations of endpoints can possibly work. You can't plug the host controller of one PC into another, since they're only expecting to talk to devices, not another controller. This is in contrast to Firewire, which is peer-to-peer and (in principle) anything could talk to anything over it.
The unfortunate consequence is that you don't just get to do networking over a nice, cheap cable as you do with Firewire. You actually need a little device box in between so that both hosts can believe they're talking to a peripheral, not another host. This approach, on its own, wouldn't let you plug in "remote" devices either so you'd have to set some other protocol up (plenty of existing options here) to talk to devices at the other end. You have to be a bit careful because most devices would barf horribly if there are multiple users - uncontrolled shared access to a disk device is a good way to lose all your data, for instance.
Although it's fun to do IP over Firewire, I'm not familiar with exactly how it's implemented. What intrigues me is the prospect of running increasingly sophisticated high-performance protocols over Firewire. As I understand it you can basically get remote DMA access to the "other end's" memory. This obviously has severe security implications but it could be quite nice in a mutually-trusting cluster. There are various protocols (e.g. used by Infiniband) for having communications over remote DMA. I wonder if anyone could put together an "infiniband lite" that just ran over Firewire. It'd be cool, though I don't know if it would be particularly useful ;-) (plus it would lack the user accessible networking Infiniband has)
We heard you like your audio to work, so we put a sound API in your sound API, so you can have silence whilst you listen!
An interesting problem is when you have a jerk-genius who is *occasionally* wrong but is used to being right all the time simply because they are very clever. Sometimes they don't seem to recognise the unfamiliar sensation of wrongness that some of us feel a bit more often ;-) Plenty of examples of this if you read the Daily WTF or even just the LKML!
Obviously, people are going to prefer to work with somebody who's effective at their work than somebody who is always wrong and creates problems for other people. But it's not like there's a choice only between "Good at work but nasty" and "Bad at work but nice". There are people who are nasty and also mediocre at their jobs, there are pleasant people who are highly skilled. So you might just luck out and get a nice, skilled person (or, if your recruiting process is not good, the reverse). Also, it's really not the whole picture. A skilled employee who won't / can't work with his colleagues (or one who nobody will work with because of his bad attitude) is not necessarily going to save work overall. I hate the phrase "team player" as it sometimes has connotations of weasel-speak. But the basic idea that a skilled worker can nevertheless not be a net gain *in a particular scenario* is true enough.
Many of us will have come across "uber hackers" who are vastly more productive in technical work than the programmers around them but who, through inconsiderate or unhelpful behaviour, slow down all the people around them as well as creating an unhappy working atmosphere. It's not that they're not valuable employees - they are. But they need to be deployed in the places where they'll make the biggest productivity win. In my opinion, laying down some specific guidelines about how their work relates to the rest of the team is also helpful, though not always possible.
Really you always want the best person for the job. Sometimes a friendly "people person" will be better in certain roles - management or technical. Sometimes a more abrasive personality may be a more effective manager or coder. What frustrates me is when I say an elite coder being coddled and allowed to disrupt all of the junior programmers' work, just because the management is not strong enough to direct him or her into more productive behaviours. By all means hold on to your elite technical staff and keep them happy - but don't let them drag everyone down in your efforts to please them - find a task they can work on alone, if necessary. The same would apply if you had an easy-going, friendly person who wasn't good at their job - find a better use for their talents or let them go if you can't fit them in.
Maybe I'm just old but I preferred when "Pentium n" is the new processor and probably better than my "Pentium n-1".
Not to troll, but the Pentium 4 line was a distinct step backwards from the Pentium III in many respects.
Of course, that's not trollish at all, as it's simply true! The Pentium 4s were still, in some sense, "better" as they (eventually! The first Pentium 4s were slower than PIII in some benchmarks, I think) exceeded the raw performance of the PIII. But in terms of microarchitecture, the Pentium 4 was a bit of a dead end. A shame in a way, as it did seem like Intel were thinking toward the future in some respects with that design and then instead ended up wasting a lot of time. The Pentium M, which begat the Core etc was much closer to the PIII than the Pentium 4 was to either of them.
Some good tech from he Pentium 4 has made its way into other Intel chips, though, so it's not a dead loss. It was a disappointing period, though.
Wait, that's a phenomenal name!
I don't understand how Core was an improvement on Pentium. Pentium was iconic and a household name (which is pretty difficult to achieve in such a low-level field, especially as Intel typically doesn't sell direct to consumers). Core is boring and misleading. For instance, Core 2 Duo ... whuh?! Doesn't sound that impressive but definitely sounds muddled.
Now there's this i7 and i5 business. Maybe I'm just old but I preferred when "Pentium n" is the new processor and probably better than my "Pentium n-1". I can understand they may have wanted to avoid the Sexium but at least that would be distinctive. Core is about as boring as traditional IBM naming.
Their hardware is excellent these days. They went through some doldrums but generally seemed to sort themselves out pretty effectively and come out with ace stuff. Their Linux support is usually great too. Maybe one of these will be my new PC...
Agreed on immersion using all the available features: when I was playing through Bioshock I got so used to listening for creaking floorboards, doors and footsteps that every time I heard a noise in the house whilst working I would have the urge to spin around wielding a wrench.
Oblivion is interesting in that it's a first-person (you can play 3rd person but reviews say it's not so good) RPG, including some ongoing conversations with characters who give you quests and sometimes help you. To a certain extent that makes you feel a connection to them that you wouldn't necessarily get in an FPS. But the connection I feel with the characters is nowhere near the level I'd got from playing Mass Effect, though that's primarily due to the cinematic nature of the (3rd person) dialogue scenes as opposed to the rest of the 3rd person gameplay. The presentation of these, plus people's reactions to the different characteristics you could display (i.e. whether you were being paragon or renegade) made the characters really come alive for me.
On the other hand, Halo is a true FPS where I nevertheless like and have sympathy for the other characters. Maybe it's partly because I really like the game but I think it's also due to the cinematic presentation, the good voice acting and the fun characters and plot. There's no control over the interaction with the other characters, dialogue-wise but they nevertheless have distinctive personalities, so it matters what happens to them.
I agree, Mass Effect was awesome and well worth repeat playthroughs. What it perhaps lost, compared so some RPGs, in the multitude of paths through the game (although there was still a decent amount of choice here) it more than won back through the cinematic presentation, well-directed cutscenes and great voice acting + dialogue. It felt like playing through a great movie. And your choices could have pretty epic effects on the fate of your party and the galaxy - effects which will be carried through to ME2 and ME3, continuing to affect the plot!
Both the DLCs, on Xbox Live, were very competitively priced - you paid less and got more than most DLC available on there. It's a shame Pinnacle Station didn't have more plot, I'd heard it hyped up (though this was subsequently somewhat withdrawn) as more than that. However, the combat in Mass Effect was pretty fun, esp with advanced use of powers. Being able to indulge in combat whenever I want rather than just when the missions allow it is probably worth the amount I paid - it's just perhaps not quite such good value as the more substantial plot-based additions from Bring Down The Sky. I really like the way they simply enlarged the game world with the DLC, rather than tacking on extra missions for those who had completed the game. It would be slightly unfortunate to have to play through the game again to get to the DLC except for the fact that the game is *worth* playing through again!
I've heard that the DRM on Mass Effect harmed its adoption on the PC platform and annoyed a lot of people. On the Xbox the DRM is no more obnoxious than for any other game, thankfully - no phoning home, unlike the PC version and no install limits.
Yeah, I agree that Britain is a good place to start - apart from anything else, there's a reasonable acknowledgement amongst many British people that we can / should do better.
And Turing should be a good place to campaign because his position is so egregious - he deserved to be commended as a key wartime figure and a prominent scientist, yet the treatment he received was inhuman.
My main objection to the comment I originally replied to was that I sometimes see Britain's past held up as a particular example of a country whose policies have been harmful. I think that's accurate enough - Britain has been involved in some awful stuff - but I just don't think it's fair or representative to suggest that they're an outlier in this respect.
I basically just objected to what I saw as an implication that other countries are / have been somehow less bad, rather than the concept that Britain ought to do better.
And agreed - justifications based on what other people are doing are rarely relevant to an argument, at least if you like to think of yourself as doing the right thing rather than just being part of the scrum. A lot of countries try to have it both ways and that doesn't really work - I'm not even sure it pays off for them from a purely selfish perspective in the end.
Eh? Which "people" race to the bottom?
Bettering yourself is great. I just suggested that basically all the nations in the world have things to be sorry for, not just the ones who are widely known or widely disliked.
I can see why you might have thought I was offering this as justification but I'm really just saying "Why focus only on Britain's wrongs when there are so many other countries who are equally guilty?"
Not disagreeing with you on the British policies of the past and the damage they've done. But while they're about it, they could do with saying sorry for the current damaging policies.
And while we're about that, how about all the other nations of the world do the same - I don't think any of the major players in world politics have a history that's free from disgusting episodes and damaging policies. I don't think any of the major players in world politics lack *current* policies that aren't doing harm for self-interested reasons. And I can't imagine the nations we don't hear about are any better.
You'd think that with his salary he'd be able to afford some cheese with his whine.
Actually, I now remember the other thing which I should resembled the "release early, release often" aspects of OSS - IIRC part of the point of scrum is a continual re-evaluation of what features are ready, what needs to be done next, etc. Except that, again, in OSS this is distributed.
I find it pretty interesting the way software development in companies increasingly seems to resemble the processes that have semi-naturally evolved in distributed open source projects.
OK, so the distinction is that scrum has agreed goals (from an outside source) that the team will work on getting done in time for the deadline? Whereas in OSS generally the developers decide the goals themselves. Makes sense. There's quite a similarity but the OSS stuff relatively undirected I guess!
I had a friend tell me how great and productive scrum development worked. His description, though, sounded basically like the model that many OSS projects evolve towards: instead of monolithically specifying the product, you do things in a set of short-term development sprints focused on finishing off selected features. Sounds very much like the operation of all the OSS projects (Linux being a particularly strong example) which do short, deadline-based releases and include whatever features are done.
To me this seems more like a formal version of what many programmers are naturally inclined to do, as opposed to imposing a structure of what they "should" do, as in waterfall for instance. Is this a good thing? I don't know.
'Dr Smith also said that Australia's banks were "being kind" when they bore the costs of cyber crime.'
Reminds me of this (Mitchell and Webb comedy sketch on identity theft): http://www.youtube.com/watch?v=CS9ptA3Ya9E
Key quote from that sketch: 'I'm not clear why you think it's my identity that was stolen, rather than *your* money'
"Russel Smith, one of Australia's principal criminologists, is pushing for first-time computer users to be required to earn a license"
"He said that education was secondary to better technology solutions."
I know, I know, I must be new here... Sounds like Russel Smith is saying maybe it's worth considering in the future, once better technology is in place. Which in my book is different to "pushing" for it. To be fair the original article was a bit sensationalist about this but on this occasion the user's submission to Slashdot appears not to have been - it's the editor commentary that misleads slightly and makes it all sound very melodramatic.
It makes for a "better" story but not better journalism.
Wow, I really must be new here.
Really? Interesting, that hadn't clicked with me. What do you lose, time-travel wise?
I just remembered the problem that time cloning units has the disadvantage of damage propagating - I suppose the appropriate tactic would be to station the "later" unit in the front lines with the "original" providing support. Conversely you'd want to try to figure out (or maybe it tells you) what the original units of your enemy are and kill them.
I don't know if damage propagation is instant or occurs via the time waves.
My understanding is that because the game propagates cause and effect through "meta time" (player time), the game will oscillate between just the factory and just the unit existing. Eventually there's a cut-off point after a certain amount of ... something (meta time, presumably), at which point you end up keeping whichever of them is currently in existence.
Others have posted a link to their explanation.
IIRC the effects of a factory being taken out in the past (and maybe ditto for the resources thing, don't really know) are the following:
When the factory is destroyed in the past, you'll stop being able to build units when working in the past. The units you'd built with the factory *originally* (i.e. earlier in *player time*, not game time) will still exist in the present, they won't just vanish.
The destruction of the factory will propagate as a "time wave", through meta time. Which is to say that the effects of destroying the factory will eventually (from the player's PoV) appear in the present. At that point, yes, your units (and the factory) will probably disappear.
In the meantime you may have gone back in time with those units (!) and saved the factory (!!). According to my understanding, you may then have to wait until *that* change propagates through meta-time to the present. Until this happens you will not have access to that factory or the units it made when playing in the present.
Make sense?
Thanks, forgot that - it's a while since I've looked at the Achron demo videos.
It seems like they've given a decent amount of thought to how to balance the gameplay.