No he isn't, God is cruel and heartless. If he was "just" no-one would fight wars, he would just smite the "bad" side. Instead he allows people to die by the millions.
Of course 64-bit Windows and Linux can malloc() more than 4GB. Why else compile an application for 64-bit? Even better, unlike LoseThos they can malloc all your free ram as if it was one contiguous block, because they actually support Virtual Memory.
LoseThos seems to trash any and all attempts at process separation made in modern CPUs and OSs. Any process run on the machine can crash the whole system, or even trash the system files, making it unbootable. It's just not practical for a desktop OS. It's ok if you only ever run your own code, but who only runs their own code? To have even posted to slashdot you must be running a modern web browser, which means not your own code.
I think most of us have had driving experiences where we really needed to accellerate *right now* in order to avoid getting run over by a truck or bus or whatever
Most of us don't pull out in front of a truck or bus in the first place.
I think you completely misunderstand. The "IE ActiveX" I am referring to is a version of IE designed for embedding inside other applications, not an addon for IE. The "IE" ActiveX works perfectly happily in a non-MS application, in this case Steam. It even works without "IE" installed. However, when you click a "new window" link, it insists on trying to launch actual IE instead of your default browser, even if you don't have actual IE installed.
I had to install IE again the other day, or else the "Microsoft Update" link in Windows 7 wouldn't do anything. IE isn't actually required to use Microsoft Update once you've installed it, as far as I know. I needed it for a link.
"Microsoft Update" is an upgrade to Windows Update that works on all MS software you have installed, in case you hadn't noticed it. I wanted it to keep Visual Studio up to date.
Also, any applications that use the IE activex (like steam) won't let you open any links outside them (e.g. steam's screenshot gallery) without IE installed.
For now, I suspect I'm going to keep finding little reasons I can't get rid of it, even though I don't use it as my web browser.
Speaking as a PS3 dev, the SPUs are very different to program for than a normal multi-core cpu (and you only get to use five and a half of them anyway, not 7).
On the flip side, everything based on UE3 (which is most big cpu-hungry multi-platform titles these days) is multithreaded to two or three significant threads: Game, rendering, and possibly physics (depending on physics engine used). None of them are SPU threads (though they may use the SPUs for some tasks), so PS3 performance isn't generally as good as the 360's, but in most games it's a non-issue as both platforms go over the 30 fps cap.
On PC, most UE3 games will run best on two cores, with anything above that being unnecessary.
Re:I'd love to see...
on
The Wii Laptop
·
· Score: 3, Informative
This link goes to Ben Heck's version (credit to this post from further down the page). It's considerably smaller and better-built.
Re:Summary Should Include...
on
The Wii Laptop
·
· Score: 1
Yeah, that one (Ben Heck's) is much better than this new one.
Perhaps one testing team which found the bugs in general, and one more experienced team which just tried to isolate bugs and repro steps and fire bugs off to the right developers would work?
It should be published in the language it was written in.
Errors during the translation process to another language could easily invalidate the entire program, which people would assume means flaws in the program output used in the paper. At least if it's published in its original language then any bugs found could genuinely matter.
We have milestones up until release. Each milestone has some requirement of where the game will be at. We have half a dozen two-week "sprints" each milestone. Each sprint tends to include related work, but it's mainly just a handy way to divide up the time. Each sprint has big tasks ("stories" in the speak) in it (estimated in days), divided up between sprints at the start of each milestone and reorganised at each sprint if needed and agreed to. Each "story" is broken up into individual tasks (estimated in hours) at the start of each sprint. Each day, people take tasks to work on and update people on what they have done. If a "story" is done, it's fired off to QA.
Most of that is irrelevant though. The important things are that the people doing the work are the ones saying how long it will take to do, being able to get people to realise that they can't demand three weeks of work in a week, leaving time to fix bugs throughout the project and not just at the end, and still giving a rough idea of when features are ready for use by the level / mission designers.
So far it's working a lot better than the usual system where "production" manage a big work sheet, continuously rearranging things between people to try to get it all to fit and generally ignoring people who bring up things that need doing that aren't in the plan (which is always the case), leaving no time for fixing bugs, resulting in people bypassing the whole system and asking people to do things directly. Everyone always ended up behind on work because if they got ahead production would replan to take it into account, but when you were behind they'd start asking why. It's because the estimate was done by someone a year or two ago, with no idea how long it would really take!
I still expect to work overtime at the end of the project, but so far we've had to do remarkably little to hit our milestones.
If you left for work, would it have really made any difference to you if it took five times as long?
Thought it probably wouldn't, as you could have been hard-disk bound quite easily reading five large files while writing five other large files. The seeking alone would be nasty.
And it's entirely possible. Most pains that came with non-portable code were dealt with years ago, when x86->x64 transition was pushed through.
You make it sound like anyone has bothered to port apps to x64.
Anything which had to be ported, like explorer extensions, antivirus, firewalls etc have been ported, but very little else is x64. Almost everything is still 32-bit x86, with all the traditional non-portable code that entails. For example, the only game I've ever seen with an x64 executable is UT2004.
Very little software is ready to be ported to ARM.
Slashdot Mirror
No he isn't, God is cruel and heartless. If he was "just" no-one would fight wars, he would just smite the "bad" side. Instead he allows people to die by the millions.
Just malloc'd 5GB on my 6GB Windows x64 machine, worked fine.
Here's the program, which I compiled with Visual C++ 2008:
#include "stdio.h"
#include "tchar.h"
#include "malloc.h"
int _tmain(int argc, _TCHAR* argv[]) // in GB
{
__int64 allocsize = 5;
void* pMallocated = malloc(allocsize * 0x40000000);
if (pMallocated)
{
_tprintf(_T("Successfully allocated %I64d GB\n"), allocsize);
}
else
{
_tprintf(_T("Failed to allocate %I64d GB\n"), allocsize);
}
return 0;
}
Of course 64-bit Windows and Linux can malloc() more than 4GB. Why else compile an application for 64-bit? Even better, unlike LoseThos they can malloc all your free ram as if it was one contiguous block, because they actually support Virtual Memory.
LoseThos seems to trash any and all attempts at process separation made in modern CPUs and OSs. Any process run on the machine can crash the whole system, or even trash the system files, making it unbootable. It's just not practical for a desktop OS. It's ok if you only ever run your own code, but who only runs their own code? To have even posted to slashdot you must be running a modern web browser, which means not your own code.
I think most of us have had driving experiences where we really needed to accellerate *right now* in order to avoid getting run over by a truck or bus or whatever
Most of us don't pull out in front of a truck or bus in the first place.
Windows 7 allows you to load storage drivers off of a usb stick before installing.
I think you completely misunderstand. The "IE ActiveX" I am referring to is a version of IE designed for embedding inside other applications, not an addon for IE.
The "IE" ActiveX works perfectly happily in a non-MS application, in this case Steam. It even works without "IE" installed. However, when you click a "new window" link, it insists on trying to launch actual IE instead of your default browser, even if you don't have actual IE installed.
I had to install IE again the other day, or else the "Microsoft Update" link in Windows 7 wouldn't do anything. IE isn't actually required to use Microsoft Update once you've installed it, as far as I know. I needed it for a link.
"Microsoft Update" is an upgrade to Windows Update that works on all MS software you have installed, in case you hadn't noticed it. I wanted it to keep Visual Studio up to date.
Also, any applications that use the IE activex (like steam) won't let you open any links outside them (e.g. steam's screenshot gallery) without IE installed.
For now, I suspect I'm going to keep finding little reasons I can't get rid of it, even though I don't use it as my web browser.
Any half-decent IMAP client should be caching the emails client-side anyway...
And possibly slightly more rigid connections between pieces.
GMod "jelly tanks" ftw!
Or use a temporary table, stick the input into there and then select against it joined to your real data.
Speaking as a PS3 dev, the SPUs are very different to program for than a normal multi-core cpu (and you only get to use five and a half of them anyway, not 7).
On the flip side, everything based on UE3 (which is most big cpu-hungry multi-platform titles these days) is multithreaded to two or three significant threads: Game, rendering, and possibly physics (depending on physics engine used). None of them are SPU threads (though they may use the SPUs for some tasks), so PS3 performance isn't generally as good as the 360's, but in most games it's a non-issue as both platforms go over the 30 fps cap.
On PC, most UE3 games will run best on two cores, with anything above that being unnecessary.
This link goes to Ben Heck's version (credit to this post from further down the page). It's considerably smaller and better-built.
Yeah, that one (Ben Heck's) is much better than this new one.
I'd never even heard of it, so I assumed it was another American thing, like Fry's, CompUSA and Radio Shack.
Then I wikipedia'd it and found out that it's as old as I am.
You may feel old now.
The patch is probably not to the same files as the exploit, but one uses the other.
Incorrect.
"Windows XP x64 is limited to 128 GB of physical memory and 8 terabytes of virtual memory per process"
Perhaps one testing team which found the bugs in general, and one more experienced team which just tried to isolate bugs and repro steps and fire bugs off to the right developers would work?
Does Windows 7 finally report on hard drive SMART status?
No, it doesn't report SMART status messages to the user, but it does keep logs that may be manually looked up.
Actually, Vista onwards pop up a massive message on the screen crying doom for your pc when it notices a sufficiently bad SMART message.
Including 7.
So yes, it does report them to the user.
It should be published in the language it was written in.
Errors during the translation process to another language could easily invalidate the entire program, which people would assume means flaws in the program output used in the paper. At least if it's published in its original language then any bugs found could genuinely matter.
That's how we use it.
We have milestones up until release. Each milestone has some requirement of where the game will be at.
We have half a dozen two-week "sprints" each milestone. Each sprint tends to include related work, but it's mainly just a handy way to divide up the time.
Each sprint has big tasks ("stories" in the speak) in it (estimated in days), divided up between sprints at the start of each milestone and reorganised at each sprint if needed and agreed to.
Each "story" is broken up into individual tasks (estimated in hours) at the start of each sprint.
Each day, people take tasks to work on and update people on what they have done. If a "story" is done, it's fired off to QA.
Most of that is irrelevant though. The important things are that the people doing the work are the ones saying how long it will take to do, being able to get people to realise that they can't demand three weeks of work in a week, leaving time to fix bugs throughout the project and not just at the end, and still giving a rough idea of when features are ready for use by the level / mission designers.
So far it's working a lot better than the usual system where "production" manage a big work sheet, continuously rearranging things between people to try to get it all to fit and generally ignoring people who bring up things that need doing that aren't in the plan (which is always the case), leaving no time for fixing bugs, resulting in people bypassing the whole system and asking people to do things directly. Everyone always ended up behind on work because if they got ahead production would replan to take it into account, but when you were behind they'd start asking why. It's because the estimate was done by someone a year or two ago, with no idea how long it would really take!
I still expect to work overtime at the end of the project, but so far we've had to do remarkably little to hit our milestones.
The Motorola 68000 was/is a 32-bit architecture.
I'm pretty sure it is one die, with communication possible between any cores. It just looks like 2x3 due to the way it is laid out.
1/2-word?
I'm pretty sure that there are instructions for atomic compare and swap of pointer-sized values, at least.
If you left for work, would it have really made any difference to you if it took five times as long?
Thought it probably wouldn't, as you could have been hard-disk bound quite easily reading five large files while writing five other large files. The seeking alone would be nasty.
And it's entirely possible. Most pains that came with non-portable code were dealt with years ago, when x86->x64 transition was pushed through.
You make it sound like anyone has bothered to port apps to x64.
Anything which had to be ported, like explorer extensions, antivirus, firewalls etc have been ported, but very little else is x64. Almost everything is still 32-bit x86, with all the traditional non-portable code that entails.
For example, the only game I've ever seen with an x64 executable is UT2004.
Very little software is ready to be ported to ARM.