I stopped buying PC games when DRM started to become irritating. Steam was the final thing for me - a bloated buggy piece of crap that insisted on downloading 1.4GB on my 1Mb/s connection just so that I could play a game I already owned. Apparently it's fixed some of the major bugs now, but when it was introduced it was shockingly bad.
Over the last year, I've spend more on gog.com that I did on games in the preceding 10 years. I have bought some games and not even played them - they're just sitting waiting for me to have some time to waste. I know that they'll still be working by the time I get around to playing them...
Android users I talk to are pissed - I mean pissed - that Apple supports a three-year old phone with the latest iOs, but Google doesn't give a ahit enough to work with carriers to make that experience more valuable - to the customer
It's nothing to do with the carriers, it's to do with the handset makers. It's also largely the fault of Google for some poor design in Android. With an iPhone, there is no artificial distinction between flash that can be used for the OS and flash that can be used for everything else. If iOS becomes 100MB bigger, it just means 100MB less for the user. If Android becomes 100MB bigger it means a load of phones stop being able to run it. My phone is about two years old, and the latest official release the manufacturer supports is 2.2 (from about when the phone was launched), although they unofficially support 2.3 (from about six months later). CyanogenMod supports a slightly newer 2.3 release.
It looks like I will be able to run a 4.x-based CyanogenMod, but that's totally unsupported by the manufacturer. They could fit 4.0 on it themselves, but they'd need to remove some of their own customisation (HTC Sense, which is quite nice, but not really essential), and they'd have to actually care about long-term support.
Even more fun, you can write nonterminating templates. Compilers typically restrict the stack depth for template evaluations, so this becomes a bit harder. With C++11, constant expressions are also Turing complete, so you have two Turing complete languages that are evaluated at compile time - with this in mind, it's impressive that any C++ project ever finishes compiling...
Current stocks are misleading. Transuranic elements, including plutonium, are so rare that they are considered not to be naturally occurring. Those stocks come from breeder reactors, where neutrons from uranium fission are used to create plutonium, not from mining - there are trace amounts of it around uranium deposits for the same reason, but not enough for anyone to make a plutonium mine. A lot of first generation nuclear reactors were designed primarily to create plutonium, with power generation being a side effect.
Speaking as someone who works on a C++ compiler, that's a comment I'd agree with. If even people implementing the language have to regularly check the spec[1] - and often have long debates over the correct interpretation - then I am not at all surprised that anyone finds it hard. The language seems to be made entirely out of corner cases. In comparison, there are very few places in C or Objective-C where it's not immediately obvious what the correct behaviour is.
[1] I cringe slightly when referring to the official language description as a 'specification'. It is a loose description of how the language works, not a formal description of its semantics.
Which is only a problem if the code needs to run more than once. There's a reason Perl is (was?) popular with system administrators: you can quickly write single-use code in it. It doesn't matter that the code is totally unmaintainable, because most of the time you won't even save it, let alone try to modify it later.
Lots of numbers are thrown around. The difference between a good developer and an average developer is generally thought to be somewhere between 10 and 100 times as productive. The problem is measuring productivity, because the increase in productivity from one good developer is reflected in everyone else who ever has to modify his code and finds it well documented, cleanly layered and easy to change. In contrast, a bad developer can actually have a negative net impact on productivity: I've worked with some devs who have made such poor design decisions that the amount of effort that everyone else had to spend to work around them was more than the effort of someone competent completely redoing their work.
There are lots of tools that do this, for varying levels of success. The problem is, translating C to hardware is not an especially difficult challenge. Translating algorithms that make sense running on a general purpose CPU to algorithms that make sense implemented in hardware is a very hard problem. C is intrinsically serial, hardware is intrinsically parallel (in two dimensions).
The hard problem, and one that's the focus of a lot of research, is analysing C (or whatever) code and determining how to modify the hardware so that the software can run quickly.
If you're going to be pedantic, then remember that mean, median, and mode are all forms of average. In common usage, average usually means mean, but interpreting it as mode or median is also valid.
As the other poster said, CPU speed is very unlikely to be a bottleneck for you. A lot of RAM is a lot more important. You're probably going to want 1GB for each VM instance, so 8GB to be able to run a small handful and still have enough on the host is probably a minimum. 16GB of laptop RAM is still pretty expensive, but if you can afford it then it will mean less time shutting down and starting up VMs.
An SSD may make a difference. It certainly does when compiling C-family languages, because you do a lot of random reads to get all of the headers and then do the write for the output. It's probably less important for things like PHP, although it will make a big difference when suspending and resuming VMs.
The tube drivers in London were recently on strike over pay. Their salaries are around £40k (about $65K), but for a decade or so most of the train control has been completely automated: they're just there to press the emergency stop button if there is something wrong with the automated system (which a human will notice but another automated system won't and, for example, cut power to that segment of track). So, judging by the past, teachers that did nothing but press play on a video machine would be better paid than ones that actually taught...
By the time you get to university, you are expected to be able to teach yourself. The point of going to a university is that teaching yourself is a lot easier when you have easy and regular access to people at the top of your field. If these people are not publishing, then they are probably not at the top of the field anymore...
Speaking as an Englishman living in Wales, I don't want to see independence for Scotland or Wales, I want to see independence for London. Without London, I think the rest of the UK would get along a lot better...
cause of all the muslims i know, none of them in this country (Australia) seem to have an issue with me eating non halal food
For fear of invoking the no true scotsman fallacy, this sounds a lot like saying 'of all of the christians I know, none of them actually go to church or have read the bible'. These people sound like they are people with muslim parents or a muslim upbringing, rather than muslims. Do they pray four times a day? How often do they go to the mosque?
In general, the people who claim to be members of a religion but don't actually observe any of its practices are not the problem. It's the ones that put their religion at the centre of their lives that are...
If you're writing assembly, obviously there are differences, but there are a few things that leak up into the C/C++ abstract machine. These include:
Alignment requirements
Endian
Word size
And, of course, performance. ARM and x86 have more or less the same alignment requirements these days. ARM is slightly more strict, but in the cases where you get it wrong the OS gets an illegal instruction trap and can fix it for you (it's very slow, but if it's not on a hot code path you won't notice). They are both little endian (ARM isn't always, but it normally is these days), and both are LP32.
There are a few more subtle issues, mainly relating to performance. For example, on x86 (but not x86-64), operations on floats and doubles are both calculated at 80-bit precision in the x87 coprocessor and are only truncated to 32 or 64 bits when storing to memory. This means that you may get rounding errors at different places on ARM (or at different optimisation levels on x86), but it also means that calculations on floats and doubles run at the same speed on x86, whereas doubles are typically a lot slower than floats on ARM. On x86-64, these both use the SSE unit, so you will only notice a performance difference if your compiler manages to do some autovectorisation (in theory, you can push twice as many 32-bit operations through SSE as 64-bit ones, but in practice it's rare for compilers to get this unless you're using vector extensions or intrinsics).
In terms of addressing modes, ARM and x86 are actually quite similar. ARM has a single addressing mode, but it also allows you to combine a fixed shift with any arithmetic instruction, so you can do more or less the same with one or two instructions on ARM as you can with any of the complex addressing modes on x86. You don't have segmentation, but no one really uses that on x86 since it isn't present in x86-64.
Porting something like.NET, which needs to generate code at run time, is difficult, but Microsoft has had a.NET VM running on ARM for years for the mobile space, so this isn't new code.
I've not been paying attention to console development for the past few years, but back when I was the people I talked to said that their company maintained its own middleware layer. They wrote games for it and had a separate team optimising the middleware for each platform. A lot of the differentiation (this was back in the XBox / GameCube days) was done in geometry and texture detail: they'd design the data for the most capable console and just reduce the polygon count and texture resolution for the rest.
Modern consoles use Bluetooth controllers - there's nothing stopping you from using them with a computer. There are even drivers for using some of them on open source operating systems. You can drive a projector from a PC. The only problem is the games - there's no technical reason not to support properly implement them in games.
Slashdot Mirror
It's probably quite interesting to watch from the inside too, if you're one of the people who got in early on the pyramid scam.
I stopped buying PC games when DRM started to become irritating. Steam was the final thing for me - a bloated buggy piece of crap that insisted on downloading 1.4GB on my 1Mb/s connection just so that I could play a game I already owned. Apparently it's fixed some of the major bugs now, but when it was introduced it was shockingly bad.
Over the last year, I've spend more on gog.com that I did on games in the preceding 10 years. I have bought some games and not even played them - they're just sitting waiting for me to have some time to waste. I know that they'll still be working by the time I get around to playing them...
Android users I talk to are pissed - I mean pissed - that Apple supports a three-year old phone with the latest iOs, but Google doesn't give a ahit enough to work with carriers to make that experience more valuable - to the customer
It's nothing to do with the carriers, it's to do with the handset makers. It's also largely the fault of Google for some poor design in Android. With an iPhone, there is no artificial distinction between flash that can be used for the OS and flash that can be used for everything else. If iOS becomes 100MB bigger, it just means 100MB less for the user. If Android becomes 100MB bigger it means a load of phones stop being able to run it. My phone is about two years old, and the latest official release the manufacturer supports is 2.2 (from about when the phone was launched), although they unofficially support 2.3 (from about six months later). CyanogenMod supports a slightly newer 2.3 release.
It looks like I will be able to run a 4.x-based CyanogenMod, but that's totally unsupported by the manufacturer. They could fit 4.0 on it themselves, but they'd need to remove some of their own customisation (HTC Sense, which is quite nice, but not really essential), and they'd have to actually care about long-term support.
Even more fun, you can write nonterminating templates. Compilers typically restrict the stack depth for template evaluations, so this becomes a bit harder. With C++11, constant expressions are also Turing complete, so you have two Turing complete languages that are evaluated at compile time - with this in mind, it's impressive that any C++ project ever finishes compiling...
Current stocks are misleading. Transuranic elements, including plutonium, are so rare that they are considered not to be naturally occurring. Those stocks come from breeder reactors, where neutrons from uranium fission are used to create plutonium, not from mining - there are trace amounts of it around uranium deposits for the same reason, but not enough for anyone to make a plutonium mine. A lot of first generation nuclear reactors were designed primarily to create plutonium, with power generation being a side effect.
[1] I cringe slightly when referring to the official language description as a 'specification'. It is a loose description of how the language works, not a formal description of its semantics.
Which is only a problem if the code needs to run more than once. There's a reason Perl is (was?) popular with system administrators: you can quickly write single-use code in it. It doesn't matter that the code is totally unmaintainable, because most of the time you won't even save it, let alone try to modify it later.
You may be confusing Prolog and Logo. Logo is an imperative language...
Lots of numbers are thrown around. The difference between a good developer and an average developer is generally thought to be somewhere between 10 and 100 times as productive. The problem is measuring productivity, because the increase in productivity from one good developer is reflected in everyone else who ever has to modify his code and finds it well documented, cleanly layered and easy to change. In contrast, a bad developer can actually have a negative net impact on productivity: I've worked with some devs who have made such poor design decisions that the amount of effort that everyone else had to spend to work around them was more than the effort of someone competent completely redoing their work.
There are lots of tools that do this, for varying levels of success. The problem is, translating C to hardware is not an especially difficult challenge. Translating algorithms that make sense running on a general purpose CPU to algorithms that make sense implemented in hardware is a very hard problem. C is intrinsically serial, hardware is intrinsically parallel (in two dimensions).
The hard problem, and one that's the focus of a lot of research, is analysing C (or whatever) code and determining how to modify the hardware so that the software can run quickly.
If you're going to be pedantic, then remember that mean, median, and mode are all forms of average. In common usage, average usually means mean, but interpreting it as mode or median is also valid.
As the other poster said, CPU speed is very unlikely to be a bottleneck for you. A lot of RAM is a lot more important. You're probably going to want 1GB for each VM instance, so 8GB to be able to run a small handful and still have enough on the host is probably a minimum. 16GB of laptop RAM is still pretty expensive, but if you can afford it then it will mean less time shutting down and starting up VMs.
An SSD may make a difference. It certainly does when compiling C-family languages, because you do a lot of random reads to get all of the headers and then do the write for the output. It's probably less important for things like PHP, although it will make a big difference when suspending and resuming VMs.
(I'm not compiling C++ or even Java most of the time.)
Telling us what you are doing is probably more likely to encourage helpful suggestions than telling us what you aren't doing...
The tube drivers in London were recently on strike over pay. Their salaries are around £40k (about $65K), but for a decade or so most of the train control has been completely automated: they're just there to press the emergency stop button if there is something wrong with the automated system (which a human will notice but another automated system won't and, for example, cut power to that segment of track). So, judging by the past, teachers that did nothing but press play on a video machine would be better paid than ones that actually taught...
By the time you get to university, you are expected to be able to teach yourself. The point of going to a university is that teaching yourself is a lot easier when you have easy and regular access to people at the top of your field. If these people are not publishing, then they are probably not at the top of the field anymore...
Speaking as an Englishman living in Wales, I don't want to see independence for Scotland or Wales, I want to see independence for London. Without London, I think the rest of the UK would get along a lot better...
cause of all the muslims i know, none of them in this country (Australia) seem to have an issue with me eating non halal food
For fear of invoking the no true scotsman fallacy, this sounds a lot like saying 'of all of the christians I know, none of them actually go to church or have read the bible'. These people sound like they are people with muslim parents or a muslim upbringing, rather than muslims. Do they pray four times a day? How often do they go to the mosque?
In general, the people who claim to be members of a religion but don't actually observe any of its practices are not the problem. It's the ones that put their religion at the centre of their lives that are...
And, of course, performance. ARM and x86 have more or less the same alignment requirements these days. ARM is slightly more strict, but in the cases where you get it wrong the OS gets an illegal instruction trap and can fix it for you (it's very slow, but if it's not on a hot code path you won't notice). They are both little endian (ARM isn't always, but it normally is these days), and both are LP32.
There are a few more subtle issues, mainly relating to performance. For example, on x86 (but not x86-64), operations on floats and doubles are both calculated at 80-bit precision in the x87 coprocessor and are only truncated to 32 or 64 bits when storing to memory. This means that you may get rounding errors at different places on ARM (or at different optimisation levels on x86), but it also means that calculations on floats and doubles run at the same speed on x86, whereas doubles are typically a lot slower than floats on ARM. On x86-64, these both use the SSE unit, so you will only notice a performance difference if your compiler manages to do some autovectorisation (in theory, you can push twice as many 32-bit operations through SSE as 64-bit ones, but in practice it's rare for compilers to get this unless you're using vector extensions or intrinsics).
In terms of addressing modes, ARM and x86 are actually quite similar. ARM has a single addressing mode, but it also allows you to combine a fixed shift with any arithmetic instruction, so you can do more or less the same with one or two instructions on ARM as you can with any of the complex addressing modes on x86. You don't have segmentation, but no one really uses that on x86 since it isn't present in x86-64.
Porting something like .NET, which needs to generate code at run time, is difficult, but Microsoft has had a .NET VM running on ARM for years for the mobile space, so this isn't new code.
You can keep an eye on the status here. Oh, and you're meant to say 'I and both other BSD users...'
And who were they voted out in favour of? How many of them lost their seats to a third party or to independents.
Does this mean I can sell my Slashdot account to shill companies for a lot of money?
Sorry, the missing verb was 'saw'.
I've not been paying attention to console development for the past few years, but back when I was the people I talked to said that their company maintained its own middleware layer. They wrote games for it and had a separate team optimising the middleware for each platform. A lot of the differentiation (this was back in the XBox / GameCube days) was done in geometry and texture detail: they'd design the data for the most capable console and just reduce the polygon count and texture resolution for the rest.
Modern consoles use Bluetooth controllers - there's nothing stopping you from using them with a computer. There are even drivers for using some of them on open source operating systems. You can drive a projector from a PC. The only problem is the games - there's no technical reason not to support properly implement them in games.
So when I give someone an OpenOffice document, and they say 'I can't open it', and I say 'Oh, here, have a copy of the application' I'm not a user?