I didn't say "web pages" either. I said pages. If one chooses to re-interpret my words to specifically make them incorrect, then I'm not able to correct them -- they'll just do so once more. This all exists with paper pages, data pages, memory pages, web pages, and every other type of page. For as long as caching has existed, it has been to reduce one resource at the expense of another. In this case, it's to reduce bandwidth at the expense of everything else -- hardware, processing, disk, performance, and speed.
Then you'll want to add input lag into that latency calculation. I'm using a colour-accurate medical imaging monitor. Takes another 100ms to go from mouse-to-monitor. Even more if I'm using a wireless mouse.
If you're a'gonna measure anything, you've got to me measuring cradle-to-grave, otherwise it's meaningless. So, if you're measuring the speed of the browser, to the user that is, then your only option is to measure click-to-read. That's the time the computer gets its very first input (the mouse click) to the time it sends the very first output (the first text/image of the page).
After three decades of personal and professional experience, I'm telling you that it's faster inline than disk-cached, every time (for reasonably-sized scripts, and reasonably-fast connections).
Of course it does. Look at the pure bandwidth capabilities. Most network cards can receive way faster than any HDDs, and most SSDs. Transmission and memory are, in principle, way faster than long-term permanent secure protected storage.
That's why we had music before records, and television before VCRs, and live sports broadcasts before instant replays. Storage is tough.
Dell machines are usually designed to be quiet. That's why things are slow. But that's a different story.
You aren't working cradle-to-grave. hitting the local disk isn't about the disk speed. Those 15ms can be zero for this discussion. Similarly, the ping to the site of 125ms is meaningless. Here's what happens, cradle-to-grave:
Scenario 1, live streaming: connect to site: 125 ms download 200KB of html and javascript, compressed to 100KB, 1s
Scenario 2, external file: connect to site: 125ms download 100KB of html, compressed to 50KB, 1s download 100KB of javascript, compressed to 50KB, 1s
Scenario 3, external file cached: connect to site: 125ms download 100KB of html, compressed to 50KB, 1s wait for disk to be available, access disk for 100KB of javascript, wait for disk to spin up, 15ms wait for virus scan, read cache meta data, determine that our cache file isn't already too old, 1s HEAD the web-site file, to compare meta data, check to see that our cache is good enough, 1s -- look at all of the side-work involved, and we're still hitting the site much of the time to check the cache anyway!
Scenario 4, external site connect to site: 125ms download 100KB of html, compressed to 50KB, 1s connect to second site: 125ms download 100KB of javascript, compressed to 50KB, 1s
Scenario 5, external site, cached connect to site: 125ms download 100KB of html, compressed to 50KB, 1s wait for disk to be available, access disk for 100KB of javascript, wait for disk to spin up, 15ms wait for virus scan, read cache meta data, determine that our cache file isn't already too old, 1s connect to second site: 125ms HEAD the web-site file, to compare meta data, check to see that our cache is good enough, 1s -- now we have side work, a second connection, traffic everywhere
And all of this gets even worse when you realize that the connection to your primary site is keep-alived for your entire visit -- minutes at a time -- but to your secondary site, you're lucky to get a full second. Add all of the other hardware that you're using, in terms of disk, cpu, virus scanners. Now add the entire local permission system, cooling system, throttling systems, battery savers, and you're now conflicting with everything else running in the background.
Google doesn't care how long it takes your page to load. It doesn't know how important the page is, so it could never judge two pages based on size alone. What google very-much does care about is how long it takes your page to render "something". Put your scripts at the end of the file. Output your logo very quickly, before you do any real server-side work. I promise the top one inch of your web-site can be the very same all the time.
You can get a device that is actually yours to control. If you've purchased something that's designed to screw you over, then you've got what you requested.
Read harder. I didn't say "browsers". I said "serving a page to a client". The world didn't begin with browsers. The web didn't start the internet. The internet wasn't the first network.
My first e-mail address had a comma in it, and token rings sucked for a lot of reasons. That's how long I've been developing web-sites.
But I didn't say I've been building web-site for three decades. I said, quite obviously, that I've been serving pages to clients for three decades.
You may be way too young to understand the difference between real-world practical and academic history, but the world wide web was not the start of the internet, the internet was not the start of networking, and networking was not the start of serving pages to clients.
Caching's been around for a very long time. If you want to learn about the benefits of caching, and the pitfalls, you want to look at archive caches, not transmission caches. When access involves an elevator, or a truck, you quickly learn what does and does not make sense.
Here's a perspective for you. When accessing a cache from a warehouse two miles away involves a truck, you get to consider the effects of rush hour traffic. So when your third-party server caches your javascript file, you get to consider that it isn't geographically in the same place as your primary server, meaning that not only does your client need to hit "another" server, with another connection, another keep-alive, and another set of caches, but it also needs to get there, through an ISP channel full of traffic. You've just doubled the amount of traffic globally. You can't ever bet on it being fast. You can only hope.
So, of course, you have a basement cache of your warehouse cache -- i.e. the disk cache. Elevators don't have traffic; or so you say. But the warehouse is full -- always, because that's what a warehouse is. So you get to search stacks and shelves and indexes. You get to have organizational training, and inventory days. Welcome to the magic of disk thrashing. The file table is incredibly slow in terms of file handles. Welcome to WAD files. Defragging is the inventory day, by the way.
So now you've got your reliable cache, that's only reliable under minimal load. Perfect. But some things get accessed often. So you keep a copy upstairs in the filing cabinet. But the filing cabinet is small. So you shuttle different cabinets up and down per day. Today you need the green cabinet. Tomorrow, the red. And life is good. Welcome to swap files -- memory to disk and back.
Now you've got employees shuttling cabinets, with dollies, and elevators, and warehouses, and trucks, and traffic. And here's the kicker. You haven't eaten yet! You've got a dozen staff, countless duplicate copies of files, trucks, buildings, elevators, desks. But you haven't done a lick of revenue-generating work yet.
Stop instructing your browser to block things. You don't need an add-on to define network connections. Start telling your network stack where to not find them:
You're wrong. I've been doing this for three decades now. If you're serving a page to a client, sending them to a third-party to get the library always sucks. Even if they've already got the library disk-cached, it's actually slower to access the disk cache, and check the cache age, and verify that there isn't a newer library version (did you know the browser often goes round-trip just to check?) than it does to simply serve the library in-line.
Serving the library yourself can still run in parallel, and it often reuses the same primary connection, so it's about as fast as your server can handle.
Now you're going to mention the browser's memory cache, instead of disk cache. First, nowadays, with each-tab-in-a-separate-sandboxed-process, those memory caches ain't as fast as they once were. But even when they are, you just ain't a'gonna beat in-line scripts.
Benchmark it yourself. Serve 100KB of javascript in-line, in the middle of your html file. Compare that to a separate src= js file. Mid-stream, in an HTML file of another 100KB, the javascript runs at full download speed, with full text transmission compression. Those 100KB easily compress down to 50KB, more often 25KB, mid-transmission, and at any modern residential bandwidth, you're talking about the tiniest of fractions of a second. No disk access, no file handles, no separate rendering processes, no sandboxes, and, most importantly, no virus scanners, no swapping.
But it does eat up your server's bandwidth costs.
If you're huge, amazon style, then you want to off-load cycles and bits anywhere you can. If you're not huge, then the added 10% bandwidth costs mean nothing to you.
There's no sense to thinking that medicating something would make it better. In this case, like in all cases, medicating the issue only makes it less-worse. It'll always be a gradual decline. Headache pills don't make you superman. They reduce the headache 99%, they don't eliminate it, and they have side-effects.
There are loads of reasons for modern-day psychiatric problems. I'd bet that most of them surround being indoors -- lack of light, lack of exercise, lack of real-world animal problems, lack of proper fresh air, lack of visual distance, lack of colour, lack of contrast, lack of sun. I'd bet that the rest surround a lifestyle based on work -- lack of variety, high stress, mostly indoors, all-hours, lack of control.
So given that the solution is a change in lifestyle, and probably a change of environment, the medication is nothing more than a crutch. If you don't solve the problem, congrats-to-you, now you live with a crutch. Gradual decline.
I'm not updating my fridge. I'm not updating my router. I'm not updating my toothbrush. I'm not updating my toilet. Aside from real security items -- and by that I mean the security of my blood coarsing through my arteries (and some specific veins) I'm not creating more work for myself. It's that simple.
My car gets semi-annual maintenance service because it can kill me in a heartbeat if it breaks. Elevators, furnaces, hot-water tanks, swimming pools, attics; these are the kinds of things that can cause death or major illness if not maintained.
Beyond that, nobody cares if my phone slows down, and while I don't want anyone listening to my calls, I ain't a'gonna spend every waking moment fighting back.
It's that simple.
Once again, I sleep in my house, protected by a dead-bolt lock, on a metal front door, right next to a glass window. The back door is all-glass. Absolutely nothing stops anyone from killing me in my sleep.
Why would you take your expensive and important office where downtime is such a big issue, and put it alone in a field where it's easy to access? That's not smart. That's just plain dumb.
No lock will repel a sledge hammer; so what are you trying to do with it? Put something else into your shed-the-backyard. Put your office elsewhere.
I can't believe we're sitting here, I'm 37 years old, and I'm finally getting stereo speakers. It's about time. I can't wait to turn 50, and get a headphone jack.
I still have a nokia phone -- my sixth in a row. Still with buttons. Best voice quality, small, light, not too-thin-to-hold. It's not my computer. It's my phone.
So, for all of those people who can't actually work on a phone -- because our work is bigger than a phone, in the same way that a general contractor can't use a swiss army knife to build your house -- a great phone with buttons beats out a big phone with a touch screen every day.
I'm happy to spend another $300+ on a nice durable quality phone with buttons, and a headset jack. Internet, I can take or leave.
Grocery stores are the supply chain from the farm to the city. It's certainly not more profitable for farmers to sell direct. Volume and scale certainly bring about stricter quality control, and more obvious failures.
When you build a building, anything from a house to a factory, to a subway tunnel, life support is always one of primary efforts -- in design priority, in timing, in cost. Ahead of temperature, and ahead of light, air quality is the number one concern. HVAC and ventilation in general is a huge issue in construction.
Now, given all of that, saying that living indoors is better than living in a cabin in the woods because air quality is of top concern is silly. Air quality needs to be a top concern because buildings ruin air quality where a cabin in the woods does not.
I'm willing to say that the same is true of FDA and grocery stores.
The reason that the farmer needn't meet any controls is because the farmer is selling you the carrot that you see. We all understand that they took it from the ground and handed it to you. It is unprocessed in every way. (pesticides are a nice little exception to that, but it's one that everyone understands and can therefore query at the point of sale) And because you're there, speaking to the farmer, you can ask any question that you like, and you can get any answer that exists. So really, you're eating the carrot the way the ground grew it -- for better or for worse.
But that carrot at walmart is very different. It went through many hands, many cities, many trucks, and there's no one that you can ask because the stock boy doesn't know. Hence, the FDA needs to get involved in order to protect the general (stupid) public from just assuming that anything sold is good -- it actually needs to be ensured to be good.
Intelligent design is an end-run argument. It's an attempt to get it all right the first time. Science improves over time, by always starting from a point of incorrect. Intelligent design works if you believe, only because you believe -- god protects you. Science works because you plan to be satisfied within the known margin-of-error -- this snake oil doesn't work 100% always, but it does work 90%, half the time.
But in the end, it really doesn't matter. Because when you look absolutely any situation, it becomes painfully obvious that there's a huge unknown, a huge risk, and you're the one who's going to be exposed to that danger. The only question is this: which unknown do you want risk?
You've presented the choice very clearly. I can choose to risk that the farmer didn't notice the bad carrot, or I can choose to risk that the FDA didn't notice the bad carrot. My personal heuristics say that the FDA is a set of rules, and people with day-jobs, such that a bad carrot has many ways to sneak through, whereas the farmer cares personally and I can see 90% of the carrot's life in front of me (no transportation by truck, no warehouse storage).
So what do I choose? I choose the third option. I get to know the farmer, and I get a tour of the greenhouse/fields, and I meet the people. I'm my own FDA as much as possible. I choose to rist that I didn't notice the bad carrot; because I know that I care personally.
That you don't see the scientific benefit, suggests that there is none.
You'll note the paradox inherent in the scientific method itself. Virtually everything that science has ever "proven" has itself disproven something that science had previously believed. So if science is forever getting better by fixing its mistakes, then it is forever making mistakes.
Police investigations work with a similar paradox: that evidence is required. A lack of evidence does not mean that I'm not a murdered. It is just as possible that I am a really good murdered (for various values of good).
So, for how long do you need to see no evidence that direct-from-farmers is scientifically better than via-walmart before you believe that there is no benefit? A day? A year? A life-time?
You can compare statistical data all you like, but you'll also need to evaluate the collection of that data, and any biases that it might have.
So I choose to say this: Patricia fed the chickens with carrots grown by Lisa, all on the same field, with no pesticides. I held the chicken (or could have). The chicken laid an egg. Patricia gave it to me, almost still warm. I buckled it into the passenger seat of my sportscar, and drove it home.
As a general heuristic, I can be certain that no trucks, no fuel fumes, no warehouses, no factories, knowing the names and where the farmers live (i.e. on the farm), is all a good thing when it comes to risking food poison. Everyone's invested, no one can just get-another-job, and everyone speaks the same language (except the chicken).
As another heuristic, I don't like the unknown. I don't know what happened to the egg-via-walmart, and I don't think you could find out for everything you eat there.
Slashdot Mirror
Tell me if I'm missing something here:
radio recording
cassette mix tapes
high-speed dubbing
VCR
BBS
FTP
DVD ripping
Napster
bittorrent
stream ripping
You'd think someone would notice just how much easier and faster it gets with each iteration.
Read even harder. Talking about serving pages to clients and caching -- all existed long before "the web".
Read harder. Never said "web".
I didn't say "web pages" either. I said pages. If one chooses to re-interpret my words to specifically make them incorrect, then I'm not able to correct them -- they'll just do so once more. This all exists with paper pages, data pages, memory pages, web pages, and every other type of page. For as long as caching has existed, it has been to reduce one resource at the expense of another. In this case, it's to reduce bandwidth at the expense of everything else -- hardware, processing, disk, performance, and speed.
Then you'll want to add input lag into that latency calculation. I'm using a colour-accurate medical imaging monitor. Takes another 100ms to go from mouse-to-monitor. Even more if I'm using a wireless mouse.
If you're a'gonna measure anything, you've got to me measuring cradle-to-grave, otherwise it's meaningless. So, if you're measuring the speed of the browser, to the user that is, then your only option is to measure click-to-read. That's the time the computer gets its very first input (the mouse click) to the time it sends the very first output (the first text/image of the page).
After three decades of personal and professional experience, I'm telling you that it's faster inline than disk-cached, every time (for reasonably-sized scripts, and reasonably-fast connections).
Of course it does. Look at the pure bandwidth capabilities. Most network cards can receive way faster than any HDDs, and most SSDs. Transmission and memory are, in principle, way faster than long-term permanent secure protected storage.
That's why we had music before records, and television before VCRs, and live sports broadcasts before instant replays. Storage is tough.
Read harder. The world didn't start with the web browser. You're an idiot.
Dell machines are usually designed to be quiet. That's why things are slow. But that's a different story.
You aren't working cradle-to-grave. hitting the local disk isn't about the disk speed. Those 15ms can be zero for this discussion. Similarly, the ping to the site of 125ms is meaningless. Here's what happens, cradle-to-grave:
Scenario 1, live streaming:
connect to site: 125 ms
download 200KB of html and javascript, compressed to 100KB, 1s
Scenario 2, external file:
connect to site: 125ms
download 100KB of html, compressed to 50KB, 1s
download 100KB of javascript, compressed to 50KB, 1s
Scenario 3, external file cached:
connect to site: 125ms
download 100KB of html, compressed to 50KB, 1s
wait for disk to be available, access disk for 100KB of javascript, wait for disk to spin up, 15ms
wait for virus scan, read cache meta data, determine that our cache file isn't already too old, 1s
HEAD the web-site file, to compare meta data, check to see that our cache is good enough, 1s
-- look at all of the side-work involved, and we're still hitting the site much of the time to check the cache anyway!
Scenario 4, external site
connect to site: 125ms
download 100KB of html, compressed to 50KB, 1s
connect to second site: 125ms
download 100KB of javascript, compressed to 50KB, 1s
Scenario 5, external site, cached
connect to site: 125ms
download 100KB of html, compressed to 50KB, 1s
wait for disk to be available, access disk for 100KB of javascript, wait for disk to spin up, 15ms
wait for virus scan, read cache meta data, determine that our cache file isn't already too old, 1s
connect to second site: 125ms
HEAD the web-site file, to compare meta data, check to see that our cache is good enough, 1s
-- now we have side work, a second connection, traffic everywhere
And all of this gets even worse when you realize that the connection to your primary site is keep-alived for your entire visit -- minutes at a time -- but to your secondary site, you're lucky to get a full second. Add all of the other hardware that you're using, in terms of disk, cpu, virus scanners. Now add the entire local permission system, cooling system, throttling systems, battery savers, and you're now conflicting with everything else running in the background.
Google doesn't care how long it takes your page to load. It doesn't know how important the page is, so it could never judge two pages based on size alone. What google very-much does care about is how long it takes your page to render "something". Put your scripts at the end of the file. Output your logo very quickly, before you do any real server-side work. I promise the top one inch of your web-site can be the very same all the time.
I said nothing about three decades with "the web". Read harder please.
You can get a device that is actually yours to control. If you've purchased something that's designed to screw you over, then you've got what you requested.
Read harder. I didn't say "browsers". I said "serving a page to a client". The world didn't begin with browsers. The web didn't start the internet. The internet wasn't the first network.
My first e-mail address had a comma in it, and token rings sucked for a lot of reasons. That's how long I've been developing web-sites.
But I didn't say I've been building web-site for three decades. I said, quite obviously, that I've been serving pages to clients for three decades.
You may be way too young to understand the difference between real-world practical and academic history, but the world wide web was not the start of the internet, the internet was not the start of networking, and networking was not the start of serving pages to clients.
Caching's been around for a very long time. If you want to learn about the benefits of caching, and the pitfalls, you want to look at archive caches, not transmission caches. When access involves an elevator, or a truck, you quickly learn what does and does not make sense.
Here's a perspective for you. When accessing a cache from a warehouse two miles away involves a truck, you get to consider the effects of rush hour traffic. So when your third-party server caches your javascript file, you get to consider that it isn't geographically in the same place as your primary server, meaning that not only does your client need to hit "another" server, with another connection, another keep-alive, and another set of caches, but it also needs to get there, through an ISP channel full of traffic. You've just doubled the amount of traffic globally. You can't ever bet on it being fast. You can only hope.
So, of course, you have a basement cache of your warehouse cache -- i.e. the disk cache. Elevators don't have traffic; or so you say. But the warehouse is full -- always, because that's what a warehouse is. So you get to search stacks and shelves and indexes. You get to have organizational training, and inventory days. Welcome to the magic of disk thrashing. The file table is incredibly slow in terms of file handles. Welcome to WAD files. Defragging is the inventory day, by the way.
So now you've got your reliable cache, that's only reliable under minimal load. Perfect. But some things get accessed often. So you keep a copy upstairs in the filing cabinet. But the filing cabinet is small. So you shuttle different cabinets up and down per day. Today you need the green cabinet. Tomorrow, the red. And life is good. Welcome to swap files -- memory to disk and back.
Now you've got employees shuttling cabinets, with dollies, and elevators, and warehouses, and trucks, and traffic. And here's the kicker. You haven't eaten yet! You've got a dozen staff, countless duplicate copies of files, trucks, buildings, elevators, desks. But you haven't done a lick of revenue-generating work yet.
Like I said, that's true for big huge amazon. It ain't true for 99% of web-sites out there, for whom bandwidth and server cycles are in excess supply.
Stop instructing your browser to block things. You don't need an add-on to define network connections. Start telling your network stack where to not find them:
HOSTS-level blocking
http://winhelp2002.mvps.org/ho...
And if that's not enough, look into PAC files. You won't be disappointed.
You're wrong. I've been doing this for three decades now. If you're serving a page to a client, sending them to a third-party to get the library always sucks. Even if they've already got the library disk-cached, it's actually slower to access the disk cache, and check the cache age, and verify that there isn't a newer library version (did you know the browser often goes round-trip just to check?) than it does to simply serve the library in-line.
Serving the library yourself can still run in parallel, and it often reuses the same primary connection, so it's about as fast as your server can handle.
Now you're going to mention the browser's memory cache, instead of disk cache. First, nowadays, with each-tab-in-a-separate-sandboxed-process, those memory caches ain't as fast as they once were. But even when they are, you just ain't a'gonna beat in-line scripts.
Benchmark it yourself. Serve 100KB of javascript in-line, in the middle of your html file. Compare that to a separate src= js file. Mid-stream, in an HTML file of another 100KB, the javascript runs at full download speed, with full text transmission compression. Those 100KB easily compress down to 50KB, more often 25KB, mid-transmission, and at any modern residential bandwidth, you're talking about the tiniest of fractions of a second. No disk access, no file handles, no separate rendering processes, no sandboxes, and, most importantly, no virus scanners, no swapping.
But it does eat up your server's bandwidth costs.
If you're huge, amazon style, then you want to off-load cycles and bits anywhere you can. If you're not huge, then the added 10% bandwidth costs mean nothing to you.
There's no sense to thinking that medicating something would make it better. In this case, like in all cases, medicating the issue only makes it less-worse. It'll always be a gradual decline. Headache pills don't make you superman. They reduce the headache 99%, they don't eliminate it, and they have side-effects.
There are loads of reasons for modern-day psychiatric problems. I'd bet that most of them surround being indoors -- lack of light, lack of exercise, lack of real-world animal problems, lack of proper fresh air, lack of visual distance, lack of colour, lack of contrast, lack of sun. I'd bet that the rest surround a lifestyle based on work -- lack of variety, high stress, mostly indoors, all-hours, lack of control.
So given that the solution is a change in lifestyle, and probably a change of environment, the medication is nothing more than a crutch. If you don't solve the problem, congrats-to-you, now you live with a crutch. Gradual decline.
I'm not updating my fridge. I'm not updating my router. I'm not updating my toothbrush. I'm not updating my toilet. Aside from real security items -- and by that I mean the security of my blood coarsing through my arteries (and some specific veins) I'm not creating more work for myself. It's that simple.
My car gets semi-annual maintenance service because it can kill me in a heartbeat if it breaks. Elevators, furnaces, hot-water tanks, swimming pools, attics; these are the kinds of things that can cause death or major illness if not maintained.
Beyond that, nobody cares if my phone slows down, and while I don't want anyone listening to my calls, I ain't a'gonna spend every waking moment fighting back.
It's that simple.
Once again, I sleep in my house, protected by a dead-bolt lock, on a metal front door, right next to a glass window. The back door is all-glass. Absolutely nothing stops anyone from killing me in my sleep.
Why would you take your expensive and important office where downtime is such a big issue, and put it alone in a field where it's easy to access? That's not smart. That's just plain dumb.
No lock will repel a sledge hammer; so what are you trying to do with it? Put something else into your shed-the-backyard. Put your office elsewhere.
My bet goes to pants. A bone would make wearing pants so very uncomfortable.
Doesn't sound like Uber would have any right to govern contractors. I guess it's settled. Employees all the way.
I can't believe we're sitting here, I'm 37 years old, and I'm finally getting stereo speakers. It's about time. I can't wait to turn 50, and get a headphone jack.
I still have a nokia phone -- my sixth in a row. Still with buttons. Best voice quality, small, light, not too-thin-to-hold. It's not my computer. It's my phone.
So, for all of those people who can't actually work on a phone -- because our work is bigger than a phone, in the same way that a general contractor can't use a swiss army knife to build your house -- a great phone with buttons beats out a big phone with a touch screen every day.
I'm happy to spend another $300+ on a nice durable quality phone with buttons, and a headset jack. Internet, I can take or leave.
I'm going to say the same thing backwards.
Grocery stores are the supply chain from the farm to the city. It's certainly not more profitable for farmers to sell direct. Volume and scale certainly bring about stricter quality control, and more obvious failures.
When you build a building, anything from a house to a factory, to a subway tunnel, life support is always one of primary efforts -- in design priority, in timing, in cost. Ahead of temperature, and ahead of light, air quality is the number one concern. HVAC and ventilation in general is a huge issue in construction.
Now, given all of that, saying that living indoors is better than living in a cabin in the woods because air quality is of top concern is silly. Air quality needs to be a top concern because buildings ruin air quality where a cabin in the woods does not.
I'm willing to say that the same is true of FDA and grocery stores.
The reason that the farmer needn't meet any controls is because the farmer is selling you the carrot that you see. We all understand that they took it from the ground and handed it to you. It is unprocessed in every way. (pesticides are a nice little exception to that, but it's one that everyone understands and can therefore query at the point of sale) And because you're there, speaking to the farmer, you can ask any question that you like, and you can get any answer that exists. So really, you're eating the carrot the way the ground grew it -- for better or for worse.
But that carrot at walmart is very different. It went through many hands, many cities, many trucks, and there's no one that you can ask because the stock boy doesn't know. Hence, the FDA needs to get involved in order to protect the general (stupid) public from just assuming that anything sold is good -- it actually needs to be ensured to be good.
Intelligent design is an end-run argument. It's an attempt to get it all right the first time. Science improves over time, by always starting from a point of incorrect. Intelligent design works if you believe, only because you believe -- god protects you. Science works because you plan to be satisfied within the known margin-of-error -- this snake oil doesn't work 100% always, but it does work 90%, half the time.
But in the end, it really doesn't matter. Because when you look absolutely any situation, it becomes painfully obvious that there's a huge unknown, a huge risk, and you're the one who's going to be exposed to that danger. The only question is this: which unknown do you want risk?
You've presented the choice very clearly. I can choose to risk that the farmer didn't notice the bad carrot, or I can choose to risk that the FDA didn't notice the bad carrot. My personal heuristics say that the FDA is a set of rules, and people with day-jobs, such that a bad carrot has many ways to sneak through, whereas the farmer cares personally and I can see 90% of the carrot's life in front of me (no transportation by truck, no warehouse storage).
So what do I choose? I choose the third option. I get to know the farmer, and I get a tour of the greenhouse/fields, and I meet the people. I'm my own FDA as much as possible. I choose to rist that I didn't notice the bad carrot; because I know that I care personally.
That you don't see the scientific benefit, suggests that there is none.
You'll note the paradox inherent in the scientific method itself. Virtually everything that science has ever "proven" has itself disproven something that science had previously believed. So if science is forever getting better by fixing its mistakes, then it is forever making mistakes.
Police investigations work with a similar paradox: that evidence is required. A lack of evidence does not mean that I'm not a murdered. It is just as possible that I am a really good murdered (for various values of good).
So, for how long do you need to see no evidence that direct-from-farmers is scientifically better than via-walmart before you believe that there is no benefit? A day? A year? A life-time?
You can compare statistical data all you like, but you'll also need to evaluate the collection of that data, and any biases that it might have.
So I choose to say this: Patricia fed the chickens with carrots grown by Lisa, all on the same field, with no pesticides. I held the chicken (or could have). The chicken laid an egg. Patricia gave it to me, almost still warm. I buckled it into the passenger seat of my sportscar, and drove it home.
As a general heuristic, I can be certain that no trucks, no fuel fumes, no warehouses, no factories, knowing the names and where the farmers live (i.e. on the farm), is all a good thing when it comes to risking food poison. Everyone's invested, no one can just get-another-job, and everyone speaks the same language (except the chicken).
As another heuristic, I don't like the unknown. I don't know what happened to the egg-via-walmart, and I don't think you could find out for everything you eat there.