They don't cost the COMPANY anything, however, they do reduce the value of the shares. THAT isn't the company's problem, but the investors.
A company can decide to offer some large block of shares to another company, to take as an investment (we'll take $300M, for these 10M shares, etc.) The shareholders often welcome things like this. The extra cash generated allows the company to invest in new development. It dilutes the value of each share, but the gamble is that the final worth of each share will be more after the future value (from the new development's results) is diluted.
So, a temporary reduciton in share-value (but not company value, the company is still worth the same (if not more, as it now has more cash), for a future increase in share-value (due to being able to bring new products to market, etc.)
Buy-back programs ARE expenses, and those need to be reported as such. So at that time, yes, it would become an expense. Until then, ISO shares are an income to the company (new investment into it).
Your confusing shorting a stock with Incentive Stock Options. With Incentive Stock Options, shares are essentially reserved for the employee, at the current price, for a period of time. If the employee decides to buy those shares, he does so at the price they were worth on the day they were issued (that the ISO was issued, not the exercise). So, effectively, the employee has purchased shares at some point in the past, and can now sell them at the market price (which is always higher than the strike price, and preferrably significantly so).
There is no liability to the company. These are new shares, and the employee does pay for them. Often the employee exercises and sells on the same day. The effect result being that the company has put some new number of shares onto the market, and splits the income of that with the employee. The company keeps the strike-price, and the difference is kept by the employee.
This causes a bit of dilution, but that is something that a good investor can be on the lookout for, and if companies were to be very frank with what ISO shares are outstanding, could use to determine what the possible dilution of a stock would be at any given market price.
No, at the time of issuance, they have no net value. They are issued at market close price on the day of issuance.
Stock is at $10/share, and my strike-price is $10/share. ie, they have no value. If the shares go UP in value, then I have options that are worth something. Otherwise, they aren't worth anything at all.
I have options at my current company that are for shares at $32/share. Market today was roughtly $10.50/share. Those are worthless options at the current price.
Options are options to buy at a price, not a GRANT of shares, which is when the company hands you shares (at no cost to you). THAT *DOES* have a value, but that's not what's being dicussed here.
But exercising has an immediate effect on the published "state" of the company. Options have a potention future dilution of the stock price, depending on the future stock price, and what people decide to do with their options.
However, publishing the outstanding options, their strike prices, vesting schedules, etc, will allow a long-term investor to see what the risks are from dilution.
Now, that will protect the investor from the employee, but the real worry isn't the employee, but upper management (who get a lions-share of hte total number of option shares).
They need to be held responsible (personally) for tactics such as running a company into the ground for a short-term surge in stock prices that net them a great deal of income. That needs to be the problem.
But a given mgmt type will only get away with it once, but if they do ir right, they only need to. Then they've got more than enough money.
But no-one should go into long-term investment with a company without getting a very good feel for it's managment and it's employees, and it's market. It's called Due Dilligence, and a lack of doing so will get you burned, badly.
Actually, options have no value when given. None. Usually, they are worthless for at least a year, at which they start vesting (this does vary from company to company).
After that point, they *might* have a value. But that's unknown.
That's why they shouldn't be expensed. A company could issue options during a high time in the market, get reamed for the "expense", and then the market goes down, the options are worthless, and the company's EPS was crap, yet the company always had more than enough earnings.
If you're worried about the dilution of the company you're investing in, then the number of shares outstanding at each strike price, and the date of issuance, vesting schedule, and expiration should all be documented. Then you can see that the price now is $20. There are a large pool of options at $21. If the price rises to $25, that pool might get exercised, and thereby reduce the value of each share by a portion, but dilution is rarely any large amount. If you have 50,000,000 shares on the market, and options for another 1M shares at $21, and those get exercised when the stock goes up to $25, then the value at that price per share, assuming the same market cap, will be about 2% less than otherwise.
But an investor can take this into account. A short-term investor doesn't care about dilution, he's not in the company long enough to do so. A longer term investor does worry, and should do that kind of due dilligence. Anything else is just being a bad investor.
"ooh!! They make internet products! BUYBUYBUYBUY!!" gah,,, stupid gits...
However, if what you're looking at IS 3D data, like as someone mentioned, automotive parts, then you do get a benefit from just DL'ing the model, and rendering it.
My laptop can easily push 1200fps with GLX gears, which is be no means a complex demo, but that implies that it can handle 40x as many triangles/sec, and still provide very good animation capabilities. That IS a benefit.
And while most meshes are complex, re-used objects only need to be dealt with once. A good scene description language would allow the definition once, maybe with controls for variations, and then be able to spit out copies in memory at very high speed.
If you've got the rendering power to handle the triangles, then you don't need the textures, which are usually (in my experience) used as a crutch to lower the polygon count at the sacrifice of more memory. Frankly, I'd rather see more, simpler textures, and a LOT more polygons, and let the hardware do the work.
New hardware is downright amazing in what it can push.
Visualization and interaction are definitley the key to making 3d work. I think we've got the bandwidth. triangles just aren't that big, a handful of bytes per.
Compression techniques like this may help, but only in cases where the base mesh is VERY complex, and has lots of redundant triangles. And the position of the viewer either has to be discarded, or the compression has to be fast so that it can be done server-side for each client (or at least done in blocks such that different compressed mesh copies are made ahead of time, and hte user switches meshes every so often, to bring far-away, compressed-out detail into more detail.
I think my modem can handle a fairly simple bit of streamed triangle data, say 350 triangles/sec, more with compression (at the PPP level, where I do get a fair bit with easily compressible data (seen 8KBps over a 26Kbps downlink with text).
But DSL/Cable should be able to download enormous amounts of data. And a GOOD client/server protocol for downloading objects at a time, instead of scenes at a time could allow for a very http/web-browsing method.
Load the "ground" and "sky" first, or in chunks, radially outward from the user, only in the hemisphere in which they can see, and then start DL'ing objects one at a time, again, having the client start with the base model, and maybe bounding boxes, and computing what objects are of interest to it. It can be displaying continually as it downloads, too. Just like images. I think people are very used to this with web pages.
But then, display of data within that "world", and the manipulation of that world is going to just suck for a while. A good 3D UI is going to be even more difficult to design than a good 2D one, as they are harder than a good console app. At least, that's my impression of things.
Then of course, the MFCs of the 3D world will try to turn everything into a homongenous mismash, and you won't be able to tell at a glance what you're dealing with.
I'd love to get into OpenGL programming for stuff like this, and try to get it working on lower-end hardware, like a old Indigo. Aim for that baseline, and then throw it only the new stuff from ATI and nVidia, and it should be smooth as silk for display/interaction. Bandwidth is still an issue, but that mainly affects what level of detail you'd want to DL in the first place.
I can definitely see this looking like it came out of snow-crash...:)
On my 2000 Dodge Ram 1500 (pickup truck), if you cycle the key in the sequence ON - OFF - ON - OFF - ON, the digital odometer will spit out the codes, one after the other, and then read "p done", and switch back to the odometer. (just don't put the key into START).
Disconnect the batter for 5-15 minutes, and all the codes are cleared from memory.
Oh, and a magnetic reed switch could be used in the gas-cap area. Most reeds are sealed inside a small glass tube.
Stored in volatile memory. Disconnect the batter for 15 minutes, and the codes are all cleared.
Some codes DO get stuffed into permanent storage, though. Depends on the car. But not many. Usually the ones that require a trip to the dealer (ie, the "change oil light" on some bmws were like this. YOu had to use a "special tool" (aka, paperclip), to reset the oil-change logic by inserting it in a hole in the dash)
Actually, the reason is demand. The manual transmissions available in light trucks tend to fall into two categories, the ultra-light-duty one that's coupled with the most-base engine available, and the ultra-heavy-duty one that's for use with the monster diesel that's used by people who actually need to tow.
The small manual transmission is either unpopular, or not strong enough for the middle of the road engines that are most popular (ie, the big V8s).
The small manual is probably tuned for a V6, and the big manual is designed for a big turbo-diesel.
AFAIK, you can't buy a 1/2-ton pickup in the US with a big V8 and a manual. No one wants them.
I just know that after owning a 5000 lb, 1/2-ton rated 4x4 pickup with a vig v8, and a slushbox (automatic transmission), I'm not owning another. Next truck will be diesel and a manual.
Not for the massive towing capacity, but for the doubled milage of the diesel, and the greater durability and control of the manual (plus it's just more fun in the hills to have a manual).
If any of the big 3 came out with a quality inline-6, 4 liter (or so) turbo diesel for use in 1/2 tons and smaller trucks, they'd sell like hotcakes. Especially with the current fuel prices, the MUCH greater mileage, and the new common-rail injection that makes even the big engines (the 5.9L Cummins, for instance) VERY quiet.
I realized the punny potential, but decided to leave it. Guess the computer can *internally* clean itself up, but the exterior's gonna still be left to the user.
No, it's not too harsh. Suspend their service, send them a note saying that they've been compromised, and they need to clean up their PCs.
Restrict their accounts to only allow port 80 to known good spyware/malware cleanup vendors, and go from there. AdAware + SpyBotSD + Symantec (Corp Edition) seals up a box nicely, or at least cleans it up temporarily.
I've been slowly teaching the other firefighters in my volunteer fire dept, and they're learning. They're not the most computer literate, but you give them a few links, and they can download what they need, and go back to viewing pr0n with less worries than before, or can at least clean up the computer afterwards...
I've been looking more and more at the EPIAs, and the mini-ITX stuff. My home boxes are likely to start being of two flavors either a silent, air-cooled "appliances" running an EPIA or similar, in a smallish, durable case. Or a full-blown workstation designed for doing workstation things (development, graphics processing (ie, digital camera), mp3/mpeg encode/rip, etc.). Although that workstation sure would be nice if it was in the form of a durable laptop...
Same here. But the problem is then people write thier apps for that more computing power, and it just seems to get wasted.
Most current-day coders don't seem understand the word optimize very well.
And I'm not talking in-lining assembly, or using C vs. an interpreted language, I'm talking about really stupid algorithms that are slow in any language.
I'm a software developer (C++, mostly msdev). As such, I recompile a LOT. With a drive dedicated to mostly source and intermediate files, about 6GB of a 9GB drive, it regularly fragments itself into molasses. It normally takes a while, but it happens. The continual replacement of files just dries NTFS up a wall. This is using both win2k and xp. I end up needed to defrag about once a month.
The problem really rears it's head once the space between the files isn't big enough for the new files, and then things start getting fragmented in a hurry.
And does it make a difference? In disk-intensive things like compiling (lots of small modules that get compiled into big binaries/debug symbol files), it really has an impact. The more the heads have to move around, the slower it all gets.
I also use lots of partitions to isolate things, so that even as it fragments, the fragments don't get too far apart. However, if you do a lot of swapping to disk, the partitions will kill you, unless the swap is on the same partition as where you're working. So I tend to foist the swap off on another drive entirely (all SCSI) so that the seeking is reduced as much as possible.
Placebo? probably is for most people that aren't continually writing/rewriting to disk. But if you're constantly reading/writing/erasing files, it is useful.
Now if I could just figure out a way to safely split up my root filesystem on linux to keep the heavily used trees separate from the not-so-heavily used ones (performance experiment). Mainly my/var/tmp/*, which gets used heavily for compiling (gentoo and portage).
Yeah, the heavy hydraulic cutters go right through them, if you can get an edge between the jaws to start with.
We actually don't have drills with us (haven't needed them). And in the time to drill, and mess with a potentially heavily compressed window, I can just pull the doors off. It's really quite easy, with the right tools, and the right placement.
Squeeze a little here, little there, then stick the tips of the spreaders in, and open wide. VERY fast once you've done it a couple times.
Actually, older cars were bricks that just transfered the energy directly to the interior (think billiard balls).
Newer cars have "crush zones", and a prime example is the Mini. Head-first into an immovable object and it crumples away, slowing the car gradually, as the front of the car crushes.
The trick is getting it just right. To soft, and you crush the occupants. Too hard, and it's not useful.
They've been slowly getting there over the years.
The focus of the manufacturers IS actually major impacts, and not small impacts. The car is meant to be totalled with as little damage to the occupants as possible.
I've seen several head-on into trees that totalled the car, and the driver walked away without a scratch. An impact that in an older car (or a full-size truck) could have seriously injured the people inside.
They don't cost the COMPANY anything, however, they do reduce the value of the shares. THAT isn't the company's problem, but the investors.
A company can decide to offer some large block of shares to another company, to take as an investment (we'll take $300M, for these 10M shares, etc.) The shareholders often welcome things like this. The extra cash generated allows the company to invest in new development. It dilutes the value of each share, but the gamble is that the final worth of each share will be more after the future value (from the new development's results) is diluted.
So, a temporary reduciton in share-value (but not company value, the company is still worth the same (if not more, as it now has more cash), for a future increase in share-value (due to being able to bring new products to market, etc.)
Buy-back programs ARE expenses, and those need to be reported as such. So at that time, yes, it would become an expense. Until then, ISO shares are an income to the company (new investment into it).
But it's NOT an expense. The company RECEIVES money from ISO options. These aren't call options, or selling-short.
These are new shares on the market, sold to the employee by the company at a reduced price, and then the employee sells them on the market.
How is this an expense? When does the company spend money?
The link you provided has NOTHING to do with ISO options that are under discussion here.
Your confusing shorting a stock with Incentive Stock Options. With Incentive Stock Options, shares are essentially reserved for the employee, at the current price, for a period of time. If the employee decides to buy those shares, he does so at the price they were worth on the day they were issued (that the ISO was issued, not the exercise). So, effectively, the employee has purchased shares at some point in the past, and can now sell them at the market price (which is always higher than the strike price, and preferrably significantly so).
There is no liability to the company. These are new shares, and the employee does pay for them. Often the employee exercises and sells on the same day. The effect result being that the company has put some new number of shares onto the market, and splits the income of that with the employee. The company keeps the strike-price, and the difference is kept by the employee.
This causes a bit of dilution, but that is something that a good investor can be on the lookout for, and if companies were to be very frank with what ISO shares are outstanding, could use to determine what the possible dilution of a stock would be at any given market price.
Good question.
Are all compensations expenses?
I don't think so.
No, at the time of issuance, they have no net value. They are issued at market close price on the day of issuance.
Stock is at $10/share, and my strike-price is $10/share. ie, they have no value. If the shares go UP in value, then I have options that are worth something. Otherwise, they aren't worth anything at all.
I have options at my current company that are for shares at $32/share. Market today was roughtly $10.50/share. Those are worthless options at the current price.
Options are options to buy at a price, not a GRANT of shares, which is when the company hands you shares (at no cost to you). THAT *DOES* have a value, but that's not what's being dicussed here.
But exercising has an immediate effect on the published "state" of the company. Options have a potention future dilution of the stock price, depending on the future stock price, and what people decide to do with their options.
However, publishing the outstanding options, their strike prices, vesting schedules, etc, will allow a long-term investor to see what the risks are from dilution.
Now, that will protect the investor from the employee, but the real worry isn't the employee, but upper management (who get a lions-share of hte total number of option shares).
They need to be held responsible (personally) for tactics such as running a company into the ground for a short-term surge in stock prices that net them a great deal of income. That needs to be the problem.
But a given mgmt type will only get away with it once, but if they do ir right, they only need to. Then they've got more than enough money.
But no-one should go into long-term investment with a company without getting a very good feel for it's managment and it's employees, and it's market. It's called Due Dilligence, and a lack of doing so will get you burned, badly.
Actually, options have no value when given. None. Usually, they are worthless for at least a year, at which they start vesting (this does vary from company to company).
After that point, they *might* have a value. But that's unknown.
That's why they shouldn't be expensed. A company could issue options during a high time in the market, get reamed for the "expense", and then the market goes down, the options are worthless, and the company's EPS was crap, yet the company always had more than enough earnings.
If you're worried about the dilution of the company you're investing in, then the number of shares outstanding at each strike price, and the date of issuance, vesting schedule, and expiration should all be documented. Then you can see that the price now is $20. There are a large pool of options at $21. If the price rises to $25, that pool might get exercised, and thereby reduce the value of each share by a portion, but dilution is rarely any large amount. If you have 50,000,000 shares on the market, and options for another 1M shares at $21, and those get exercised when the stock goes up to $25, then the value at that price per share, assuming the same market cap, will be about 2% less than otherwise.
But an investor can take this into account. A short-term investor doesn't care about dilution, he's not in the company long enough to do so. A longer term investor does worry, and should do that kind of due dilligence. Anything else is just being a bad investor.
"ooh!! They make internet products! BUYBUYBUYBUY!!" gah,,, stupid gits...
However, if what you're looking at IS 3D data, like as someone mentioned, automotive parts, then you do get a benefit from just DL'ing the model, and rendering it.
My laptop can easily push 1200fps with GLX gears, which is be no means a complex demo, but that implies that it can handle 40x as many triangles/sec, and still provide very good animation capabilities. That IS a benefit.
And while most meshes are complex, re-used objects only need to be dealt with once. A good scene description language would allow the definition once, maybe with controls for variations, and then be able to spit out copies in memory at very high speed.
If you've got the rendering power to handle the triangles, then you don't need the textures, which are usually (in my experience) used as a crutch to lower the polygon count at the sacrifice of more memory. Frankly, I'd rather see more, simpler textures, and a LOT more polygons, and let the hardware do the work.
New hardware is downright amazing in what it can push.
Visualization and interaction are definitley the key to making 3d work. I think we've got the bandwidth. triangles just aren't that big, a handful of bytes per.
:)
Compression techniques like this may help, but only in cases where the base mesh is VERY complex, and has lots of redundant triangles. And the position of the viewer either has to be discarded, or the compression has to be fast so that it can be done server-side for each client (or at least done in blocks such that different compressed mesh copies are made ahead of time, and hte user switches meshes every so often, to bring far-away, compressed-out detail into more detail.
I think my modem can handle a fairly simple bit of streamed triangle data, say 350 triangles/sec, more with compression (at the PPP level, where I do get a fair bit with easily compressible data (seen 8KBps over a 26Kbps downlink with text).
But DSL/Cable should be able to download enormous amounts of data. And a GOOD client/server protocol for downloading objects at a time, instead of scenes at a time could allow for a very http/web-browsing method.
Load the "ground" and "sky" first, or in chunks, radially outward from the user, only in the hemisphere in which they can see, and then start DL'ing objects one at a time, again, having the client start with the base model, and maybe bounding boxes, and computing what objects are of interest to it. It can be displaying continually as it downloads, too. Just like images. I think people are very used to this with web pages.
But then, display of data within that "world", and the manipulation of that world is going to just suck for a while. A good 3D UI is going to be even more difficult to design than a good 2D one, as they are harder than a good console app. At least, that's my impression of things.
Then of course, the MFCs of the 3D world will try to turn everything into a homongenous mismash, and you won't be able to tell at a glance what you're dealing with.
I'd love to get into OpenGL programming for stuff like this, and try to get it working on lower-end hardware, like a old Indigo. Aim for that baseline, and then throw it only the new stuff from ATI and nVidia, and it should be smooth as silk for display/interaction. Bandwidth is still an issue, but that mainly affects what level of detail you'd want to DL in the first place.
I can definitely see this looking like it came out of snow-crash...
Twice the cost, 500x speed? what are you referring to here (dial-up vs. DSL/Cable? or something faster than DSL/Cable?)
water-cooled.
For instance many oil companies buying up solar/renewable IP and sitting on it?
LOL...
agreed.
I learned POVRay with 2.x or so, back in HS.
Not all are this stupid.
On my 2000 Dodge Ram 1500 (pickup truck), if you cycle the key in the sequence ON - OFF - ON - OFF - ON, the digital odometer will spit out the codes, one after the other, and then read "p done", and switch back to the odometer. (just don't put the key into START).
Disconnect the batter for 5-15 minutes, and all the codes are cleared from memory.
Oh, and a magnetic reed switch could be used in the gas-cap area. Most reeds are sealed inside a small glass tube.
Stored in volatile memory. Disconnect the batter for 15 minutes, and the codes are all cleared.
Some codes DO get stuffed into permanent storage, though. Depends on the car. But not many. Usually the ones that require a trip to the dealer (ie, the "change oil light" on some bmws were like this. YOu had to use a "special tool" (aka, paperclip), to reset the oil-change logic by inserting it in a hole in the dash)
Actually, the reason is demand. The manual transmissions available in light trucks tend to fall into two categories, the ultra-light-duty one that's coupled with the most-base engine available, and the ultra-heavy-duty one that's for use with the monster diesel that's used by people who actually need to tow.
The small manual transmission is either unpopular, or not strong enough for the middle of the road engines that are most popular (ie, the big V8s).
The small manual is probably tuned for a V6, and the big manual is designed for a big turbo-diesel.
AFAIK, you can't buy a 1/2-ton pickup in the US with a big V8 and a manual. No one wants them.
I just know that after owning a 5000 lb, 1/2-ton rated 4x4 pickup with a vig v8, and a slushbox (automatic transmission), I'm not owning another. Next truck will be diesel and a manual.
Not for the massive towing capacity, but for the doubled milage of the diesel, and the greater durability and control of the manual (plus it's just more fun in the hills to have a manual).
If any of the big 3 came out with a quality inline-6, 4 liter (or so) turbo diesel for use in 1/2 tons and smaller trucks, they'd sell like hotcakes. Especially with the current fuel prices, the MUCH greater mileage, and the new common-rail injection that makes even the big engines (the 5.9L Cummins, for instance) VERY quiet.
I realized the punny potential, but decided to leave it. Guess the computer can *internally* clean itself up, but the exterior's gonna still be left to the user.
No, it's not too harsh. Suspend their service, send them a note saying that they've been compromised, and they need to clean up their PCs.
Restrict their accounts to only allow port 80 to known good spyware/malware cleanup vendors, and go from there. AdAware + SpyBotSD + Symantec (Corp Edition) seals up a box nicely, or at least cleans it up temporarily.
I've been slowly teaching the other firefighters in my volunteer fire dept, and they're learning. They're not the most computer literate, but you give them a few links, and they can download what they need, and go back to viewing pr0n with less worries than before, or can at least clean up the computer afterwards...
At least with the seek times vs. rpm, we're now to a point where it pretty much looks like (on any decent drive) seek time is dependent on RPM.
I've been looking more and more at the EPIAs, and the mini-ITX stuff. My home boxes are likely to start being of two flavors either a silent, air-cooled "appliances" running an EPIA or similar, in a smallish, durable case. Or a full-blown workstation designed for doing workstation things (development, graphics processing (ie, digital camera), mp3/mpeg encode/rip, etc.). Although that workstation sure would be nice if it was in the form of a durable laptop...
Same here. But the problem is then people write thier apps for that more computing power, and it just seems to get wasted.
Most current-day coders don't seem understand the word optimize very well.
And I'm not talking in-lining assembly, or using C vs. an interpreted language, I'm talking about really stupid algorithms that are slow in any language.
I'm a software developer (C++, mostly msdev). As such, I recompile a LOT. With a drive dedicated to mostly source and intermediate files, about 6GB of a 9GB drive, it regularly fragments itself into molasses. It normally takes a while, but it happens. The continual replacement of files just dries NTFS up a wall. This is using both win2k and xp. I end up needed to defrag about once a month.
/var/tmp/*, which gets used heavily for compiling (gentoo and portage).
The problem really rears it's head once the space between the files isn't big enough for the new files, and then things start getting fragmented in a hurry.
And does it make a difference? In disk-intensive things like compiling (lots of small modules that get compiled into big binaries/debug symbol files), it really has an impact. The more the heads have to move around, the slower it all gets.
I also use lots of partitions to isolate things, so that even as it fragments, the fragments don't get too far apart. However, if you do a lot of swapping to disk, the partitions will kill you, unless the swap is on the same partition as where you're working. So I tend to foist the swap off on another drive entirely (all SCSI) so that the seeking is reduced as much as possible.
Placebo? probably is for most people that aren't continually writing/rewriting to disk. But if you're constantly reading/writing/erasing files, it is useful.
Now if I could just figure out a way to safely split up my root filesystem on linux to keep the heavily used trees separate from the not-so-heavily used ones (performance experiment). Mainly my
Yeah, the heavy hydraulic cutters go right through them, if you can get an edge between the jaws to start with.
We actually don't have drills with us (haven't needed them). And in the time to drill, and mess with a potentially heavily compressed window, I can just pull the doors off. It's really quite easy, with the right tools, and the right placement.
Squeeze a little here, little there, then stick the tips of the spreaders in, and open wide. VERY fast once you've done it a couple times.
Actually, older cars were bricks that just transfered the energy directly to the interior (think billiard balls).
Newer cars have "crush zones", and a prime example is the Mini. Head-first into an immovable object and it crumples away, slowing the car gradually, as the front of the car crushes.
The trick is getting it just right. To soft, and you crush the occupants. Too hard, and it's not useful.
They've been slowly getting there over the years.
The focus of the manufacturers IS actually major impacts, and not small impacts. The car is meant to be totalled with as little damage to the occupants as possible.
I've seen several head-on into trees that totalled the car, and the driver walked away without a scratch. An impact that in an older car (or a full-size truck) could have seriously injured the people inside.