What might work would be to have the app generate a GUID on login and when a bug is submitted, the app monitors the bug tracker and notifies the user when changes are made to the ticket or more info is required.
Sounds massively overcomplicated to me. Bugs (should) have an ID anyway; the devs need something to track them by, and databases are great for generating such stuff. But a GUID is just nasty; too long to be a good identifier for human beings to use, and also not containing any real information. A URL to the webpage that tracks the bug works much better.
I understand why registration is used but on the flipside, I have decided against reporting bugs because of the registration process. The above idea would fix that.
No, it wouldn't. It just means that you've added more complexity with having another damn application or feature to debug! It also wouldn't work in a lot of corporate settings, where apps are strictly prohibited from doing anything like phoning home.
As I wrote previously, anon bug reports are a painful source of spam, but they're also potentially valuable when you've got a large user community. Sometimes I guess there's no easy answer to the utility/abuse challenge.
Also, not everyone lives in towns that are less than 10 miles in diameter.
What's that got to do with anything? Lots of people in the UK live in big cities. (It's implicit in the description, "big city".)
More to the point, there is absolutely no technical reason for there to be a single transmitter per city. Indeed when it is also hilly area, repeaters are needed to ensure everyone can get a signal. This is common where I live; ice-cut valleys have steep sides, which would otherwise make for large signal black-spots.
Some open-source projects get all the bug reports they can handle despite the difficulty. Ease-of-use improvements in Bugzilla which increase the number of junk bugs reported by people who can't be bothered to put a little effort into it may not actually be helpful.
More of an issue is the fact that if you allow anonymous submissions, you tend to get a problem with spam. It's not generally difficult to deal with spam, but it does take time to triage and squelch.
OTOH, in the past I've fixed important bugs that were submitted anonymously and where I've never been able to identify after the fact who did the submission. I've also had some users mention to me that they never submit bug reports where they have to identify themselves in the process. Prohibiting anonymous submissions does mean that you miss out on some things.
On reflection, I'd suggest that only large should accept anonymous submissions, since that at least saves effort for things that are reported properly. Large projects have to decide for themselves whether they value anonymous reports or spam-freedom more; I'm in two minds about it, depending on whether I'm dealing with spam or bugs at the time. If you do allow anon submissions, make sure you've got a mailing list set up to track all changes in the bug DB, since that makes it much easier to see trouble...
Agreed. However, with just a little research, whoever's doing the tech for Joe's Cafeteria can find out where to report that bug and, once reported it will probably get fixed a lot faster than a bug in a closed source program.
That varies. Some vendors are really good, better than the majority of OSS projects. But yes, others are crap-shovelers; in some cases, where I've had access to the code under NDA, the code has been bad enough that I've just been left speechless.
I think the real determinant on quality is actually the skill of the people who have time to work on maintenance and development; the whole closed/open debate is pretty much orthogonal to that, except in how open code means that it is more likely (though not guaranteed) for someone good to look at it.
So an entire community that emits no carbon dioxide. What are the inhabitants, vampires? Zombies? Undead "not otherwise specified"? This "green movement" is getting out of control when we turn to the dark powers.
Can't be zombies. You'd get methane off them as they decompose and that converts fairly rapidly to CO2.
And whether anyone's been "smart" enough to decide to run the out-of-band management access over the same network as the production networking "to save resources"...
Guess what: one way of implementing parametrized queries is through automatic escaping!
It's a slow way of doing it though, since the database engine will need to reparse the statement from scratch each time. Far better to use a real parameterized query when the engine can cache a compiled form. (A performance boost and more security at the same time? Win-win! What's not to like?)
If a blackhat already has access to something like a university's mail system (say through someone's weak password), and sends a message to these known-bad addresses (aka, honyepot) through the university's mail system, then he's successfully blacklisted the university's mail servers
You seem to assume that this isn't already a problem. If only you were right; if only...
OTOH, in practice most spam (well, using the sample that gets in my mailbox) actually seems to be routed via hacked home systems.
If it was profitable to do this, someone would already doing it. Hell, if it's such a simple idea you could start up a business yourself and melt salt when the electricity price is negative. Unfortunately, having a salt melting plant sitting idle for 99% of the time doesn't make up for the 1% of the time you can store energy.
On the other hand, with increasing amounts of uncontrollable energy sources and falling energy storage costs, it will be profitable at some stage. We're just not there yet.
Actually, there are a number of pumped storage systems deployed. The power they produce is expensive, but they follow a strategy of buying when prices (and demand) are at their lowest and selling high. Classic economics. These molten salt plants will fit in the same category and, presumably, follow very similar commercial strategies, though I've not seen what the cost-profile of the technology is.
But if it lets execs strut about, getting good press and feeling like they're doing something community-spirited at the same time as improving the bottom line, so much the better. Only problem right now is finding enough money to do the capital investment to change anything.
Well, that's not the only problem. In many cases, the biggest real problem is that the business unit that will incur the extra costs to make the change is different from the business unit that will reap the savings. Stupid, but true.
The picture is getting more and more complicated when it comes to software development, and I think that's wrong. I liked.Net as an idea. We could all code to one platform, but the business/IP aspects prevented that technical utopia. I am hoping that LGPL Qt will, while a little more limited be that multi-platform toolkit that everyone can use to solve new problems, instead of continually recoding the old ones.
The problem with Qt at least for desktop apps is that apps written with it look and feel like Qt apps. If you're on a Qt-based desktop (hi there, KDE!) that's not an issue at all, but on Win or OSX they just don't feel right (despite functioning absolutely correctly). Or at least not without large amounts of effort to put in platform-specific tuning, which makes something of a mockery of the whole "multi-platform"-ness. Now, I'm a bit of a cynic so I think the problem is expecting magic to make GUI code transmogrify between the very different platforms; that just doesn't seem to work, at least with current abstractions.
OTOH, it's possible to do a very acceptable cross-platform non-GUI toolkit. Sure you won't have access to the full OS API, but you will have a substantial and useful subset. The problem with GUIs is that they really are different on different platforms.
as unpopular as it is to say so, I have to agree, I personally haven't found a single useful webapp for what I normally do, I see the usefulness of intranet server based apps, but webapps are generally useless, slow, buggy and problematic
Either what you do normally is pretty intensive of resources (not webapps strong point to date) or you're not doing a lot of work across multiple organizations. Trying to deploy something in a highly distributed and heterogenous setting is an utter nightmare, and using a webapp instead turns it into just plain sucky.
Although it's normally not recommended to use the gears for braking. For better control of the car, you should brake first and then move into the right gear.
With modern materials, gearboxes and clutches last pretty well even when you're using them for braking a lot. I find that the best rule to follow when approaching a light or roundabout is to be in a gear that is suitable for both bringing me to a stop and accelerating away if things are clear. When following that rule, I've noticed that the majority of the speed changes are done without the use of brakes under normal conditions.
If you got yourself into a situation where you can't react to events other than by making it more dangerous, you've made a bad blunder. (What that means in practice will vary, but if someone is really tailgating me, I'll gradually slow down so that they've got space to stop safely if I have to brake suddenly; I'm not in that much of a hurry after all and I'm not at all keen on being in an accident of course.)
They just installed one at the intersection outside my apartment. I was sitting at the intersection waiting for a green light and no other cars were around and yet a bright flash from the camera went off in my face not once but twice. I can't stand the damn thing.
They need two pictures (preferably a measured amount of time apart) to prove that a car running the red light was moving and not just broken down in a bad spot.
Fourth - No smoke. Fill the burning rooms with smoke, so that you can only just see the exit signs or, indeed, the fire. Much more realistic and useful (I can find my out of any building in broad daylight - that's not the problem you're testing here).
Fire evacuation strategies for large buildings depend on getting people out before the smoke becomes dense enough to see (institutional smoke detectors are typically pretty sensitive and checked regularly). This is wise, because smoke is really dangerous (toxic gases it contains are the big problem) and is why, when that alarm goes off, you should make sure you evacuate yourself safely; you should have plenty of time, and if you do so you (and everyone else) will be safe. If you wait, you greatly increase the danger to yourself and others. And leave going near smoke to firemen with equipment and training.
(Yes, I've had fire evacuation warden training. Does it show?)
I don't trust lumens either. The lumen output of CFL lighting halves every foot or so from the light source.
It's worse than that, mate. Every time you double the distance, the brightess goes down by a factor of four! So, two feet away, the bulb is a quarter as bright as it was a foot away.
OTOH, your eye perceives apparent brightness logarithmically, so the light will appear to decrease linearly in brightness with distance. It's not all doom and gloom!
If they worked we could do away with trial by jury - just hook them up and ask "did you kill your wife?" and if the detector says they did then throw them in jail for 20 years.
Wouldn't work so well if the person being questioned believed at the time that they did not. (Now, if lie detectors were accurately named, they'd be called "stress detectors", but lies are not the only source of stress in a courtroom...)
Sure, I should probably lock the door of my house when I leave for work... It's probably a good idea to lock my car in the parking lot, too... But that doesn't mean it isn't a criminal act if you walk into my house and steal something.
Yes, from an insurance standpoint not locking the door will likely have an effect. If my insurance company knows that I didn't lock my car they probably won't pay for any repairs it may need after being recovered. But the guy who steals it is still a criminal, still goes on trial, and still goes to jail.
In that specific case? It's possible that if you didn't take "reasonable" steps to secure your property, the thief would be able to get a lesser sentence. (Yeah, this really does depend on the jurisdiction, but the principle of mitigating and aggravating factors changing the sentence will hold true everywhere which uses English Common Law as the basis, including the US. AIUI anyway.)
With hacking, the key bad act is the usage of the computer without the approval of the owner. If the user fails to keep patched that will mitigate, but leaving behind anything to make it easier to get back in would (significantly) aggravate, just as making a copy of the house key would make burglary much worse. (According to TFS, one of the objectives of the hacking was the theft of "bank passwords", which is a separate fraud-related crime.)
This was an intentional criminal act.
Yeah. And (leaving the law out for the moment) it really comes down to whether we, as a community, could ever trust him again. I don't think I could; if I ever hired him to do something for me, I'd not want to use the result until I'd had it independently verified by someone I trust. But then again, at that point I'd just hire the trusted verifier to do the work for me in the first place...
I would say the main downside of a credit card (besides not curing aids like cash-injected-in-the-vein can) is that credit card companies are pocketing a few percentage points of each transaction you make. You think the vendors are paying it, not you. Think again. The consumer ultimately pays for everything.
It cuts both ways. Handling cash is tremendously expensive (or did you think that armored cars and security staff were free?) and ultimately that increases the price of goods as well. You might not see it as a line-item on the receipt, but it's still there.
I've absolutely no idea about the relative cost of handling cash or credit cards.
If the 90/10 market share is true, then those systems should have 10% of the virus market by that logic.
Only if you assume that there is a linear relationship between market share and number of viruses. If that was so, I'd be really surprised. In practice, it seems to be much more closely related to a higher power of market share (e.g. cubed, though I've no evidence for that) and there are substantive hysteresis effects as well. Nobody and nothing in human affairs turns on a dime.
And that's still assuming that all OSes are fundamentally equally vulnerable. The only response to that has got to be "O RLY?"
In any case judging samba performance on the basis of a very odd use-case like 50 users hitting a single file is kind of strange.
It's not that strange in education, especially with large classes (but perhaps more so at Universities than at schools). What happens is you get lots of people get to about the same point in a practical class at about the same time, and then they sit there and repeatedly hammer whatever services you've got up to support them until they get through.
Business usage patterns are different to education ones. You can't really use experience with one to predict the other. (Alas. It'd be so much easier if you could...)
Often when I get into intractable arguments like this, it turns out in the end that the disagreement boils down to differing definitions of a specific word. In this case, I suspect it is 'philosophy'. Merriam Webster has a few definitions, of which 'pursuit of wisdom' would probably satisfy those lumping science in with philosophy. On the other hand, 'a search for a general understanding of values and reality by chiefly speculative rather than observational means' would tend to exclude science.
Science used to be called Natural Philosophy, and can still be regarded as a sub-discipline of philosophy. It's just a branch that (largely) takes as axioms that it is sensible and practical to observe the world, perform experiments, and draw conclusions from that activity. It looks like a successful approach to me, but what do I know?
Slashdot Mirror
What might work would be to have the app generate a GUID on login and when a bug is submitted, the app monitors the bug tracker and notifies the user when changes are made to the ticket or more info is required.
Sounds massively overcomplicated to me. Bugs (should) have an ID anyway; the devs need something to track them by, and databases are great for generating such stuff. But a GUID is just nasty; too long to be a good identifier for human beings to use, and also not containing any real information. A URL to the webpage that tracks the bug works much better.
I understand why registration is used but on the flipside, I have decided against reporting bugs because of the registration process. The above idea would fix that.
No, it wouldn't. It just means that you've added more complexity with having another damn application or feature to debug! It also wouldn't work in a lot of corporate settings, where apps are strictly prohibited from doing anything like phoning home.
As I wrote previously, anon bug reports are a painful source of spam, but they're also potentially valuable when you've got a large user community. Sometimes I guess there's no easy answer to the utility/abuse challenge.
Also, not everyone lives in towns that are less than 10 miles in diameter.
What's that got to do with anything? Lots of people in the UK live in big cities. (It's implicit in the description, "big city".)
More to the point, there is absolutely no technical reason for there to be a single transmitter per city. Indeed when it is also hilly area, repeaters are needed to ensure everyone can get a signal. This is common where I live; ice-cut valleys have steep sides, which would otherwise make for large signal black-spots.
The #1 thing that is going to guarantee his security is this- if he dies, Biden becomes president.
If that was his approach to security he would have asked Dick Cheney to be his running mate ;)
Don't be silly. Obama's a lawyer and wouldn't want to be shot by his own Veep.
Some open-source projects get all the bug reports they can handle despite the difficulty. Ease-of-use improvements in Bugzilla which increase the number of junk bugs reported by people who can't be bothered to put a little effort into it may not actually be helpful.
More of an issue is the fact that if you allow anonymous submissions, you tend to get a problem with spam. It's not generally difficult to deal with spam, but it does take time to triage and squelch.
OTOH, in the past I've fixed important bugs that were submitted anonymously and where I've never been able to identify after the fact who did the submission. I've also had some users mention to me that they never submit bug reports where they have to identify themselves in the process. Prohibiting anonymous submissions does mean that you miss out on some things.
On reflection, I'd suggest that only large should accept anonymous submissions, since that at least saves effort for things that are reported properly. Large projects have to decide for themselves whether they value anonymous reports or spam-freedom more; I'm in two minds about it, depending on whether I'm dealing with spam or bugs at the time. If you do allow anon submissions, make sure you've got a mailing list set up to track all changes in the bug DB, since that makes it much easier to see trouble...
How many times has google been hacked in its 11 year history? Answer: Anybody, anybody?
To be fair, if they had been they wouldn't tell anyone. They don't even like to admit when they have service downtime.
Agreed. However, with just a little research, whoever's doing the tech for Joe's Cafeteria can find out where to report that bug and, once reported it will probably get fixed a lot faster than a bug in a closed source program.
That varies. Some vendors are really good, better than the majority of OSS projects. But yes, others are crap-shovelers; in some cases, where I've had access to the code under NDA, the code has been bad enough that I've just been left speechless.
I think the real determinant on quality is actually the skill of the people who have time to work on maintenance and development; the whole closed/open debate is pretty much orthogonal to that, except in how open code means that it is more likely (though not guaranteed) for someone good to look at it.
So an entire community that emits no carbon dioxide. What are the inhabitants, vampires? Zombies? Undead "not otherwise specified"? This "green movement" is getting out of control when we turn to the dark powers.
Can't be zombies. You'd get methane off them as they decompose and that converts fairly rapidly to CO2.
Depends how good your out-of-band management is.
And whether anyone's been "smart" enough to decide to run the out-of-band management access over the same network as the production networking "to save resources"...
Guess what: one way of implementing parametrized queries is through automatic escaping!
It's a slow way of doing it though, since the database engine will need to reparse the statement from scratch each time. Far better to use a real parameterized query when the engine can cache a compiled form. (A performance boost and more security at the same time? Win-win! What's not to like?)
If a blackhat already has access to something like a university's mail system (say through someone's weak password), and sends a message to these known-bad addresses (aka, honyepot) through the university's mail system, then he's successfully blacklisted the university's mail servers
You seem to assume that this isn't already a problem. If only you were right; if only...
OTOH, in practice most spam (well, using the sample that gets in my mailbox) actually seems to be routed via hacked home systems.
If it was profitable to do this, someone would already doing it. Hell, if it's such a simple idea you could start up a business yourself and melt salt when the electricity price is negative. Unfortunately, having a salt melting plant sitting idle for 99% of the time doesn't make up for the 1% of the time you can store energy.
On the other hand, with increasing amounts of uncontrollable energy sources and falling energy storage costs, it will be profitable at some stage. We're just not there yet.
Actually, there are a number of pumped storage systems deployed. The power they produce is expensive, but they follow a strategy of buying when prices (and demand) are at their lowest and selling high. Classic economics. These molten salt plants will fit in the same category and, presumably, follow very similar commercial strategies, though I've not seen what the cost-profile of the technology is.
Big Enterprise just cares about the bottom line.
But if it lets execs strut about, getting good press and feeling like they're doing something community-spirited at the same time as improving the bottom line, so much the better. Only problem right now is finding enough money to do the capital investment to change anything.
Well, that's not the only problem. In many cases, the biggest real problem is that the business unit that will incur the extra costs to make the change is different from the business unit that will reap the savings. Stupid, but true.
The picture is getting more and more complicated when it comes to software development, and I think that's wrong. I liked .Net as an idea. We could all code to one platform, but the business/IP aspects prevented that technical utopia. I am hoping that LGPL Qt will, while a little more limited be that multi-platform toolkit that everyone can use to solve new problems, instead of continually recoding the old ones.
The problem with Qt at least for desktop apps is that apps written with it look and feel like Qt apps. If you're on a Qt-based desktop (hi there, KDE!) that's not an issue at all, but on Win or OSX they just don't feel right (despite functioning absolutely correctly). Or at least not without large amounts of effort to put in platform-specific tuning, which makes something of a mockery of the whole "multi-platform"-ness. Now, I'm a bit of a cynic so I think the problem is expecting magic to make GUI code transmogrify between the very different platforms; that just doesn't seem to work, at least with current abstractions.
OTOH, it's possible to do a very acceptable cross-platform non-GUI toolkit. Sure you won't have access to the full OS API, but you will have a substantial and useful subset. The problem with GUIs is that they really are different on different platforms.
as unpopular as it is to say so, I have to agree, I personally haven't found a single useful webapp for what I normally do, I see the usefulness of intranet server based apps, but webapps are generally useless, slow, buggy and problematic
Either what you do normally is pretty intensive of resources (not webapps strong point to date) or you're not doing a lot of work across multiple organizations. Trying to deploy something in a highly distributed and heterogenous setting is an utter nightmare, and using a webapp instead turns it into just plain sucky.
Although it's normally not recommended to use the gears for braking. For better control of the car, you should brake first and then move into the right gear.
http://www.ridedrive.co.uk/tipoffs19.htm
With modern materials, gearboxes and clutches last pretty well even when you're using them for braking a lot. I find that the best rule to follow when approaching a light or roundabout is to be in a gear that is suitable for both bringing me to a stop and accelerating away if things are clear. When following that rule, I've noticed that the majority of the speed changes are done without the use of brakes under normal conditions.
If you got yourself into a situation where you can't react to events other than by making it more dangerous, you've made a bad blunder. (What that means in practice will vary, but if someone is really tailgating me, I'll gradually slow down so that they've got space to stop safely if I have to brake suddenly; I'm not in that much of a hurry after all and I'm not at all keen on being in an accident of course.)
They just installed one at the intersection outside my apartment. I was sitting at the intersection waiting for a green light and no other cars were around and yet a bright flash from the camera went off in my face not once but twice. I can't stand the damn thing.
They need two pictures (preferably a measured amount of time apart) to prove that a car running the red light was moving and not just broken down in a bad spot.
Fourth - No smoke. Fill the burning rooms with smoke, so that you can only just see the exit signs or, indeed, the fire. Much more realistic and useful (I can find my out of any building in broad daylight - that's not the problem you're testing here).
Fire evacuation strategies for large buildings depend on getting people out before the smoke becomes dense enough to see (institutional smoke detectors are typically pretty sensitive and checked regularly). This is wise, because smoke is really dangerous (toxic gases it contains are the big problem) and is why, when that alarm goes off, you should make sure you evacuate yourself safely; you should have plenty of time, and if you do so you (and everyone else) will be safe. If you wait, you greatly increase the danger to yourself and others. And leave going near smoke to firemen with equipment and training.
(Yes, I've had fire evacuation warden training. Does it show?)
I managed to get a hold on the actual source code. Here's a sample:
Sss (sss, sssSSS, sS, sSS):
S.SS = s[S].s SSss * sssss / S(SSs) + sSSSs
[...]
Does anyone here speak python?
You don't want Python, you want Lissssp. All those S-expressions...
I don't trust lumens either. The lumen output of CFL lighting halves every foot or so from the light source.
It's worse than that, mate. Every time you double the distance, the brightess goes down by a factor of four! So, two feet away, the bulb is a quarter as bright as it was a foot away.
OTOH, your eye perceives apparent brightness logarithmically, so the light will appear to decrease linearly in brightness with distance. It's not all doom and gloom!
If they worked we could do away with trial by jury - just hook them up and ask "did you kill your wife?" and if the detector says they did then throw them in jail for 20 years.
Wouldn't work so well if the person being questioned believed at the time that they did not. (Now, if lie detectors were accurately named, they'd be called "stress detectors", but lies are not the only source of stress in a courtroom...)
Sure, I should probably lock the door of my house when I leave for work... It's probably a good idea to lock my car in the parking lot, too... But that doesn't mean it isn't a criminal act if you walk into my house and steal something.
Yes, from an insurance standpoint not locking the door will likely have an effect. If my insurance company knows that I didn't lock my car they probably won't pay for any repairs it may need after being recovered. But the guy who steals it is still a criminal, still goes on trial, and still goes to jail.
In that specific case? It's possible that if you didn't take "reasonable" steps to secure your property, the thief would be able to get a lesser sentence. (Yeah, this really does depend on the jurisdiction, but the principle of mitigating and aggravating factors changing the sentence will hold true everywhere which uses English Common Law as the basis, including the US. AIUI anyway.)
With hacking, the key bad act is the usage of the computer without the approval of the owner. If the user fails to keep patched that will mitigate, but leaving behind anything to make it easier to get back in would (significantly) aggravate, just as making a copy of the house key would make burglary much worse. (According to TFS, one of the objectives of the hacking was the theft of "bank passwords", which is a separate fraud-related crime.)
This was an intentional criminal act.
Yeah. And (leaving the law out for the moment) it really comes down to whether we, as a community, could ever trust him again. I don't think I could; if I ever hired him to do something for me, I'd not want to use the result until I'd had it independently verified by someone I trust. But then again, at that point I'd just hire the trusted verifier to do the work for me in the first place...
I would say the main downside of a credit card (besides not curing aids like cash-injected-in-the-vein can) is that credit card companies are pocketing a few percentage points of each transaction you make. You think the vendors are paying it, not you. Think again. The consumer ultimately pays for everything.
It cuts both ways. Handling cash is tremendously expensive (or did you think that armored cars and security staff were free?) and ultimately that increases the price of goods as well. You might not see it as a line-item on the receipt, but it's still there.
I've absolutely no idea about the relative cost of handling cash or credit cards.
If the 90/10 market share is true, then those systems should have 10% of the virus market by that logic.
Only if you assume that there is a linear relationship between market share and number of viruses. If that was so, I'd be really surprised. In practice, it seems to be much more closely related to a higher power of market share (e.g. cubed, though I've no evidence for that) and there are substantive hysteresis effects as well. Nobody and nothing in human affairs turns on a dime.
And that's still assuming that all OSes are fundamentally equally vulnerable. The only response to that has got to be "O RLY?"
In any case judging samba performance on the basis of a very odd use-case like 50 users hitting a single file is kind of strange.
It's not that strange in education, especially with large classes (but perhaps more so at Universities than at schools). What happens is you get lots of people get to about the same point in a practical class at about the same time, and then they sit there and repeatedly hammer whatever services you've got up to support them until they get through.
Business usage patterns are different to education ones. You can't really use experience with one to predict the other. (Alas. It'd be so much easier if you could...)
Often when I get into intractable arguments like this, it turns out in the end that the disagreement boils down to differing definitions of a specific word. In this case, I suspect it is 'philosophy'. Merriam Webster has a few definitions, of which 'pursuit of wisdom' would probably satisfy those lumping science in with philosophy. On the other hand, 'a search for a general understanding of values and reality by chiefly speculative rather than observational means' would tend to exclude science.
Science used to be called Natural Philosophy, and can still be regarded as a sub-discipline of philosophy. It's just a branch that (largely) takes as axioms that it is sensible and practical to observe the world, perform experiments, and draw conclusions from that activity. It looks like a successful approach to me, but what do I know?