The idea I'm proposing, is that for instance, the latest version of GCC, or any other compiler, released today, can't possibly include code to patch a compiler that doesn't exist yet. And that this new compiler can't patch a program that didn't exist when the compiler was made.
The idea is that Ken Thompson's trick relied on that the compiler already existed, so it was easy to figure out what to patch in it. The login program also existed and the precise place that needed patching was also known. But what if you take those things away?
And yes, I'm aware that gcc compiles itself several times with different versions of itself and compares to attempt to detect the trickery described by Ken Thompson.
Invent your own language and write a compiler for it in-house. Do not explain what it'll be used for. Doesn't matter if it's a crappy version of BASIC. Before getting any developers, choose a development environment and stick to it. A particular version of GCC for instance, and make sure to keep all that well checksummed to be sure there can't be any changes to the environment.
Once the compiler is built, hire programmers to make your vote counting application.
Explanation: It's very unlikely that a compiler you chose before starting development could effectively patch a compiler for a language that didn't exist when it was released. It's also very unlikely that this new compiler could patch an application that isn't written yet.
You say the universe isn't hospitable enough - ok I understand that. But that's a distraction, because even for this universe to be even barely hospital at all an astonishing level of tuning is required to ensure that the universe doesn't implode, atoms don't evaporate, and stars can burn. This is a very serious problem for the Atheistic worldview, but very rarely have I seen Atheists stop and doubt and think on this, and this is my point - Atheists are not per se any less lazy about doubting than Christians are sometimes as GP was claiming.
It's not really a problem.
Again, the same thing. If the universe imploded, you wouldn't be here to ask why it doesn't.
Personally I consider that it's interesting to ask why the speed of light is what it is, but I don't see what it has to do with religion. Perhaps at the core there is some universal rule, from which everything else derives. That'd probably explain a lot of things, except why that rule is there.
I think you're going the wrong way here -- for most atheists your problem isn't a troubling indication of that maybe somebody indeed made the universe, it's an indication of that more research is needed.
In the end though, I don't think religion or a deity is needed in any case. There's stuff in the universe, it interacts in interesting ways, what exists is a consequence of that. There's probably no interesting creation myth, no grand purpose to it, and no reason for its existence. I see no reason why there would have to be a neat explanation to it.
Deep Blue played chess, regardless of the way it did that. Can you look at a chess game and distinguish one played through heuristics from one played through brute force?
Also, how many millions of neurons fire in your brain when you're playing chess? Isn't that brute force of a sort as well?
Actually, typical chess AI is basically the turn-based equivalent of the RTS AI you dislike.
No, it isn't. It's the same playing field, with the same conditions and the same information awareness.
The computer doesn't get to move twice in its turn, to use its bishop as a queen, or to make you start without pawns.
It's purely a competition of who plays chess better, the human or the machine.
Strong chess AI is tactically perfect--it effectively knows everything that can go on within the next N moves. Within that N-move window, you can't fake it out or hope it overlooks some subtle or bizarre line of play--it sees everything within that N-move window perfectly. Meanwhile, the player is limited to being able to think about relatively few lines of play. Any tactical mistake the player makes within that N-move window will be seized upon and exploited to the fullest extent possible.
Sure, but that's to be expected. A grandmaster would play the same way. Somebody like like Kramnik or Kasparov would also mercilessly exploit every mistake you make. And unless you have an experience comparable to that of them, you can bet they can evaluate chess positions in their head a lot better and faster than you can.
You have the answer right at the start of the article.
If the universe wasn't tuned in a way that allowed us to exist, we wouldn't be here to marvel at its well-tunedness.
There's also that life forms adapt to their environment. It's not that the universe is well suited to us, but we're well suited to live in the universe. It's like wondering that the ocean is remarkably well tuned for dolphins. It's isn't, the ocean was there before the dolphins.
A realistic chess AI would be one that consumes no more energy than a human body would, and therefore has to resort to heuristic solutions to make a 'best-guess' with low processing power instead of algorithmically enumerating every possible permutation of the game.
Actually, this is something I don't get.
IMO, it doesn't matter how it thinks, so long it does. A calculator doesn't multiply numbers in the same way I do. That doesn't mean it's somehow a worse or a better way to do it, it's just different. I don't really care if a chess engine does a brute force search, heuristics, or a neural net, the end result is that it plays chess in any case, following the same rules the human does, getting the same amount of time to think.
Making computer chess use heuristics and limiting the energy it can use won't save the human players for very long. A computer will be able to apply more heuristics faster, and we'll eventually come up with a more energy efficient engine -- after all the brain is a general purpose computer, that can't possibly compete with an optimized single purpose one.
The human vs computer chess battle seems to be decided: computers win pretty much all the time now, and imposing restrictions on them only delays the unavoidable.
But you're not going to get a complex game with a cheating AI anyway.
Most RTS AIs are immune to strategy and can only be defeated through brute force. Sneaking from behind? It saw that coming. Attack from multiple fronts? It saw that too. Attacking resource collection? Doesn't work, it gets free resources forever. Turtling and trying to wear out the defense doesn't work either for the same reason.
The standard RTS AI sends periodic small attacks to make things challenging. Meanwhile you try to defend against it while building up your own forces, until you can make a massive attack that destroys or cripples the AI base. It's the same every time, unless you're playing a campaign with scripted objectives. The challenge is building and micromanaging fast enough, pretty much.
While this is a very good idea, it's very difficult to implement well, and it's been tried plenty of times. I've played games that attempted that, but as a result were very easy to beat. For example, you could start an attack on three fronts, and the AI would ignore all but the top two threats, and the third front would just walk all over them. Every single time.
That's just a bad implementation. There's no reason why an AI couldn't ocassionally spend a while to look at its territory. Also, the human player usually has a map, and notifications (like an unit popping up to report "We're under attack!"). It's fair to have the AI have access to that as well.
The fog of war is usually done by a simple radius check. if you are running from something and you are faster, once you get more than 1.5 screens away, you can see on your radar they immediately break off the attack and go regroup.
That's not fog of war, it's just a limit on how far they'll pursue you. And it makes perfect sense too. Otherwise it's trivial to exploit. Take a fast unit, drive it to the enemy base, get a tank or two to pursue you to your base, where they get pummeled by the base defense. Do that a few times, and the enemy is 10 tanks down.
Though I 100% agree that the computer's unlimited ability to micromanage is the one reason I can't stand playing RTS against computers. I can't micromanage anyway, so I still get tooled by real players, but against the computer it's totally futile
The game that came closest to my ideal of what a RTS should be like is Total Annihilation (haven't tried Supreme Commander, so can't compare). The sheer amount of automation you have access to (waypoints, automated production, patrolling aircraft, automatic base repair) and long range defense means that achieving parity with the AI is perfectly possible.
The only problem is that the AI turns out to be too weak. Once you've got a good base going, finding ways to gain advantage is easy. But it seemed to be a step in the right direction.
AIs often win in some games not by the virtue of being smarter, but by having an unfair advantage. Examples:
In RTSes, constant money injections. This pretty much nullifies attempts to attack resource collection -- they don't need it anyway.
Knowledge of the position of everything. In RTSes, they don't need to discover your position. It's useless to try to build an outpost and hide the real base somewhere behind it. In FPSes they know where you are, and can tell when you're sneaking from behind
Instant reaction time and all-encompassing awareness. In RTSes, the AI is capable of controlling every unit at once, and knows what's going on in the whole map at once. Meanwhile, the players are limited in the speed they can give orders, and only has a view of part of the world. Due to this, the AI can't be fooled by multiple attacks from different places, it will see all of them perfectly.
My suggestion: An AI should be coded as a bot, within the constraints given to the player. If the player can only see a part of the battlefield (like in Starcraft) then the AI should have the same limit and need adjust its own viewport to gain awareness of an area. It should also be limited by the fog of war, and lack the ability to see out of the back of its head. To put in another way, a fair Starcraft AI would be one implemented with a camera pointed at the screen, controlling only the keyboard and mouse inputs.
The idea is that I want to be beaten because the AI is indeed smarter, not because it's got a superior access to the battlefield I can never gain.
Chess probably comes closest to the sort of thing I want -- the AI and human are fighting on very equal terms. I don't see the calculating millions of positions a second as a problem, that's simply an implementation detail.
You can have both global warming and local cooling.
For instance, one possible effect is that while the average temperature over the whole planet does rise (global warming), the melting of the ice will shutdown the gulf stream and make some countries like Britain colder.
Can you imagine a hundred panicked people queueing in front of an open door? You'd have the parents screaming about their children and babies, jerks trying to be the first and pushing people out of the way, people standing shaking at the door unable to jump, half the people not understanding what to do with very limited time available, and so on. Then there would be the 3 or 4 who absolutely refuse to jump, what do you do, kick them out of the door?
Also, what about children and really fat people? Can you imagine the mess you'd have if a mother and her 10 year old kid had to jump separately?
Then there's the problem of where can you safely jump. Probably a bad idea over pretty much any populated place, with good chances of landing on a highway, or crashing into a building.
I think it'd be a really horrible mess. This might work for the military, but normal people rarely think straight in such situations, and it'd be a complete chaos.
First, you need to find some pigeons or some other suitable birds. You will also figure out how to make something resembling paper (shouldn't be too difficult with all the wood in the woods), and some means to write (something suitable should be available as well)
Once you managed to train some of them to deliver messages, you send one asking for RFC791 and RFC793, unless you're a networking expert and know them from memory. RFC 792 would be also recommended. You will also need RFC 1149, but that one is short and is best memorized before you get lost in the woods. Optionally, RFC 2549 could provide better service.
The next thing to do is to implement RFC 1149, and use that to talk to a mail server. Anybody with some mail experience should know how to use mail over a telnet session. Just make sure to memorize the IP addresses of a SMTP and a POP3 server (no problem if you run your own server and remember the address). Then just connect and send something like:
HELO thewoods.org MAIL FROM: vadimt@thewoods.org RCPT TO: somebody@gmail.com DATA Subject: I'm the woods
What's up? .
Then to read email:
USER vadimt PASS bears34 LIST RETR 1 QUIT
Latency could be a bit annoying with having to send all those pigeons back and forth, and a good spam filter would be needed server-side if you don't want to spend weeks getting rid of it before you get anything useful, but in a couple of weeks it could be done.
Once this is going, the next step would be starting an open source project to implement IP over smoke signals, or optical telegraph, in case something happens to the pigeons, and to reduce latency. Also implementing DNS would help with talking to the rest of the net.
Once all this is working you can start really improving your tech, by requesting pages from wikipedia on anything you don't know enough about.
It's probably the camera, that's Canon's budget series.
Something newer, like a SX100 IS for instance. Not only it focuses fine, but will also try to detect faces in the image to focus more optimally. And if that's still not satisfying for some reason you can control focus manually. The image stabilization is a huge plus too.
There's one thing I don't get, and it's why does there have to be the SLR part? I pretty much started with digital and prefer the LCD to the viewfinder.
I'd prefer to skip the expense and complexity of the SLR mechanism and just have the rest of the features that come with those cameras. I don't think I even understand the point of a DSLR. I understand the point for a film camera, but for a digital one it seems unnecessarily complex.
What I'm saying is that people fear radiation because it can cause damage that accumulates unnoticeably over a long time, until you suddenly realize you have cancer several months too late.
A type of radiation that is tuned to trigger the pain receptors in the skin would be much safer because you'd notice it much faster and at lower intensities, and the damage would be done to something that quite easily and constantly regenerates.
I got a digital camera when I was going on a trip and didn't really have any experience with one before that.
One thing that struck me is how incredibly better the human eye handles brightness than a not very cheap camera. Out in the sun, for the most part it'd be no problem. But in intense sun, white t-shirts nearly always came out as overexposed, as the sensor reached its limit. The result is a pure white blotch on the image. And inside a building, in normal light, the image often came out all grainy and required a flash to get anything decent.
My priority list for a camera:
1. Good lens, with optical zoom, 10X or so, with image stabilization. This seems the upper range for taking a photo without a tripod. 2. Good sensor: good low light performance, low noise, good color perception 2. Interchangeable lenses 3. Better flash. Why is it that it can't charge up for multiple shots? It's very frustrating when flash is required, I miss the right moment on the first try and have wait for it to charge. If the flash could charge in advance for 2 or 3 uses it'd almost eliminate this problem. 4. Non-crippled video capture. Pretty much every consumer camera on the market can capture video in a decent quality, but with either absolutely terrible sound (something like 11KHz), or stopping after a few minutes.
You can't meaningfully rate CPUs with a single number anyway. Any rating should be understood to be only very approximate.
For instance, a word processor wouldn't care much if you have a 2GHz or a 5GHz CPU, it's fast enough anyway, and the user is unlikely to notice any difference. CPU rating tells you little about performance in this case (you're more likely to run into problems due to low RAM)
For something really CPU intensive like video encoding or rendering, it's not much better. Which CPU is better for video encoding, an Intel 3 GHz one, or an AMD one? What if the video encoder has been updated to use the latest AMD acceleration instructions but not the Intel ones? How will it perform when Intel support is added? What if it's compiled with icc?
IMO, the best way to do this is: Get benchmarks for the specific applications you're interested in, or at least something as close as possible. Then ignore core count, GHz, cache sizes, and memory bandwidth (because the benchmark already accounts for them) and pick the option with the best price/performance ratio.
Incidentally 3mm (100ghz) wavelength is what that "skin on fire" ray uses.
Wouldn't that be actually a good thing from the safety point of view? That would mean it has very bad depth penetration, and if it damages anything, it'll be the most easily replaceable part of the body. It's also one full of nerves, so you're likely to notice that something's wrong soon enough. Something that penetrates deeper could quietly cook the brain instead. While I'd certainly prefer neither, if I have to pick one, I'd certainly go with the former.
The source is there. If the code is shitty, then the right thing to do is to make it not shitty, instead of adding shittiness to another piece of software to work around it.
Also, note: Patch #1: Adds an EXT4 specific ioctl. Meaning the interested application must specifically call this. Obviously no current apps do. Maybe databases and such will use it. Patch #2 and #3: These only apply "if the filesystem is mounted with data=ordered". This is the default setting, but the user or distribution can change it, so the application can't rely on this being true 100% of the time anyway.
As per the documentation, ext4 has 3 modes to choose from with different tradeoffs between performance and reliability. The default is the middle one.
Well, if multiple independent vendors take a spec and implement it in a way that break your assumptions, maybe you should reconsider whether your assumptions were correct.
Hence all the comments about sqlite. If you find dealing with the low level API too complicated, use a simpler abstraction.
Slashdot Mirror
This has nothing to do with GCC.
The idea I'm proposing, is that for instance, the latest version of GCC, or any other compiler, released today, can't possibly include code to patch a compiler that doesn't exist yet. And that this new compiler can't patch a program that didn't exist when the compiler was made.
The idea is that Ken Thompson's trick relied on that the compiler already existed, so it was easy to figure out what to patch in it. The login program also existed and the precise place that needed patching was also known. But what if you take those things away?
And yes, I'm aware that gcc compiles itself several times with different versions of itself and compares to attempt to detect the trickery described by Ken Thompson.
That's of course the most practical solution. But that's not very fun to think about.
Possible solution:
Invent your own language and write a compiler for it in-house. Do not explain what it'll be used for. Doesn't matter if it's a crappy version of BASIC. Before getting any developers, choose a development environment and stick to it. A particular version of GCC for instance, and make sure to keep all that well checksummed to be sure there can't be any changes to the environment.
Once the compiler is built, hire programmers to make your vote counting application.
Explanation: It's very unlikely that a compiler you chose before starting development could effectively patch a compiler for a language that didn't exist when it was released. It's also very unlikely that this new compiler could patch an application that isn't written yet.
It's not really a problem.
Again, the same thing. If the universe imploded, you wouldn't be here to ask why it doesn't.
Personally I consider that it's interesting to ask why the speed of light is what it is, but I don't see what it has to do with religion. Perhaps at the core there is some universal rule, from which everything else derives. That'd probably explain a lot of things, except why that rule is there.
I think you're going the wrong way here -- for most atheists your problem isn't a troubling indication of that maybe somebody indeed made the universe, it's an indication of that more research is needed.
In the end though, I don't think religion or a deity is needed in any case. There's stuff in the universe, it interacts in interesting ways, what exists is a consequence of that. There's probably no interesting creation myth, no grand purpose to it, and no reason for its existence. I see no reason why there would have to be a neat explanation to it.
Why does that matter?
Deep Blue played chess, regardless of the way it did that. Can you look at a chess game and distinguish one played through heuristics from one played through brute force?
Also, how many millions of neurons fire in your brain when you're playing chess? Isn't that brute force of a sort as well?
No, it isn't. It's the same playing field, with the same conditions and the same information awareness.
The computer doesn't get to move twice in its turn, to use its bishop as a queen, or to make you start without pawns.
It's purely a competition of who plays chess better, the human or the machine.
Sure, but that's to be expected. A grandmaster would play the same way. Somebody like like Kramnik or Kasparov would also mercilessly exploit every mistake you make. And unless you have an experience comparable to that of them, you can bet they can evaluate chess positions in their head a lot better and faster than you can.
I don't think there's anything unfair about that.
You have the answer right at the start of the article.
If the universe wasn't tuned in a way that allowed us to exist, we wouldn't be here to marvel at its well-tunedness.
There's also that life forms adapt to their environment. It's not that the universe is well suited to us, but we're well suited to live in the universe. It's like wondering that the ocean is remarkably well tuned for dolphins. It's isn't, the ocean was there before the dolphins.
Actually, this is something I don't get.
IMO, it doesn't matter how it thinks, so long it does. A calculator doesn't multiply numbers in the same way I do. That doesn't mean it's somehow a worse or a better way to do it, it's just different. I don't really care if a chess engine does a brute force search, heuristics, or a neural net, the end result is that it plays chess in any case, following the same rules the human does, getting the same amount of time to think.
Making computer chess use heuristics and limiting the energy it can use won't save the human players for very long. A computer will be able to apply more heuristics faster, and we'll eventually come up with a more energy efficient engine -- after all the brain is a general purpose computer, that can't possibly compete with an optimized single purpose one.
The human vs computer chess battle seems to be decided: computers win pretty much all the time now, and imposing restrictions on them only delays the unavoidable.
But you're not going to get a complex game with a cheating AI anyway.
Most RTS AIs are immune to strategy and can only be defeated through brute force. Sneaking from behind? It saw that coming. Attack from multiple fronts? It saw that too. Attacking resource collection? Doesn't work, it gets free resources forever. Turtling and trying to wear out the defense doesn't work either for the same reason.
The standard RTS AI sends periodic small attacks to make things challenging. Meanwhile you try to defend against it while building up your own forces, until you can make a massive attack that destroys or cripples the AI base. It's the same every time, unless you're playing a campaign with scripted objectives. The challenge is building and micromanaging fast enough, pretty much.
That's just a bad implementation. There's no reason why an AI couldn't ocassionally spend a while to look at its territory. Also, the human player usually has a map, and notifications (like an unit popping up to report "We're under attack!"). It's fair to have the AI have access to that as well.
That's not fog of war, it's just a limit on how far they'll pursue you. And it makes perfect sense too. Otherwise it's trivial to exploit. Take a fast unit, drive it to the enemy base, get a tank or two to pursue you to your base, where they get pummeled by the base defense. Do that a few times, and the enemy is 10 tanks down.
The game that came closest to my ideal of what a RTS should be like is Total Annihilation (haven't tried Supreme Commander, so can't compare). The sheer amount of automation you have access to (waypoints, automated production, patrolling aircraft, automatic base repair) and long range defense means that achieving parity with the AI is perfectly possible.
The only problem is that the AI turns out to be too weak. Once you've got a good base going, finding ways to gain advantage is easy. But it seemed to be a step in the right direction.
A computer that plays on equal terms.
AIs often win in some games not by the virtue of being smarter, but by having an unfair advantage. Examples:
My suggestion: An AI should be coded as a bot, within the constraints given to the player. If the player can only see a part of the battlefield (like in Starcraft) then the AI should have the same limit and need adjust its own viewport to gain awareness of an area. It should also be limited by the fog of war, and lack the ability to see out of the back of its head. To put in another way, a fair Starcraft AI would be one implemented with a camera pointed at the screen, controlling only the keyboard and mouse inputs.
The idea is that I want to be beaten because the AI is indeed smarter, not because it's got a superior access to the battlefield I can never gain.
Chess probably comes closest to the sort of thing I want -- the AI and human are fighting on very equal terms. I don't see the calculating millions of positions a second as a problem, that's simply an implementation detail.
One friend of mine turned his rear window sprinkler around, and would use it on the tailgaters. He said it worked very well.
You can have both global warming and local cooling.
For instance, one possible effect is that while the average temperature over the whole planet does rise (global warming), the melting of the ice will shutdown the gulf stream and make some countries like Britain colder.
I don't think it'd be practical in an airliner.
Can you imagine a hundred panicked people queueing in front of an open door? You'd have the parents screaming about their children and babies, jerks trying to be the first and pushing people out of the way, people standing shaking at the door unable to jump, half the people not understanding what to do with very limited time available, and so on. Then there would be the 3 or 4 who absolutely refuse to jump, what do you do, kick them out of the door?
Also, what about children and really fat people? Can you imagine the mess you'd have if a mother and her 10 year old kid had to jump separately?
Then there's the problem of where can you safely jump. Probably a bad idea over pretty much any populated place, with good chances of landing on a highway, or crashing into a building.
I think it'd be a really horrible mess. This might work for the military, but normal people rarely think straight in such situations, and it'd be a complete chaos.
Oh, that would be doable fairly quickly.
First, you need to find some pigeons or some other suitable birds. You will also figure out how to make something resembling paper (shouldn't be too difficult with all the wood in the woods), and some means to write (something suitable should be available as well)
Once you managed to train some of them to deliver messages, you send one asking for RFC791 and RFC793, unless you're a networking expert and know them from memory. RFC 792 would be also recommended. You will also need RFC 1149, but that one is short and is best memorized before you get lost in the woods. Optionally, RFC 2549 could provide better service.
The next thing to do is to implement RFC 1149, and use that to talk to a mail server. Anybody with some mail experience should know how to use mail over a telnet session. Just make sure to memorize the IP addresses of a SMTP and a POP3 server (no problem if you run your own server and remember the address). Then just connect and send something like:
Then to read email:
Latency could be a bit annoying with having to send all those pigeons back and forth, and a good spam filter would be needed server-side if you don't want to spend weeks getting rid of it before you get anything useful, but in a couple of weeks it could be done.
Once this is going, the next step would be starting an open source project to implement IP over smoke signals, or optical telegraph, in case something happens to the pigeons, and to reduce latency. Also implementing DNS would help with talking to the rest of the net.
Once all this is working you can start really improving your tech, by requesting pages from wikipedia on anything you don't know enough about.
It seems that somebody plugged in your reasoning chip backwards. I recommend readjustment.
It's probably the camera, that's Canon's budget series.
Something newer, like a SX100 IS for instance. Not only it focuses fine, but will also try to detect faces in the image to focus more optimally. And if that's still not satisfying for some reason you can control focus manually. The image stabilization is a huge plus too.
There's one thing I don't get, and it's why does there have to be the SLR part? I pretty much started with digital and prefer the LCD to the viewfinder.
I'd prefer to skip the expense and complexity of the SLR mechanism and just have the rest of the features that come with those cameras. I don't think I even understand the point of a DSLR. I understand the point for a film camera, but for a digital one it seems unnecessarily complex.
I'm not sure if you're getting what I mean.
What I'm saying is that people fear radiation because it can cause damage that accumulates unnoticeably over a long time, until you suddenly realize you have cancer several months too late.
A type of radiation that is tuned to trigger the pain receptors in the skin would be much safer because you'd notice it much faster and at lower intensities, and the damage would be done to something that quite easily and constantly regenerates.
I got a digital camera when I was going on a trip and didn't really have any experience with one before that.
One thing that struck me is how incredibly better the human eye handles brightness than a not very cheap camera. Out in the sun, for the most part it'd be no problem. But in intense sun, white t-shirts nearly always came out as overexposed, as the sensor reached its limit. The result is a pure white blotch on the image. And inside a building, in normal light, the image often came out all grainy and required a flash to get anything decent.
My priority list for a camera:
1. Good lens, with optical zoom, 10X or so, with image stabilization. This seems the upper range for taking a photo without a tripod.
2. Good sensor: good low light performance, low noise, good color perception
2. Interchangeable lenses
3. Better flash. Why is it that it can't charge up for multiple shots? It's very frustrating when flash is required, I miss the right moment on the first try and have wait for it to charge. If the flash could charge in advance for 2 or 3 uses it'd almost eliminate this problem.
4. Non-crippled video capture. Pretty much every consumer camera on the market can capture video in a decent quality, but with either absolutely terrible sound (something like 11KHz), or stopping after a few minutes.
You can't meaningfully rate CPUs with a single number anyway. Any rating should be understood to be only very approximate.
For instance, a word processor wouldn't care much if you have a 2GHz or a 5GHz CPU, it's fast enough anyway, and the user is unlikely to notice any difference. CPU rating tells you little about performance in this case (you're more likely to run into problems due to low RAM)
For something really CPU intensive like video encoding or rendering, it's not much better. Which CPU is better for video encoding, an Intel 3 GHz one, or an AMD one? What if the video encoder has been updated to use the latest AMD acceleration instructions but not the Intel ones? How will it perform when Intel support is added? What if it's compiled with icc?
IMO, the best way to do this is: Get benchmarks for the specific applications you're interested in, or at least something as close as possible. Then ignore core count, GHz, cache sizes, and memory bandwidth (because the benchmark already accounts for them) and pick the option with the best price/performance ratio.
Wouldn't that be actually a good thing from the safety point of view? That would mean it has very bad depth penetration, and if it damages anything, it'll be the most easily replaceable part of the body. It's also one full of nerves, so you're likely to notice that something's wrong soon enough. Something that penetrates deeper could quietly cook the brain instead. While I'd certainly prefer neither, if I have to pick one, I'd certainly go with the former.
The source is there. If the code is shitty, then the right thing to do is to make it not shitty, instead of adding shittiness to another piece of software to work around it.
Also, note:
Patch #1: Adds an EXT4 specific ioctl. Meaning the interested application must specifically call this. Obviously no current apps do. Maybe databases and such will use it.
Patch #2 and #3: These only apply "if the filesystem is mounted with data=ordered". This is the default setting, but the user or distribution can change it, so the application can't rely on this being true 100% of the time anyway.
As per the documentation, ext4 has 3 modes to choose from with different tradeoffs between performance and reliability. The default is the middle one.
See the list
Yes, it tests for markup errors. It also tests for other things, like PNG transparency and CSS paint order and positioning.
Well, if multiple independent vendors take a spec and implement it in a way that break your assumptions, maybe you should reconsider whether your assumptions were correct.
Hence all the comments about sqlite. If you find dealing with the low level API too complicated, use a simpler abstraction.