Hopefully the world will get fed up with the United States' inaction and force a reduction in carbon emissions through economic embargo.
economic embargo... which would simply apply isolationism from outside, which would sharply stimulate the US economy. We have everything we need: almost incomprehensibly massive natural resources, a huge workforce, the ability to produce more food than we need, awesome transport infrastructure, a strong military, excellent communications, and an educational infrastructure that could easily be made to work in our favor with a few simple adjustments. What's holding our economy down right now is open trade; it was a huge mistake and it caused an immense amount of damage to our economy.
So go ahead. Apply an economic embargo. Your word of the day will be "backfire."
Agreed. That's because "scientifically-literate people" are smart, and want no part of a monumentally corrupt, deeply flawed, oath-breaking conspiracy possessed of massive inertia in precisely the wrong direction in every way that is possible. Instead, we get members of the political parties, or IOW equally corrupt types, or crazed fanatics who manage to get in there and actually make a terrible situation even worse.
No. The way to tell if someone is fighting is to check and see if the system has invested the effort to squash them. If not, they're having no effect, even if they *think* they're fighting.
You will not beat the establishment. Ever. It may beat itself out of sheer lumbering stupidity, with which it is copiously oversupplied, but you won't have had any hand in it. Not in the USA, in any case.
Call me cynical, but I'm just suspicious that people who get up and run around in the morning have a lower BMI because they get up and run around in the morning. The whole sunlight thing, that's just a coincidental (mis)feature of morning. By which I'm sure you can intuit my BMI range.:)
I have often remarked to my SO that the primary fault with mornings is that they don't wait until at least noon to begin.
You could write everything in assembly if you wanted to and with careful optimization you could probably produce faster code but it would take several orders of magnitude faster to do.
No. You can't do that unless the platform is locked down hardware wise, and that's not been the case with the major OS's for quite some time now. The best tool -- to date -- for anything serious aimed at a major OS is c. By far. Not C++. not objective c, not C#, not asm... just c.
due to NIH syndrome
No. That's not it at all. I don't care where it was invented; that's a symptom, not the actual problem. The problem is bringing in other people's code results in a loss of maintainability, quite often a loss of focus on the precise problem one is attempting to address, a loss of understanding of exactly what is going on, which in turn leads to other bugs and performance shortcomings. OPC comes into play at multiple levels: attempts to manage memory for you; libraries; canned packages of every type and "handy" language features that hide the details from you. NIH because it wasn't you just *looks* like the problem, but the problem is what NIH code actually does to the end result, and that's a real thing, not a matter of I don't like your style, or some personality syndrome. If the goal is the highest possible quality, then the job has to be fully understood and carefully crafted from components you can service from start to finish, the only exceptions being where it *must* interface with the host OS. Even then you're likely to get screwed. Need UDP ports to work right? Stay away from OSX. Need file dialogs to handle complex selections? MS's were broken for at least a decade straight. Need font routines that rotate consistently? Windows would give it to you various ways depending on the platform. And so on. Better off to write your own code if you can possibly manage it. You know, so it'll work, and if your customer finds an error, so you can fix it instead of punting it into Apple or MS's lap.
It boggles the mind that people *still* use the term "bloated" simply because they are utilizing frameworks that might not be limited to just the exact set of things you need
I use "bloated" when my version of something is 1 mb, and a friend's, with fewer lines of code, is 50 mb and runs the target functionality at a fraction of the speed, not to mention loading differences and startup differences. It's not just about a library routine that isn't called (well, until there are a lot of them, or if they're very large... linkers really ought to toss those out anyway), it's primarily about waste in every function call, clumsy memory management that tries to be everything to everybody and ends up causing hiccups and brain farts at random times, libraries that bring in other libraries that bring in other libraries until you've got a house of a thousand bricks, where you only actually laid a few of them, and you have *no idea* of the integrity of the remaining structure. Code like that is largely out of your control. Bloated. Unmaintainable. Opaque. Unfriendly to concurrently running tasks.
Look at your average iOS application. 20 megs. 50 megs. Or more. For the most simpleminded shite you ever saw; could have been implemented in 32k of good code and (maybe) a couple megs of image objects. That's what I'm talking about, right there. Bloat. It's that zone where a craft is swamped by clumsy apprentices who think they understand a lot more than they do. Where one fellow creates beautiful, strong, custom furniture, and the other guy buys a 59.95 box from IKEA and turns a few cams. The good news is that there will always be a place for those who can really craft, because there's a never-ending source of challenges where crap just won't do. And despite rumors to the contrary, end users do know the difference -- especially once they've been exposed to both sides of the coin.
Memory and CPU power are there to be used so why not take advantage of it
1) if my app is careful with memory, you have more left to do other things with, and there's less swapping, etc.
2) if my app is 10x faster than yours (and it probably is at least that), I *am* taking advantage of the CPU, in fact, better than you are.
And what the hell is a hand coded app?
It's an app where you write the code, instead of bringing in a bunch of black boxes. So that A, you can control exactly what is going on, and B, you can fix any bug that arises without having to go to whomever (Apple, MS, Some Random Dude) and beg them to fix their black box. It takes more time to write -- a lot more -- but it results in a much higher quality, easier to maintain software product.
And what does eschewing OO approaches mean?
It means just what it says. No black boxes. No compilers that build in overhead with every call and every method, basically nothing that will turn what should be a megabyte of clean code into 100 mb of utter dreck.
I'm not talking about objects in the sense of (for instance) a structure containing slots for various methods appropriate to the concept that the structure implements; that kind of "object" has been around since prehistoric days. I used to code like that in ASM for the 6809. I'm talking about HLL cruft, basically.
Are you talking about an application that encapsulates all it's functionalities without referencing any external resources or dependencies?
As much as is possible to do so, yes. It's the difference between crafting something of your own, something you can service at any level, and something built from Other People's Code, often code you have no control over and/or no knowledge of how it actually works.
AFAIC, someone is capable of real programming when they can write anything they need. And when you can, you should. Because it results in higher quality, more maintainable, faster, leaner products.
You can stop pretending that our multicore processors with 64 gigs of ram can't handle them.
...and perhaps you can stop pretending that HLL bloatware has anywhere near the performance of hand coded apps *on the same CPU*. It has nothing to do with GUI's per se, either. It's about frameworks with years and years of bloat, slow code in black boxes that can't be sped up (or often even bugfixed, as we have sadly come to learn), about ridiculous amounts of memory getting chewed up by library after library, about swapping instead of careful memory use... please don't pretend that faster CPUs have addressed the performance issues of higher (and higher) level approaches. The bottom line is still that well crafted apps that eschew OO approaches will almost always outperform for both memory use and speed, given the same environment to run in.
They're a good bit lower than the fenders, so the view to the rear would be obstructed, barring a very tall mount. Integrated to the fender seems like the way to go for one of those.
That's it - you travel 1.4 feet in the time it takes for a complete display redraw if you're going 60 mph.
At 120 mph, you travel 2.8 feet in the same time.
Further, if you're dealing with a vehicle approaching you from the rear or side, the speed isn't the road speed (say, 60 mph), the speed is the delta between your two speeds. IOW, if you are going 60, and a vehicle is approaching you from the rear at 65, the delta is only 5 mph, and so the distance travelled during a complete screen redisplay is *much* less than 1.4 feet. If the approach is from the side, it's the rate of sideways closure vectorially added to the |delta| between your forward speeds.
Don't think it's significant in real world terms, so cameras/monitors are fine WRT this issue.
Human reaction time for *reflex* is about 30 ms. Considered complex reaction time is far longer (and unless you're a pro driver, almost everything you do is almost certain to be considered, not reflex.). Video (NTSC, non-interlace) frame rates are ~16 ms. HD progressive scans are similar, ~16 ms. There's nothing stopping anyone from going to higher frame rates, either. Well within mundane tech bounds.
Modern camera AGC covers from bright sunlight to ~1 lux night vision, far better and faster than your eye can do it. There is a dynamic range issue, but that's largely not relevant to driving conditions. The human eye's dynamic range isn't all that great without iris involvement, and suffers from slow recovery overload when large changes are encountered -- cameras can do much better. They can also mute headlight glare so that it doesn't affect your vision at all, which your naked eye will react to in a mirror by stopping down and limiting you to daylight equivalent ranges when it's actually pitch dark out.
Finally, if you are performing maneuvers that go from safe to unsafe in critical 16 ms increments, you'd better be a pro driver on a racetrack -- and you're probably going to crash anyway, because your reaction time is considerably longer -- about double that. Not even counting the time it takes to focus your attention on the mirror/monitor from the main road picture.
They make monitors in the rearview mirror form factor that are specifically designed to replace the rear view mirror. You *really* don't want to have to look down to see behind you. You need at least your peripheral vision on the road at all times you are in motion.
I've also seen custom cars with the monitor embedded in the hood, under heated plex. It's an interesting idea, but has some drawbacks. Earlier yet, some cars had gauges there like this one. It's pretty common in custom work.
The pan/tilt is not supposed to be used while driving.
It would be trivial to disable pan/tilt when in gear or in motion; they don't, ergo, they are *designed* to be used while driving. Further, there are very good reasons to do so, for instance when some idiot is gifting you from behind with high beams right in your eyes, a quick pan down solves the problem. Because while it may be inconvenient to lose the mirror image, it's far worse to be blinded. Another reason for adjustment is when changing from multilane to single lane roads; the best drivers use side mirrors differently in those two cases. Another reason is coming up an on-ramp into traffic at an angle; if the driver's side mirror is adjusted at that time, you can get a clear view of what's coming up in the merge lane. If you don't make that adjustment, you will see little or none of that until it's too late to be of use. But as soon as you have completed the merge, the mirror should be re-adjusted -- while you are driving.
The fact that you drive your bike in traffic indicates you are insensitive to safety issues in the first place. Bicycles do not belong in traffic. Ever. You don't have the acceleration to go with the flow. You are one steering wheel or brake or accelerator twitch from being crushed any time you are near the much heavier vehicles. You are vulnerable to sudden and complete vision loss from splashes, much more so than a car or truck, and once that happens, again unlike a car or truck, you have zero protection from the vehicles you can no longer see. And so on.
Until or unless your region implements dedicated bicycle paths that don't intersect vehicular traffic-ways -- and you use them -- you're playing Russian roulette.
Those include all the cables and mounts you need. So for about $45.00, you're up and running. I can't imagine a sideview camera would be any more expensive than a rearview. If you broke the mount off, that's bodywork, but hey, don't do that.:)
The monitor can automatically dim to compensate for ambient lighting conditions.
Furthermore, it can keep headlights behind you from blowing your night vision using dynamic range control.
I have two monitors in the cab of my truck -- one is a GPS and the other is for the cameras; both monitors dim based on ambient light. It's not exactly a high tech thing. And the IR view at night is spectacular (high IR... not heat detection, just IR LED illumination to which the camera is very sensitive.) I have never found my night vision to be compromised; quite the contrary.
You don't even need stitching. Use a lens that captures extreme wide field, then geometrically correct that to be linear. One hires camera, one lens, no panning or multiple sources required.
My current backup camera (aftermarket add on to a 2002 Avalanche) is wide angle, and when I'm close to something like a car behind me, the distortion is profound. I'd be a lot happier if that was corrected.
I do some other camera tricks -- exit from my property involves blindly backing out into an alleyway through a gated fence. I have a small building which has one wall parallel to the alleyway and another parallel to the driveway, so I mounted cameras pointing up and down the alley under the eaves, combined their live output into a left-right presentation, then transmit that at the corner of the building. Then inside the truck, I have a remote receiver which feeds one of the monitor inputs, and so when I get near the building (within about 30 feet), my backup camera (almost entirely useless at this time because it points across the alley instead of up and down it) automatically switches to overlapping views up and down the alleyway. This prevents some clown from fogging down the alleyway and t-boning us as we pull out. I always turn on my 4-ways when I back out too... I figure that's about as good as it's going to get.
Also, whoever decided to auto-play audio on Slashdot should be fired from a cannon that was loaded with 3-inch nails, and then with them, into a brick wall.
Slashdot Mirror
economic embargo... which would simply apply isolationism from outside, which would sharply stimulate the US economy. We have everything we need: almost incomprehensibly massive natural resources, a huge workforce, the ability to produce more food than we need, awesome transport infrastructure, a strong military, excellent communications, and an educational infrastructure that could easily be made to work in our favor with a few simple adjustments. What's holding our economy down right now is open trade; it was a huge mistake and it caused an immense amount of damage to our economy.
So go ahead. Apply an economic embargo. Your word of the day will be "backfire."
Agreed. That's because "scientifically-literate people" are smart, and want no part of a monumentally corrupt, deeply flawed, oath-breaking conspiracy possessed of massive inertia in precisely the wrong direction in every way that is possible. Instead, we get members of the political parties, or IOW equally corrupt types, or crazed fanatics who manage to get in there and actually make a terrible situation even worse.
No. The way to tell if someone is fighting is to check and see if the system has invested the effort to squash them. If not, they're having no effect, even if they *think* they're fighting.
You will not beat the establishment. Ever. It may beat itself out of sheer lumbering stupidity, with which it is copiously oversupplied, but you won't have had any hand in it. Not in the USA, in any case.
No. This is just what I expect; all the evidence points this way on every other subject, why not on science as well?
Call me cynical, but I'm just suspicious that people who get up and run around in the morning have a lower BMI because they get up and run around in the morning. The whole sunlight thing, that's just a coincidental (mis)feature of morning. By which I'm sure you can intuit my BMI range. :)
I have often remarked to my SO that the primary fault with mornings is that they don't wait until at least noon to begin.
No. You can't do that unless the platform is locked down hardware wise, and that's not been the case with the major OS's for quite some time now. The best tool -- to date -- for anything serious aimed at a major OS is c. By far. Not C++. not objective c, not C#, not asm ... just c.
No. That's not it at all. I don't care where it was invented; that's a symptom, not the actual problem. The problem is bringing in other people's code results in a loss of maintainability, quite often a loss of focus on the precise problem one is attempting to address, a loss of understanding of exactly what is going on, which in turn leads to other bugs and performance shortcomings. OPC comes into play at multiple levels: attempts to manage memory for you; libraries; canned packages of every type and "handy" language features that hide the details from you. NIH because it wasn't you just *looks* like the problem, but the problem is what NIH code actually does to the end result, and that's a real thing, not a matter of I don't like your style, or some personality syndrome. If the goal is the highest possible quality, then the job has to be fully understood and carefully crafted from components you can service from start to finish, the only exceptions being where it *must* interface with the host OS. Even then you're likely to get screwed. Need UDP ports to work right? Stay away from OSX. Need file dialogs to handle complex selections? MS's were broken for at least a decade straight. Need font routines that rotate consistently? Windows would give it to you various ways depending on the platform. And so on. Better off to write your own code if you can possibly manage it. You know, so it'll work, and if your customer finds an error, so you can fix it instead of punting it into Apple or MS's lap.
I use "bloated" when my version of something is 1 mb, and a friend's, with fewer lines of code, is 50 mb and runs the target functionality at a fraction of the speed, not to mention loading differences and startup differences. It's not just about a library routine that isn't called (well, until there are a lot of them, or if they're very large... linkers really ought to toss those out anyway), it's primarily about waste in every function call, clumsy memory management that tries to be everything to everybody and ends up causing hiccups and brain farts at random times, libraries that bring in other libraries that bring in other libraries until you've got a house of a thousand bricks, where you only actually laid a few of them, and you have *no idea* of the integrity of the remaining structure. Code like that is largely out of your control. Bloated. Unmaintainable. Opaque. Unfriendly to concurrently running tasks.
Look at your average iOS application. 20 megs. 50 megs. Or more. For the most simpleminded shite you ever saw; could have been implemented in 32k of good code and (maybe) a couple megs of image objects. That's what I'm talking about, right there. Bloat. It's that zone where a craft is swamped by clumsy apprentices who think they understand a lot more than they do. Where one fellow creates beautiful, strong, custom furniture, and the other guy buys a 59.95 box from IKEA and turns a few cams. The good news is that there will always be a place for those who can really craft, because there's a never-ending source of challenges where crap just won't do. And despite rumors to the contrary, end users do know the difference -- especially once they've been exposed to both sides of the coin.
1) if my app is careful with memory, you have more left to do other things with, and there's less swapping, etc.
2) if my app is 10x faster than yours (and it probably is at least that), I *am* taking advantage of the CPU, in fact, better than you are.
It's an app where you write the code, instead of bringing in a bunch of black boxes. So that A, you can control exactly what is going on, and B, you can fix any bug that arises without having to go to whomever (Apple, MS, Some Random Dude) and beg them to fix their black box. It takes more time to write -- a lot more -- but it results in a much higher quality, easier to maintain software product.
It means just what it says. No black boxes. No compilers that build in overhead with every call and every method, basically nothing that will turn what should be a megabyte of clean code into 100 mb of utter dreck.
I'm not talking about objects in the sense of (for instance) a structure containing slots for various methods appropriate to the concept that the structure implements; that kind of "object" has been around since prehistoric days. I used to code like that in ASM for the 6809. I'm talking about HLL cruft, basically.
As much as is possible to do so, yes. It's the difference between crafting something of your own, something you can service at any level, and something built from Other People's Code, often code you have no control over and/or no knowledge of how it actually works.
AFAIC, someone is capable of real programming when they can write anything they need. And when you can, you should. Because it results in higher quality, more maintainable, faster, leaner products.
nah, I just run into stuff. :)
Exactly.
They're a good bit lower than the fenders, so the view to the rear would be obstructed, barring a very tall mount. Integrated to the fender seems like the way to go for one of those.
60 mi/h = 5280 feet * 60 = 316800 ft/h
316800 / 3600 = 88 ft/second
88 * .016 = 1.408 ft
That's it - you travel 1.4 feet in the time it takes for a complete display redraw if you're going 60 mph.
At 120 mph, you travel 2.8 feet in the same time.
Further, if you're dealing with a vehicle approaching you from the rear or side, the speed isn't the road speed (say, 60 mph), the speed is the delta between your two speeds. IOW, if you are going 60, and a vehicle is approaching you from the rear at 65, the delta is only 5 mph, and so the distance travelled during a complete screen redisplay is *much* less than 1.4 feet. If the approach is from the side, it's the rate of sideways closure vectorially added to the |delta| between your forward speeds.
Don't think it's significant in real world terms, so cameras/monitors are fine WRT this issue.
Human reaction time for *reflex* is about 30 ms. Considered complex reaction time is far longer (and unless you're a pro driver, almost everything you do is almost certain to be considered, not reflex.). Video (NTSC, non-interlace) frame rates are ~16 ms. HD progressive scans are similar, ~16 ms. There's nothing stopping anyone from going to higher frame rates, either. Well within mundane tech bounds.
Modern camera AGC covers from bright sunlight to ~1 lux night vision, far better and faster than your eye can do it. There is a dynamic range issue, but that's largely not relevant to driving conditions. The human eye's dynamic range isn't all that great without iris involvement, and suffers from slow recovery overload when large changes are encountered -- cameras can do much better. They can also mute headlight glare so that it doesn't affect your vision at all, which your naked eye will react to in a mirror by stopping down and limiting you to daylight equivalent ranges when it's actually pitch dark out.
Finally, if you are performing maneuvers that go from safe to unsafe in critical 16 ms increments, you'd better be a pro driver on a racetrack -- and you're probably going to crash anyway, because your reaction time is considerably longer -- about double that. Not even counting the time it takes to focus your attention on the mirror/monitor from the main road picture.
I only have one usable eye, you insensitive clod
They make monitors in the rearview mirror form factor that are specifically designed to replace the rear view mirror. You *really* don't want to have to look down to see behind you. You need at least your peripheral vision on the road at all times you are in motion.
I've also seen custom cars with the monitor embedded in the hood, under heated plex. It's an interesting idea, but has some drawbacks. Earlier yet, some cars had gauges there like this one. It's pretty common in custom work.
It would be trivial to disable pan/tilt when in gear or in motion; they don't, ergo, they are *designed* to be used while driving. Further, there are very good reasons to do so, for instance when some idiot is gifting you from behind with high beams right in your eyes, a quick pan down solves the problem. Because while it may be inconvenient to lose the mirror image, it's far worse to be blinded. Another reason for adjustment is when changing from multilane to single lane roads; the best drivers use side mirrors differently in those two cases. Another reason is coming up an on-ramp into traffic at an angle; if the driver's side mirror is adjusted at that time, you can get a clear view of what's coming up in the merge lane. If you don't make that adjustment, you will see little or none of that until it's too late to be of use. But as soon as you have completed the merge, the mirror should be re-adjusted -- while you are driving.
Here's one that does both.
Although those front semi-fenders would make awesome camera mount points.
The fact that you drive your bike in traffic indicates you are insensitive to safety issues in the first place. Bicycles do not belong in traffic. Ever. You don't have the acceleration to go with the flow. You are one steering wheel or brake or accelerator twitch from being crushed any time you are near the much heavier vehicles. You are vulnerable to sudden and complete vision loss from splashes, much more so than a car or truck, and once that happens, again unlike a car or truck, you have zero protection from the vehicles you can no longer see. And so on.
Until or unless your region implements dedicated bicycle paths that don't intersect vehicular traffic-ways -- and you use them -- you're playing Russian roulette.
IR/color backup camera w/distance projection: $14.09
Monitor: $31.64
Those include all the cables and mounts you need. So for about $45.00, you're up and running. I can't imagine a sideview camera would be any more expensive than a rearview. If you broke the mount off, that's bodywork, but hey, don't do that. :)
The monitor can automatically dim to compensate for ambient lighting conditions.
Furthermore, it can keep headlights behind you from blowing your night vision using dynamic range control.
I have two monitors in the cab of my truck -- one is a GPS and the other is for the cameras; both monitors dim based on ambient light. It's not exactly a high tech thing. And the IR view at night is spectacular (high IR... not heat detection, just IR LED illumination to which the camera is very sensitive.) I have never found my night vision to be compromised; quite the contrary.
So, you're one of those conventional types with the driver's seat mounted so you face forward? Lame.
I only have one usable eye, you insensitive clod.
You don't even need stitching. Use a lens that captures extreme wide field, then geometrically correct that to be linear. One hires camera, one lens, no panning or multiple sources required.
My current backup camera (aftermarket add on to a 2002 Avalanche) is wide angle, and when I'm close to something like a car behind me, the distortion is profound. I'd be a lot happier if that was corrected.
I do some other camera tricks -- exit from my property involves blindly backing out into an alleyway through a gated fence. I have a small building which has one wall parallel to the alleyway and another parallel to the driveway, so I mounted cameras pointing up and down the alley under the eaves, combined their live output into a left-right presentation, then transmit that at the corner of the building. Then inside the truck, I have a remote receiver which feeds one of the monitor inputs, and so when I get near the building (within about 30 feet), my backup camera (almost entirely useless at this time because it points across the alley instead of up and down it) automatically switches to overlapping views up and down the alleyway. This prevents some clown from fogging down the alleyway and t-boning us as we pull out. I always turn on my 4-ways when I back out too... I figure that's about as good as it's going to get.
FTFY
Enabled: Have you missed the part where no one ever is held responsible?