It's too bad everyone and their dog are excited about Ruby on Rails, when a great platform like Django is out there as well.
Even in the Ruby world, it's too bad Rails gets most of the attention; a lot of people would probably be better off with one of the many more lightweight frameworks there, or even no framework at all (really, your 3 page website needs an 80kLOC framework to support it?). So many people hyperfocus on one system and miss out on all the other ways of doing things; Nitro, Merb, Sanatra, Ramaze, even writing your own handlers in Rack. Given the size, complexity and overhead of these things, it'd really make more sense for people to start from the bottom (Rack) and work their way up, not the other way around.
Python wise this probably means starting by writing your own WSGI handlers, rather than starting with a huge framework to write Hello World in.
on the whole Python indentation=block thing... It's not perfect, but only use spaces and it won't be a problem.
Blegh, use tabs properly and it won't be a problem either. It's shocking how people can't even get a trivial thing like that right, though, is it really that difficult to configure your editor not to mix the two? Hint: Set your editor to highlight leading whitespace, doing tabs and spaces differently, then you'll never be surprised by either. I'll get you started:
highlight LeadingTab ctermbg=blue guibg=blue highlight LeadingSpace ctermbg=darkgreen guibg=darkgreen highlight EvilSpace ctermbg=darkred guibg=darkred au Syntax * syn match LeadingTab/^\t\+/ au Syntax * syn match LeadingSpace/^\ \+/ au Syntax * syn match EvilSpace/[^\t]\+\zs\t\+/ " tabs not preceeded by tabs are never acceptable au Syntax * syn match EvilSpace/\zs\ \+$/ " trailing space is silly
There, now you have no excuse. Well, except the first EvilSpace match broke at some point, anyone see why?
Feel free to check the source code or gather memory usage statistics by examining the memory mappings with some other tool.
Re:Chrome iPhone
on
Chrome Vs. IE 8
·
· Score: 4, Informative
IE8 with 6 processes was using 958524 KB and Chrome with 11 processes was using 783840 KB.
Uhm, how are you counting that? There are 11 Chome.exe processes, and when you add their "Mem Usage" columns up you get 783840KB? Because, er, OS's which use paged memory VM's don't work like that; about the only way you can really work out how much memory they're all using is by comparing their VM mappings and seeing what bits are shared between them (and not also with other processes; e.g. standard Win32 dll's everyone uses) and which aren't.
This is why Chrome has about:memory, with an *estimate* of how much memory Chrome is using; if I spawn 11 tabs and add up Mem Use, I get 263MB. about:memory, however, estimates it's using 166MB, and a good chunk of that may well be in memory mapped files and as easily disposable as filesystem cache.
Now, I wonder why they didn't make Chrome multithreaded instead of multiprocess. Threads can share memory within a process, meaning there's far less overhead from both a scheduling standpoint and a memory standpoint
Processes share memory too; pages are marked copy on write when you clone a process, so the only additional memory used is that which changes with respect to the parent process. This isn't represented very well to the user by most OS's, though; shared memory often appears just like any other in top/ps/Task Manager/etc, so it can appear as though it's more expensive than it really is; fork a 2GB process, you'll get two processes with a RES of 2GB, but global system memory use will barely twitch.
The upshot of this is, once a child process dies, the parent doesn't have any of the junk left over from it in its address space, which helps reduce fragmentation and makes memory leaks and even memory corruption bugs less annoying. It's also easy to modify the permissions of a parent process; you can use OpenSSH-style privsep using child processes to help limit the impact of vulnerabilities without running the entire browser in a form that can't really do anything; not so with threads.
Processes also greatly simplify programming; you're only sharing state where you explicitly request it (e.g. using inter-process message passing), rather than having it implicit and having to worry about endless locking and reentrancy issues, not only in your code, but in any code you link to.
Direct download from EA is £39.95, or £42.94 if you want to be able to redownload for 2 years instead of 6 months. 95.95 AUD is £45, so not that much of a markup.
Of course, if I buy a physical copy, I can get it for £28, or £30 if I want it (almost) guaranteed on release day, so you do have to wonder what EA are thinking with that download price..
It's certainly worth getting past the simple graphics (a good tileset helps) and somewhat wobbly controls. You'll soon go from not being able to work out how to dig to building automated goblin crushers and appreciating the detailed gibbage and realistic blood effects.
GPG has already made an absolute mockery of rights #2, 3, 4 and 5.
"2) Gamers shall have the right to demand that games be released in a finished state."
Well, SupCom and FA had bugs, and balance issues, and stuff.. but so does everything. I can't say the problems seemed severe enough to me to consider them "unfinished".
"3) Gamers shall have the right to expect meaningful updates after a games release."
Which GPG provided; frequent patches, new units, improved balance, new features, rapid DRM removal, improved performance. They made a mockery of this? WTF do you expect, extra 10 hour single-player campaigns every month?
"4) Gamers shall have the right to demand that download managers and updaters not force themselves to run or be forced to load in order to play a game"
Yes, GPGNet is rubbish, but you can download patches yourself if you want to, and you don't need to run or even install GPGnet to run SupCom. Unless it's required for online play? That's something I never bothered with.
"5) Gamers shall have the right to expect that the minimum requirements for a game will mean that the game will play adequately on that computer."
Depends what you mean by "adequate"; some SupCom maps (i.e. the biggest it supports) leave me playing at something like 1/4th real time on a 2.6GHz dual core Opteron, but I think it's reasonable that a game like it scale up to levels that are painful for even very high end systems.
Everybody spends and spends and builds mammoth PCs to get the highest FPS... 90-95% of the PCs in homes aren't even SLI capable
I suggest you look up the meaning of "everybody", as you seem to be confusing it with something else.
IT ISN'T WORTH IT
Not for most people, no, but for game developers, people with huge monitors, and people with enough money to make the extra cost irrelevent, the tradeoff might be different.
Of course, Extreme Edition/Ultra/etc are probably silly even for them; pay 70% more to get an extra 10% performance? At least SLI can nearly double performance.
Crysis.. no one actually *plays* it as a game, it is just a benchmark and eye candy demo
Um, I'm pretty sure I played it as a game; it's a fun FPS, at least for the first 2/3rds.
Also I've been looking at a cheap DVD Autoload backup option. Any ideas there from the Slashdot crowd?
Backup 200GB+ of data to DVD's? Are you mad? That's 25-50 disks just for the initial backup, and you probably want twice that to handle discs going bad.
Get two or three external disks (ESATA ideally; you can run SMART self tests, get better transfer rates, etc). Use a decent incremental backup tool to make versioned snapshots to them, rotating the drives periodically; keep one in storage, and ideally one off-site. Faster, less hassle, more robust and more flexible than a pile-o-DVDs.
It doesn't matter how deep or absorbing the game can be.
Saying that, you are perhaps not the target audience of DF;)
I'll note that DF is also alpha software, and has a planned development arc of more than "a year or four", and that does include a lot of interface improvements.
If the controls suck and it gives a bad first impression by not at the very least trying to marginally stay up to date with the looks, it's going to turn more people away than it would draw in.
Maybe, but then, plenty of games do those things and bomb. UT3 looks pretty damn good, it's got easy to pick up controls, etc.. yet, it's sold all of about 30,000 units, and I can't say I've ever seen anyone raving about how good it is. DF, with its ANSI tiles and dubious controls has developed far more of a following (if not in numbers then in devotion), and frankly has a lot more chance of still being around in half a decade than, well, most other games, frankly.
And yes, perhaps a game which doesn't focus on looks that much will turn away lots of people, but not every developer is looking to take the world by storm; maybe they just want to make a game they want to play, and it just happens to have a market that can support it. Again, DF is free, but they make enough off donations to live off, so they must be doing something right.
Maybe you're more on the mark with other games in the list, though frankly having played some of them, I somewhat doubt it; Mount & Blade isn't exactly suffering by lacking bump mapped phong shaded self shadowed blooming effects, but would certainly benefit from deeper backstory and gameplay, Democracy 2 isn't going to benefit from being 3D but would from having a more detailed simulation. If you think there aren't any good games on the list because they lack the graphical effects to which you have become acustomed, I can't help but feel you're maybe missing something.
Dwarf Fortress's website looks like it came straight out of 1990. The game looks like something out of the 70's. The controls are confusing and inconsistent, and you get very little guidance from the game itself.
Sword of the Stars is pretty good too; it's kind of a cross between Gal Civ 2 and Sins, with turn based strategic gameplay and real-time controllable battles. It's developed by ex Barking Dog Studios peeps, just like Sins:)
Semi-randomized tech-trees based on a race's strengths. Just because you've researched Lasers doesn't mean you're going to get Phasers, and research can end early or hit time/cost overruns. Adds extra layers of risk to research.
Radically different propulsion methods for each race. e.g. Humans have very rapid travel along specific "Node lines", but can't stop or turn around mid-way if they detect overwhelming odds on the other side. Hivers have no faster-than-light travel, and take ages to get anywhere, but if they arrive intact they can deploy hypergates to provide instant travel between other gates.
Customizable ships, but not quite to the overwhelming degree of GalCiv 2.
Does it really need to be patched in? On FreeBSD, kernel modules are often (well.. occasionally) distributed as ports which build a kernel module; no kernel patching, recompiles or reboots necessary. This is how FUSE is distributed, for example. Having a stable kernel API/ABI probably helps, but I'm quite sure I've built standalone Linux kernel modules before too.
Please drop the whole "scripted storyline" concept and make a super fancy algorithm so that the story derives from whatever the player does and whatever happens as a consequence
PHP isn't really usable under worker, unless you're happy to limit to a very small number of extensions; most aren't thread safe, and good luck finding documentation on which ones are. It's not even that simple to test. Similarly, mod_python might work threaded, but libraries you might want to use with it might not be (they would normally be protected by the GIL, but if you've got multiple serperate interpreter instances in a process, that won't save them).
Pfft, I can't stand the whole mod_$language thing. It ties you to Apache, it ties you to a substandard Apache MPM, it adds another interdependency between your webserver and your actual application and makes seperating them harder.
I far prefer application servers, with the webserver left to serve/proxy HTTP and related protocols rather than running your entire application. I'd like to see better support for this with PHP; i.e. a HTTP SAPI that runs a simple webserver, rather like its daemonized FastCGI support. Then all you need to interface with a webserver is mod_proxy, which most provide by default.
This, incidently, tends to be the preferred means of interfacing with webservers for most other languages; Ruby has FastCGI, Mongrel, Thin, Ebb, etc, Python has Paster, CherryPy, Aspen, WSGI, etc, Java has Glassfish and friends, Erlang has Yaws. This lets your applications run effeciently under other credentials, even seperate (virtual or physical) machines, and in a process environment which suits them.
So, does that mean they could somehow be used with entangled photons or whatever to transmit information faster than light?
No, since you need to encode something in the channels, and you can't entangle a photon, send it off to the receiver and then change your photon's quantum state at a later date to encode anything in a way which gets information to the other party; the best you can do is measure them and go "woa, they're highly correlated!".
The paper talks about two types of capacity a quantum channel can provide; "private capacity", which is our common or garden secure crypto channel, and "assisted capacity", whereby you exploit a quantum channel with said correlations between your input and the receiver's output (even if you can't control said correlations) to reduce the noise floor of the channels; the encoder knows the input to the assisted channel, and can talk about it on the private one, thus making a potentially useful link, even if both links individually would otherwise be useless.
IANAQP, I just skimmed the paper and maybe vaguely understood some of the less squiggly bits.
Slashdot Mirror
It's too bad everyone and their dog are excited about Ruby on Rails, when a great platform like Django is out there as well.
Even in the Ruby world, it's too bad Rails gets most of the attention; a lot of people would probably be better off with one of the many more lightweight frameworks there, or even no framework at all (really, your 3 page website needs an 80kLOC framework to support it?). So many people hyperfocus on one system and miss out on all the other ways of doing things; Nitro, Merb, Sanatra, Ramaze, even writing your own handlers in Rack. Given the size, complexity and overhead of these things, it'd really make more sense for people to start from the bottom (Rack) and work their way up, not the other way around.
Python wise this probably means starting by writing your own WSGI handlers, rather than starting with a huge framework to write Hello World in.
on the whole Python indentation=block thing... It's not perfect, but only use spaces and it won't be a problem.
Blegh, use tabs properly and it won't be a problem either. It's shocking how people can't even get a trivial thing like that right, though, is it really that difficult to configure your editor not to mix the two? Hint: Set your editor to highlight leading whitespace, doing tabs and spaces differently, then you'll never be surprised by either. I'll get you started:
There, now you have no excuse. Well, except the first EvilSpace match broke at some point, anyone see why?
Feel free to check the source code or gather memory usage statistics by examining the memory mappings with some other tool.
IE8 with 6 processes was using 958524 KB and Chrome with 11 processes was using 783840 KB.
Uhm, how are you counting that? There are 11 Chome.exe processes, and when you add their "Mem Usage" columns up you get 783840KB? Because, er, OS's which use paged memory VM's don't work like that; about the only way you can really work out how much memory they're all using is by comparing their VM mappings and seeing what bits are shared between them (and not also with other processes; e.g. standard Win32 dll's everyone uses) and which aren't.
This is why Chrome has about:memory, with an *estimate* of how much memory Chrome is using; if I spawn 11 tabs and add up Mem Use, I get 263MB. about:memory, however, estimates it's using 166MB, and a good chunk of that may well be in memory mapped files and as easily disposable as filesystem cache.
Now, I wonder why they didn't make Chrome multithreaded instead of multiprocess. Threads can share memory within a process, meaning there's far less overhead from both a scheduling standpoint and a memory standpoint
Processes share memory too; pages are marked copy on write when you clone a process, so the only additional memory used is that which changes with respect to the parent process. This isn't represented very well to the user by most OS's, though; shared memory often appears just like any other in top/ps/Task Manager/etc, so it can appear as though it's more expensive than it really is; fork a 2GB process, you'll get two processes with a RES of 2GB, but global system memory use will barely twitch.
The upshot of this is, once a child process dies, the parent doesn't have any of the junk left over from it in its address space, which helps reduce fragmentation and makes memory leaks and even memory corruption bugs less annoying. It's also easy to modify the permissions of a parent process; you can use OpenSSH-style privsep using child processes to help limit the impact of vulnerabilities without running the entire browser in a form that can't really do anything; not so with threads.
Processes also greatly simplify programming; you're only sharing state where you explicitly request it (e.g. using inter-process message passing), rather than having it implicit and having to worry about endless locking and reentrancy issues, not only in your code, but in any code you link to.
39.95 GBP = 70.9170 USD
£29.99, "Despatched in time for delivery on release day".
Direct download from EA is £39.95, or £42.94 if you want to be able to redownload for 2 years instead of 6 months. 95.95 AUD is £45, so not that much of a markup.
Of course, if I buy a physical copy, I can get it for £28, or £30 if I want it (almost) guaranteed on release day, so you do have to wonder what EA are thinking with that download price..
It's certainly worth getting past the simple graphics (a good tileset helps) and somewhat wobbly controls. You'll soon go from not being able to work out how to dig to building automated goblin crushers and appreciating the detailed gibbage and realistic blood effects.
It's ok, Losing is fun.
GPG has already made an absolute mockery of rights #2, 3, 4 and 5.
"2) Gamers shall have the right to demand that games be released in a finished state."
Well, SupCom and FA had bugs, and balance issues, and stuff.. but so does everything. I can't say the problems seemed severe enough to me to consider them "unfinished".
"3) Gamers shall have the right to expect meaningful updates after a games release."
Which GPG provided; frequent patches, new units, improved balance, new features, rapid DRM removal, improved performance. They made a mockery of this? WTF do you expect, extra 10 hour single-player campaigns every month?
"4) Gamers shall have the right to demand that download managers and updaters not force themselves to run or be forced to load in order to play a game"
Yes, GPGNet is rubbish, but you can download patches yourself if you want to, and you don't need to run or even install GPGnet to run SupCom. Unless it's required for online play? That's something I never bothered with.
"5) Gamers shall have the right to expect that the minimum requirements for a game will mean that the game will play adequately on that computer."
Depends what you mean by "adequate"; some SupCom maps (i.e. the biggest it supports) leave me playing at something like 1/4th real time on a 2.6GHz dual core Opteron, but I think it's reasonable that a game like it scale up to levels that are painful for even very high end systems.
Elaborate.
Everybody spends and spends and builds mammoth PCs to get the highest FPS ... 90-95% of the PCs in homes aren't even SLI capable
I suggest you look up the meaning of "everybody", as you seem to be confusing it with something else.
IT ISN'T WORTH IT
Not for most people, no, but for game developers, people with huge monitors, and people with enough money to make the extra cost irrelevent, the tradeoff might be different.
Of course, Extreme Edition/Ultra/etc are probably silly even for them; pay 70% more to get an extra 10% performance? At least SLI can nearly double performance.
Crysis .. no one actually *plays* it as a game, it is just a benchmark and eye candy demo
Um, I'm pretty sure I played it as a game; it's a fun FPS, at least for the first 2/3rds.
Please do explain how data INTEGRETY is affected by the way you define indexes
You don't think a database might lose some degree of integrity by lacking primary, foreign and unique key indexes?
Also I've been looking at a cheap DVD Autoload backup option. Any ideas there from the Slashdot crowd?
Backup 200GB+ of data to DVD's? Are you mad? That's 25-50 disks just for the initial backup, and you probably want twice that to handle discs going bad.
Get two or three external disks (ESATA ideally; you can run SMART self tests, get better transfer rates, etc). Use a decent incremental backup tool to make versioned snapshots to them, rotating the drives periodically; keep one in storage, and ideally one off-site. Faster, less hassle, more robust and more flexible than a pile-o-DVDs.
Both Intel and nVidia - proprietary driver companies - should be on defensive right now.
Eh? Intel, the company with open source accelerated graphics drivers available right now in X.org?
It doesn't matter how deep or absorbing the game can be.
Saying that, you are perhaps not the target audience of DF ;)
I'll note that DF is also alpha software, and has a planned development arc of more than "a year or four", and that does include a lot of interface improvements.
If the controls suck and it gives a bad first impression by not at the very least trying to marginally stay up to date with the looks, it's going to turn more people away than it would draw in.
Maybe, but then, plenty of games do those things and bomb. UT3 looks pretty damn good, it's got easy to pick up controls, etc.. yet, it's sold all of about 30,000 units, and I can't say I've ever seen anyone raving about how good it is. DF, with its ANSI tiles and dubious controls has developed far more of a following (if not in numbers then in devotion), and frankly has a lot more chance of still being around in half a decade than, well, most other games, frankly.
And yes, perhaps a game which doesn't focus on looks that much will turn away lots of people, but not every developer is looking to take the world by storm; maybe they just want to make a game they want to play, and it just happens to have a market that can support it. Again, DF is free, but they make enough off donations to live off, so they must be doing something right.
Maybe you're more on the mark with other games in the list, though frankly having played some of them, I somewhat doubt it; Mount & Blade isn't exactly suffering by lacking bump mapped phong shaded self shadowed blooming effects, but would certainly benefit from deeper backstory and gameplay, Democracy 2 isn't going to benefit from being 3D but would from having a more detailed simulation. If you think there aren't any good games on the list because they lack the graphical effects to which you have become acustomed, I can't help but feel you're maybe missing something.
Dwarf Fortress's website looks like it came straight out of 1990. The game looks like something out of the 70's. The controls are confusing and inconsistent, and you get very little guidance from the game itself.
That doesn't stop it being incredibly deep, absorbing and rewarding; Looks aren't everything.
Sword of the Stars is pretty good too; it's kind of a cross between Gal Civ 2 and Sins, with turn based strategic gameplay and real-time controllable battles. It's developed by ex Barking Dog Studios peeps, just like Sins :)
Highlights:
No DRM that I've noticed, at least over Impulse.
Semi-randomized tech-trees based on a race's strengths. Just because you've researched Lasers doesn't mean you're going to get Phasers, and research can end early or hit time/cost overruns. Adds extra layers of risk to research.
Radically different propulsion methods for each race. e.g. Humans have very rapid travel along specific "Node lines", but can't stop or turn around mid-way if they detect overwhelming odds on the other side. Hivers have no faster-than-light travel, and take ages to get anywhere, but if they arrive intact they can deploy hypergates to provide instant travel between other gates.
Customizable ships, but not quite to the overwhelming degree of GalCiv 2.
Does it really need to be patched in? On FreeBSD, kernel modules are often (well.. occasionally) distributed as ports which build a kernel module; no kernel patching, recompiles or reboots necessary. This is how FUSE is distributed, for example. Having a stable kernel API/ABI probably helps, but I'm quite sure I've built standalone Linux kernel modules before too.
Please drop the whole "scripted storyline" concept and make a super fancy algorithm so that the story derives from whatever the player does and whatever happens as a consequence
Here you go. Some assembly required. Dwarf Fortress is in many respects built to allow stories to emerge from gameplay; indeed, it's a significant part of what people find attractive about it.
It's kind of a mixture of Dungeon Keeper 2, Sim City, Nethack, The Sims, The Incredible Machine, and experimental brain surgery.
I'm pretty sure SSL doesn't have one of those.
PHP isn't really usable under worker, unless you're happy to limit to a very small number of extensions; most aren't thread safe, and good luck finding documentation on which ones are. It's not even that simple to test. Similarly, mod_python might work threaded, but libraries you might want to use with it might not be (they would normally be protected by the GIL, but if you've got multiple serperate interpreter instances in a process, that won't save them).
Pfft, I can't stand the whole mod_$language thing. It ties you to Apache, it ties you to a substandard Apache MPM, it adds another interdependency between your webserver and your actual application and makes seperating them harder.
I far prefer application servers, with the webserver left to serve/proxy HTTP and related protocols rather than running your entire application. I'd like to see better support for this with PHP; i.e. a HTTP SAPI that runs a simple webserver, rather like its daemonized FastCGI support. Then all you need to interface with a webserver is mod_proxy, which most provide by default.
This, incidently, tends to be the preferred means of interfacing with webservers for most other languages; Ruby has FastCGI, Mongrel, Thin, Ebb, etc, Python has Paster, CherryPy, Aspen, WSGI, etc, Java has Glassfish and friends, Erlang has Yaws. This lets your applications run effeciently under other credentials, even seperate (virtual or physical) machines, and in a process environment which suits them.
I don't really want to switch over to Ruby / Python, largely for performance reasons
Why, do you need your language to be slower than Python but not slower than PHP?
There is virtually 0 market for post-sale support.
The success of services like Steam and Impulse suggest otherwise.
So, does that mean they could somehow be used with entangled photons or whatever to transmit information faster than light?
No, since you need to encode something in the channels, and you can't entangle a photon, send it off to the receiver and then change your photon's quantum state at a later date to encode anything in a way which gets information to the other party; the best you can do is measure them and go "woa, they're highly correlated!".
The paper talks about two types of capacity a quantum channel can provide; "private capacity", which is our common or garden secure crypto channel, and "assisted capacity", whereby you exploit a quantum channel with said correlations between your input and the receiver's output (even if you can't control said correlations) to reduce the noise floor of the channels; the encoder knows the input to the assisted channel, and can talk about it on the private one, thus making a potentially useful link, even if both links individually would otherwise be useless.
IANAQP, I just skimmed the paper and maybe vaguely understood some of the less squiggly bits.