Speaking for myself, China is so far much smaller than I expected for our tech product, and smaller in proportion than any other market. We speculate about why: perhaps the attitude in China is, why wouldn't we do it ourselves?
That's a good point, and seems increasingly likely by now. Still, when trying to evaluate solutions, it doesn't help to have a list that blanket excludes everything. If the problem gets bad enough, some of those things it excludes will turn out to be tolerable (for example, anonymous mailing).
That form is amusing and enlightening for first-time proposals at solving spam. But as far as I can tell, it also rules out all solutions because it assumes there is a solution that doesn't have any cost or compromise.
The likely reality is that someone will have to pay or be inconvenienced to solve spam.
Indeed. While hard drive space is 100-1000 times what it used to be, the speed is only about double or triple. So in terms of useful, responsive swap space you can only use a little bit more than you used to. Using (say) 8GB of swap is much, much slower than using 256MB of swap.
It seems that the time when Captchas were an effective way to protect valuable resources is over. Where valuable means "anything of more than a tiny value that is available in large numbers". One email account isn't of value, but a million mail accounts is worth a lot to a spammer, and it's just as easy to get a million automatically as it is to get one.
Frankly, modern captchas are often past the point where I can read them; and the image recognition programs are good enough to get a useful correct recognition rate. This tells us that captcha is a dead end, AI in the form of image processing is now about the same "intelligence" as a human, so there is nowhere for captchas to go.
What to do instead? Well, looking at that report, the bot signup surely looks recognisable - the same IP constantly trying to sign up? But maybe big NAT networks mean that "same IP" isn't a safe bet to block?
If you can't recognise the bot, and it can answer simple questions as well as a human, then the only thing left is to provide another form of identification - like a real-life physical ID.
I think that the truly great managers do understand a lot of what goes on and could do some of it - but only as an additional skill to the general management and people skills they have, and they will still know their own limits and have people they trust.
But a good manager doesn't need to be that good - so long as they are reasonably smart, humble and capable they don't need to know how to do all the jobs.
Great managers are very few and far between. Good managers are much easier to find (though still rarer than we'd all like).
Agreed - crashes in the browser itself are rare - Firefox seems very reliable in that way. However crashes in plugins can be common, and indeed trusting a big binary blob to invasively use your process safely just seems like a bad idea. So I would say that firefox should definitely go for that part and not worry about the process-per-tab part. Well like most good ideas it has been in Bugzilla for years! https://bugzilla.mozilla.org/show_bug.cgi?id=156493
Actually, I have been thinking lately that some of the summaries are really excellent, particularly in linking back to previous stories and explaining why the story is different now. There is a certain significant minority that seem to be too misleading about articles to be just accident, but thats a minority. Maybe bad summaries have replaced dupes?
I just don't see what is so visually amazing to look at. As far as I can remember it's mostly just driving/running/fighting in dark urban areas. What does imax add to that? This was for me one reason I enjoyed Begins more, because it had the great scenery and general visual experience of the training sequence.
I had some shreds of sympathy for the record companies; I didn't (still don't) think piracy by itself is OK; but having paid these pathetic losers to illegally hassle people destroys that remaining sympathy. They can't claim any ethical or moral high ground if they use these kinds of tactics.
Games are in fact one of the ONLY things on consumer PCs that make heavy use of the hardware. Some people edit video also, or play HD video on their desktop. A small fraction do other 3D tasks. Of course these particular apps can use lots of CPU, but they always have.
The rest of it is trivial. In case you hadn't noticed, most modern OSes sit there using less than 1% of CPU most of the time. Sure, there are occasionaly bursts of activity but these are rare and usually related to other things that are already demanding.
Even the viruses are usually limited far more by the internet connection (how much spam can they send) than the CPU.
shows the latest design at 145 tonnes in June 2008. Has there been another big boost since then?? The 188 tonnes figure is from NASA's page and copied to WP but I don't see when it changed...
Sounds like it was more of a test or prototype battle station - not armed with anything but having various parts that would have been tested for possible later use (e.g. target dummies).
Yep, large-scale, multi-user/multi-instance server applications have to do something smarter. I don't have any direct experience but it's obvious the file only approach is not very managable.
Still the general advice applies: treat logging as any other development task. What are the requirements and constraints? In such a server environment you will arrive at different answers than for a single user desktop application or an embedded controller.
Not to mention the added complexity and failure modes. All but the most trivial databases can go wrong in interesting ways, and when that happens where will you put your logging? It's precisely when things go wrong that you need logging the most. So you want the least possible dependencies. Right now, that's appending text to a file - file systems are simpler and tested more thoroughly than even the best databases can be.
Like the user (or the system, or the virus...) shutdown the database server in the middle of operation. How do you prove that after the fact if the logs were going into the database?
As usual, "it depends" on what you are trying to achieve. Nobody can give you a blanket recommendation. But I guess in general: the log files need to give you enough information, that can't be got in other ways, to solve any problem that comes up.
We have a realtime product that goes all over the world and talks to hardware that we can't always get access to ourselves. Therefore, we sometimes must debug our code remotely. Obviously, logging is critical to this. We keep sometimes hundreds of MB of logs and have archiving rules and a tool for users to collect them. Every layer of the system keeps it's own logs, and all logs have timestamps to milliseconds.
In our case we log all the data back and forth, and then every important decision the code makes. For example if it decides there is something wrong with incoming data, it must log that. Any action it decides to take must be logged. Any data that will be passed on to other layers/the outside world must be shown. Generally, whenever we forget to log some of this data we will later regret it ("why the hell is it ignoring that device state..."). We also log at startup, basically the whole system configuration so that we can reproduce it.
Callstacks when there is an exception can be very useful. However, a lot of "errors" (at least in our case) are not exceptions but rather unexpected data or behaviour. We rarely have a crash and in state-based systems a callstack doesn't tell you much about what's going on. So a callstack is not useful for all situations.
Other times, you just want logging to give you a clue where in the code it was so you can run up the debugger and step through it (you do know how to step through code in the debugger, right?). In that case, too much logging can just get in the way. It might be sufficient in a GUI or web app to say which screen/page and which button was clicked.
You'd hope users could report this kind of details, but not always: if the user is working in another language, in another country, with two layers of helpdesk between you and them, and they are busy doing other things when the problem occurs and only call in the issue an hour later, and the helpdesk takes a week to report it to you - you may just get a vague or even misleading report that no-one can remember when you ask questions. In those cases log files may be all you have to go on.
There is also a tradeoff between log detail and manageability. Besides the difficulty in reading long log files, having a lot of detail means maintaining a lot of extra code. It also means that log files can become unmanagably large. In our case those hundreds of MB of logs can be a huge problem for customers to send to us because they have low quality internet connections (small companies in Mexico for example).
Surely the dark fibre is the easy part? Actually building out a GSM network means spending billions of dollars and years negotiating to build cell sites everywhere. While they have a few pieces of the puzzle, the cell sites themselves are the biggest and hardest part.
That's also nearly irrelevant, because what scammers want these days is either your user data (either by reading files or just getting you to type it in) or to use your bandwidth for spamming. Damaging user data is a rare and minor concern these days.
Of course they do need to be able to write exes (etc) to the system. But it doesnt help that a correct copy is still archived away - the new bad one is already running.
The problem with that approach is that for general users, the user interface *is* the product. They see nothing else and if it isn't good, whatever is underneath is irrelevant.
In addition, coming up with a good user interface is often quite a difficult part of the project.
So while it is fun for programmers to solve the interesting algorithms and pick nice tools and write a bunch of code, one of the hardest and most important parts is neglected.
True, but the US doesn't have a free market like Europe. It's tough living in an oligarchy. One day we can hope that the US people will be free to enjoy the fruits of capitalism.
Yes, this is a significant mistake, although it could be a mistake by someone in the reporting chain (some people are fuzzy on the difference between corporate positions). If the rest of the accusation is true though, then it's even worse - even more unlikely a President woould get involved than a CEO.
Because this time there are laws of physics that limit us, not just things we don't know. Of course, space travel can be done cheaper, but it is always going to be difficult. That's just the way the universe is, it seems.
It's not like we haven't attempted space flights. Thousands of launches have been done, and hundreds of manned flights, and the fact is it's not getting any easier in the last 40 years. Various ideas have been tried out and been found to be just as expensive or more so.
Slashdot Mirror
Speaking for myself, China is so far much smaller than I expected for our tech product, and smaller in proportion than any other market. We speculate about why: perhaps the attitude in China is, why wouldn't we do it ourselves?
That's a good point, and seems increasingly likely by now. Still, when trying to evaluate solutions, it doesn't help to have a list that blanket excludes everything. If the problem gets bad enough, some of those things it excludes will turn out to be tolerable (for example, anonymous mailing).
I do the same thing, but it's not an answer to the general case, of how to prevent spammers from signing up for seemingly legitimate email addresses.
I agree all these things are difficult. So what solution do you suggest?
That form is amusing and enlightening for first-time proposals at solving spam. But as far as I can tell, it also rules out all solutions because it assumes there is a solution that doesn't have any cost or compromise.
The likely reality is that someone will have to pay or be inconvenienced to solve spam.
Indeed. While hard drive space is 100-1000 times what it used to be, the speed is only about double or triple. So in terms of useful, responsive swap space you can only use a little bit more than you used to.
Using (say) 8GB of swap is much, much slower than using 256MB of swap.
It seems that the time when Captchas were an effective way to protect valuable resources is over. Where valuable means "anything of more than a tiny value that is available in large numbers". One email account isn't of value, but a million mail accounts is worth a lot to a spammer, and it's just as easy to get a million automatically as it is to get one.
Frankly, modern captchas are often past the point where I can read them; and the image recognition programs are good enough to get a useful correct recognition rate. This tells us that captcha is a dead end, AI in the form of image processing is now about the same "intelligence" as a human, so there is nowhere for captchas to go.
What to do instead? Well, looking at that report, the bot signup surely looks recognisable - the same IP constantly trying to sign up? But maybe big NAT networks mean that "same IP" isn't a safe bet to block?
If you can't recognise the bot, and it can answer simple questions as well as a human, then the only thing left is to provide another form of identification - like a real-life physical ID.
I think that the truly great managers do understand a lot of what goes on and could do some of it - but only as an additional skill to the general management and people skills they have, and they will still know their own limits and have people they trust.
But a good manager doesn't need to be that good - so long as they are reasonably smart, humble and capable they don't need to know how to do all the jobs.
Great managers are very few and far between. Good managers are much easier to find (though still rarer than we'd all like).
Agreed - crashes in the browser itself are rare - Firefox seems very reliable in that way.
However crashes in plugins can be common, and indeed trusting a big binary blob to invasively use your process safely just seems like a bad idea. So I would say that firefox should definitely go for that part and not worry about the process-per-tab part.
Well like most good ideas it has been in Bugzilla for years!
https://bugzilla.mozilla.org/show_bug.cgi?id=156493
Actually, I have been thinking lately that some of the summaries are really excellent, particularly in linking back to previous stories and explaining why the story is different now. There is a certain significant minority that seem to be too misleading about articles to be just accident, but thats a minority. Maybe bad summaries have replaced dupes?
I just don't see what is so visually amazing to look at. As far as I can remember it's mostly just driving/running/fighting in dark urban areas. What does imax add to that? This was for me one reason I enjoyed Begins more, because it had the great scenery and general visual experience of the training sequence.
I had some shreds of sympathy for the record companies; I didn't (still don't) think piracy by itself is OK; but having paid these pathetic losers to illegally hassle people destroys that remaining sympathy. They can't claim any ethical or moral high ground if they use these kinds of tactics.
You've trotted out the same old arguments.
Games are in fact one of the ONLY things on consumer PCs that make heavy use of the hardware. Some people edit video also, or play HD video on their desktop. A small fraction do other 3D tasks. Of course these particular apps can use lots of CPU, but they always have.
The rest of it is trivial. In case you hadn't noticed, most modern OSes sit there using less than 1% of CPU most of the time. Sure, there are occasionaly bursts of activity but these are rare and usually related to other things that are already demanding.
Even the viruses are usually limited far more by the internet connection (how much spam can they send) than the CPU.
This 188,000 kg to LEO figure is interesting. That's a big jump from previous figures.
This page:
http://www.geocities.com/launchreport/ares5.html
shows the latest design at 145 tonnes in June 2008. Has there been another big boost since then?? The 188 tonnes figure is from NASA's page and copied to WP but I don't see when it changed...
Sounds like it was more of a test or prototype battle station - not armed with anything but having various parts that would have been tested for possible later use (e.g. target dummies).
Still cool in a ghoulish way ...
Yep, large-scale, multi-user/multi-instance server applications have to do something smarter. I don't have any direct experience but it's obvious the file only approach is not very managable.
Still the general advice applies: treat logging as any other development task. What are the requirements and constraints? In such a server environment you will arrive at different answers than for a single user desktop application or an embedded controller.
Not to mention the added complexity and failure modes. All but the most trivial databases can go wrong in interesting ways, and when that happens where will you put your logging? It's precisely when things go wrong that you need logging the most. So you want the least possible dependencies. Right now, that's appending text to a file - file systems are simpler and tested more thoroughly than even the best databases can be.
Like the user (or the system, or the virus...) shutdown the database server in the middle of operation. How do you prove that after the fact if the logs were going into the database?
As usual, "it depends" on what you are trying to achieve. Nobody can give you a blanket recommendation. But I guess in general: the log files need to give you enough information, that can't be got in other ways, to solve any problem that comes up.
We have a realtime product that goes all over the world and talks to hardware that we can't always get access to ourselves. Therefore, we sometimes must debug our code remotely. Obviously, logging is critical to this. We keep sometimes hundreds of MB of logs and have archiving rules and a tool for users to collect them. Every layer of the system keeps it's own logs, and all logs have timestamps to milliseconds.
In our case we log all the data back and forth, and then every important decision the code makes. For example if it decides there is something wrong with incoming data, it must log that. Any action it decides to take must be logged. Any data that will be passed on to other layers/the outside world must be shown. Generally, whenever we forget to log some of this data we will later regret it ("why the hell is it ignoring that device state..."). We also log at startup, basically the whole system configuration so that we can reproduce it.
Callstacks when there is an exception can be very useful. However, a lot of "errors" (at least in our case) are not exceptions but rather unexpected data or behaviour. We rarely have a crash and in state-based systems a callstack doesn't tell you much about what's going on. So a callstack is not useful for all situations.
Other times, you just want logging to give you a clue where in the code it was so you can run up the debugger and step through it (you do know how to step through code in the debugger, right?). In that case, too much logging can just get in the way. It might be sufficient in a GUI or web app to say which screen/page and which button was clicked.
You'd hope users could report this kind of details, but not always: if the user is working in another language, in another country, with two layers of helpdesk between you and them, and they are busy doing other things when the problem occurs and only call in the issue an hour later, and the helpdesk takes a week to report it to you - you may just get a vague or even misleading report that no-one can remember when you ask questions. In those cases log files may be all you have to go on.
There is also a tradeoff between log detail and manageability. Besides the difficulty in reading long log files, having a lot of detail means maintaining a lot of extra code. It also means that log files can become unmanagably large. In our case those hundreds of MB of logs can be a huge problem for customers to send to us because they have low quality internet connections (small companies in Mexico for example).
Hence the attempts at SPF and SenderID, which aims to provide some confidence if Reply addresses are genuine.
Surely the dark fibre is the easy part? Actually building out a GSM network means spending billions of dollars and years negotiating to build cell sites everywhere.
While they have a few pieces of the puzzle, the cell sites themselves are the biggest and hardest part.
That's also nearly irrelevant, because what scammers want these days is either your user data (either by reading files or just getting you to type it in) or to use your bandwidth for spamming. Damaging user data is a rare and minor concern these days.
Of course they do need to be able to write exes (etc) to the system. But it doesnt help that a correct copy is still archived away - the new bad one is already running.
The problem with that approach is that for general users, the user interface *is* the product. They see nothing else and if it isn't good, whatever is underneath is irrelevant.
In addition, coming up with a good user interface is often quite a difficult part of the project.
So while it is fun for programmers to solve the interesting algorithms and pick nice tools and write a bunch of code, one of the hardest and most important parts is neglected.
True, but the US doesn't have a free market like Europe. It's tough living in an oligarchy. One day we can hope that the US people will be free to enjoy the fruits of capitalism.
Yes, this is a significant mistake, although it could be a mistake by someone in the reporting chain (some people are fuzzy on the difference between corporate positions). If the rest of the accusation is true though, then it's even worse - even more unlikely a President woould get involved than a CEO.
Because this time there are laws of physics that limit us, not just things we don't know. Of course, space travel can be done cheaper, but it is always going to be difficult. That's just the way the universe is, it seems.
It's not like we haven't attempted space flights. Thousands of launches have been done, and hundreds of manned flights, and the fact is it's not getting any easier in the last 40 years. Various ideas have been tried out and been found to be just as expensive or more so.