You wanna see market manipulation in the small.... go watch the price of a common commodity like 'Goldthorn' or 'Neitherweave bags' it helps if you install and use 'Auctioneer' so you can get some meaningful data to analyze.
So, on Thursday you will see sellers posting their goods for the weekend crowds. By Thursday around midnight server-time count the number of over-priced auctions and the number of auctions that are at or below market price. Especially take note of the auction details for at market and below market 'neitherweave bags' as these show WHO MADE IT, not just who is selling it.
Count again every few hours. More often than not you will see:
* The number of at or below market auctions decrease, while the number of above market auctions increases by a almost the exact same number. * Notice that the Seller of the new over-price auctions is the same as previous over-priced auctions, and the creator of the objects were the previous sellers. By Friday evening only the extreme markups are left. The manipulators had the resources to buy out all sellers who were content to sell at or below market.
As they drive the median price up over weeks and weeks of manipulation they gain a hefty profit, and they also end up with a sizable inventory of product purchased below market. When the market price climbs too high for them to effectively push it up any higher, they dump their conserved inventory in large bursts well below current market, but still above the older fair market, thus driving the market back down.... and freeing their warehousing. They then move on to another commodity.
It only takes a few clowns with deep-pockets to do this to a low to medium activity server to dominate any market they enter. Some do it as in-game sport. It also generates gold-farmer inventories. None of it is fair to players just trying to supply their toons, or generate fair return on their legitimate resource farming income if they happen to post during the "dumping cycle" of a market maker.
Or even easier..When your site is setup to limit how many tickets can be bought per session or person, change it to limit how many tickets can be bought per credit card. You really don't think these guys had 5,000 credit cards to buy 20,000 tickets at a time, do you?
Seems it would have been trivial to block by ticketmaster, if they ever cared.
If you actually read the Indictment you would know that they and their brokers used every method they could think of to get control of enough credit cards and snail-mail addresses to avoid attempts by ticket vendors in filtering out exploitive purchases.
Maybe you could read the Indictment and be illuminated on their technique, and why it led to a massive string of Federal charges.
It exploited a feature of the TM system that allows a potential customer to "hold" a ticket selection long enough to enter their CC digits and confirm a sale. These bots would lock the system up by breaking through the CAPTCHA and then holding hundreds to thousands of ticket selections in limbo while their sales agents haggled with ready and waiting "brokers" for the best seats. Legit customers were locked out of the best selections until the brokers put in their orders for the tickets "held" in limbo by Wiseguys' bot array.
IRL, I suppose an equivalent would be a bunch of Thugs storming the ticket office just as it opens, and then barring the doors to the remaining crowd. The clue free ticket agent ends up selling all the best tickets to the thugs and their "friends." The raiding crew then exits through the fire doors... Neither the ticket agent or the legit customers are quite sure what just happened... awareness of the screw-job only becomes apparent later.
So far as I can tell from some of the details in the indictment Wiseguys were a big target because they were very successful at implementing their exploits, and profiting from them.
TicketBastard, et al, are perfectly within their retail rights to set prices, terms for sale, use for their tickets based on their agreements with the venues and artists. The ticket is in effect a temporary lease to a specific part of a PRIVATE VENUE for the purpose of witnessing a specific event.
What is unfair is that Wiseguys methodically and maliciously violated TicketBastard's and other's TOS, and screwed their customers out of the best seats by end-running the system that attempted --however poorly implemented it was-- to give legitimate customers a fair shot at the best seats in the house.
By interfering with TicketBastard's (et al's) direct relationship with their legitimate customers, Wiseguys deprived an unknowable (but large) number of consumers access to goods and services that they had good reason to expect they would have access to, and at a fair (even if artificially set) price. While TicketBastard, et al do not lose revenue, they lose good-will if their "first come; first served" system is perceived by potential customers as exploitable by scalpers, or simply unfair by some unknown influence.
Other's who claim that Wiseguys did not engage in theft or (possibly malware) have not read the Indictment carefully. There are specific charges that they stole code from ReCAPTCHA servers, and also from various authorized ticket vendors to assist in defeating their attempts to enforce TOS on their services. They also appear to have acquired "back-door" access to one or more of the ticket vendor's systems to gain exploit information and possible market information to "build" their attacks.
That Wiseguys' 'bots' did not make use of malware to obtain computation resources is beside the point. If anything it shows that they were careful to avoid direct ties to unquestionably illegal computing resources.
Heck you can go to any number of "freelancer" sites and find employment offerings that are basically thinly(or poorly) disguised attempts to trick/encourage skilled programmers into working on elements of any number of morally questionable projects. I think the current freelance market is rife with potential legal risk for well meaning, and naïve professionals to end up working for some self-styled "Guido."
This same kind of nonsense is why beginning electronics students have a rough time with transistor circuits. Electron flow is opposite 'conventional current flow.'
To make matters worse electronic symbols have arrows that point towards the higher electron potential, not away from it. So in effect they are indicating hole flow not electron flow.
The irony is that in electronic diagrams we are told, point the arrows (transistors and diodes in particular) towards the most negative potential expected in the circuit, for typical usage.
It's completely silly. However, we seem to be stuck with it.
In SL: It used to be possible to trick an avatar to "consent" to being animated. Longer ago... there was this nasty object called a "skull fucker" that would allow the assailant to simulate a "Skull Fuck" without the victim's consent.
There are still WAY more options for wanna-be greifers in SL than any other platform on the market. Many more have been nerfed. And a huge number of accounts and even entire groups have been banned over the years.
In WoW I get a kick out of the "after-school-special" kids who flip their PvP flag and run into the middle of lower-level group's EvP melee. They try to force a cross-faction PvP by getting hit with an AOE from the victim group.
I cut my teeth on Z-80(Sinclair Zx-80/81) and 6502 when I was 11. I am only now working towards my first BS and your earlier comments about the %2 gap (more like 10% for me) are quite salient. Though at my age I am not going to go for CS. I am going for business admin and project management, as I think this is an area I can best apply my experience with new training.
I don't disagree with the conclusion on LSL: That is LSL is fail. I do think that the intern who designed and implemented LSL did an admirable job considering LL had no idea what users would do with SL. They also needed to keep the execution environment for scripts light-weight, and memory constrained. It does quite well in that regard. I regularly see 4-8K scripts running in a Sim, with only a few % lag over an empty sim. On the other hand, I have seen what happens when some asshat figures out how to get a few hundred scripts to make a sim useless, without attacking the physics engine. Giving the general public execution privileges on a service like SL is not an easy problem to solve. In that context maybe LSL isn't all that bad for what it DOES do.
The issues with manipulating Non-Phys prims are actually related to the way the Havok physics engine handles them, not LSL. Those issues would exist no matter what language were driving the property inputs.
It does need to be replaced. Rebuilding the language on the MONO VM was the first major step in eventually supporting a broad range of languages; possibly even allowing 3rd party compilers.
----
Funny you should mention Lua... I am currently in the process of modifying Lua to run on PIC32MX series micro-controllers. The intent is to provide a development environment for these amazing controllers that is easier for an enterprising 11 year-old to get their head around than embedded C or raw assembly.
One of the worst examples I can think of off the top of my head is LSL (Linden Scripting Language), used in Second Life. It's an absolute nightmare of a language. And yet, it made it into a large-scale product like Second Life.
If you have problems with LSL then you are misusing it. It is a DSL and it's very good at what it was DESIGNED to do. Which is animate CSG link-sets. Using for anything else is asking way too much. Even Linden Labs has forgotten that it's not a generalized language. Abuses abound, including features added to the stdlib that should not be there without redesigning the language!
The crap that many people write in LSL is an example of trying to use a phillips screw driver to install every fucking fastener except phillips-head screws!!!
Programming in LSL has more in common with using an embedded micro-controller with an application specific library for motion control....
Working with LSL has been a kick. One example is building very efficient PID controllers... and other tasks that interact with virtually physical processes.
People that complain about LSL either don't get it, or are actively trying to make it operate in problem domains it was not designed to operate in.
If it turns out the dna is the only way of doing this properly (or the best way) then we would expect to see it everywhere there is life. For all we know there could have been a number of competitor systems but DNA won hands down due to its superior properties and/or ease of evolutionary access - in which case we can expect it to be ubiquitous as well. This is basically a variation of the contingency vs inevitability argument.
A key point might be made that DNA works for the regime WE evolved in. It works when you are 8 light minutes away from a yellow star and have a fairly substantial atmosphere of hydrogen, oxygen and nitrogen.
It's far less clear what will work under a less forgiving regime.
What goes on with organics in Jupiter's or Saturn's atmosphere, at say 5 - 20 atmospheres?
What about the more sheltered locations on Venus or Mercury?
Maybe not much...
We have hundreds to thousands of years of planetary study yet to accomplish. There is a huge amount of work yet to be done.
The thing that always bothered me about pansperima and related theories is that, while exciting, they depend on the premise that there must be a certain concentration of places out in space that are better suited for generating life or its basic compunds than here on earth. I have a hard time imagining such a place, and have yet to see any of the proponents describe even the rudimentary properties of such a place would need to have.
Is it so difficult to imagine that our little patch of galactic sky has had it's share of Pandoras, Endors, Degobahs, Earths, etc... that have bloomed, and become utterly saturated in organic mass?
Would it also be much of a stretch to imagine that some meaningful fraction of such moldy boulders might get shattered by other less interesting rocks?
Would it be too much to expect that some get slung out of orbit, or turned into a ~0.1*c shotgun-blast of interstellar gravel when their local star takes 'The Big Shit?'
How many million years might it take a chunk of one of those organically contaminated splinters to travel a few dozen light years, or even a few hundred?
How long until it might it wander until it got caught in another stellar waltz and hit something? A million years? A few billion years?
Interstellar space seems to be sparse, but it's not THAT sparse. Stars tend to collect shit too.... So do large clouds of dust. In the mean time, the flash-heated, vacuum-frozen, moldy chunks would get a nice protective layer of dust and gas, keeping the remaining organics relatively safe.... maybe.
Do we know that this happens? No. Is it reasonable to expect that it does? I tend to think it might.
5 billion years (give or take a billion) is a long fuxing time. Where will the Pioneer and Voyager probes be in a few million years, for comparison?
We get a constant rain of crap filtering down on this moldy rock -- many tons per year. Almost all of it extra-teresstrial. Some fraction of it probably was not part of the formation of this star system. Some smaller fraction of it is likely organic. How much might that be?
Bringing this up, I am not suggesting that life here was patterned elsewhere. I am saying that it doesn't strike me as fantastic that we'd find complex organics in extra-terresterial debris. I also would not be very surprised that continual influx of such material for billions of years might have influenced the diversity of native organics.
In "bucket chemistry" it is not uncommon to have the following situation:
BEGIN CAR ANALOGY:
1) Take a large cement mixer, fill it will enough loose components to manually assemble 10,000 automobiles. 2) Agitate, heat, compress and cool the "mixture" while adding a few more components and some tools at appropriate times.... continue for a loooong time... 3) dump resulting mixture through a car-philyic filtering process.... 4) not-cars are washed away; leaving a two or three fully assembled cars. 5) Wash. Rinse. Repeat. 6)... 7) profit.
END CAR ANALOGY;
Most industrial chemistry works on similar principles. YMMV
I'll add, that in particular, an electric power steering module made by Audi does NOT do the right thing. When confronted with a error-heavy bus it shuts down if it does not see an ENGINE_RUN packet every 1500ms. Regardless of the error state of the bus, or any other potential indications (like main bus voltage) that the engine is, in fact still running.
While the application I worked on was not directly related to CANbus applied in a car, I can say that a given controller might have a difficult time deciding what to do if the bus suffered a general communication failure.
The issue at hand is FBW vs MA. For systems like aircraft you get a choice due to advances in redundancy and system voting. In a budget oriented automobile application these solutions are not viable YET. So why go there at all?
The project I referenced was my first with CANbus, and I do find a lot I like about it. I am considering it for some other projects since it does behave very well in failure modes, when using well designed network modules. The catch is that if the other modules in a system do not take a conservative approach to their signaling they can kill the bus. Who knows what an ECM DOES do when confronted with an error-retry overload on the bus? I don't, my application didn't touch on that particular interaction. What I do know is that it doesn't take much to make it happen... just get the bus terminated improperly on a high volume traffic (mine was dealing with 9ms between packets on a 500KHz bus) and it's every controller for themselves in error recovery mode. Your solution would cause a power steering module to shutdown, or an ECM to go into limp mode.... what if that were to happen in heavy rush hour traffic on a stormy night.... I can bet the sudden loss of assist and engine power might create a serious risk. All because a cracked wire got too wet.
That is a serious problem with these systems. It's not root failure that is devastating, it's that the linked systems do not fall back to safe positions in all cases, and that is much harder to test for and verify.
This can be included in the decision tree by noting that that forward motion is ZERO! By the time the car is moving 5 mph there wont be a Accel Brake conflict.
So if your kid is being dumb behind the wheel, you would rather have them die and take their friends and and innocent bystanders out too? maybe my niece?
You sick fuck!
you cant count on the ignorant masses to do the right thing in all cases. Additionally it's often not the idiot who is at risk. That is one reason why there are Big Red Buttons. In a fair number of cases it's a third party that presses those safety shutdowns to save some other fool from hurting someone other than themselves. I have been the fool, and the one pressing the button when others didn't realize that something had gone wrong. Apparently you have done neither. Wake up, fool, social Darwinism does not work like you think it works.
what you didn't see is the gradual fraying of the cable, and under the right conditions this could cause the cable to bind in the sheath. However, the reason this didn't happen in a lot of systems and why the most common failure is a cable break at end of life, is because it was designed to make sure that the most stressed portions of the cable are also the most exposed, so they don't have anything to bind against, when they start fraying. also the pedal return spring is quite beefy. Get down there with your paws sometime and push on it... same with the brake pedal... your feet have a lot more power available, even under relaxed regimes, and a good engineer takes full advantage of that.
another drawback to PARKING BRAKES is that they only engage the rear shoe on drum systems, and a secondary actuator in disc systems. The secondary actuator is off-center from the friction plate, so it does not provide a solid engagement of the caliper. They are parking brakes NOT emergency brakes! Yes in a pinch they can help, but they cannot overcome the engine, and at any significant speed even a well adjusted parking brake will not provide any significant stopping force.
If you examine a typical main brake system you will see that it would take a tremendously unlikely scenario to make it inoperative from the driver's perspective. Losing power assist is not a barrier to putting both feet on that pedal and jamming it through the floorboards. I have driven in situations that required shutting down the engine and coasting. (Overheating engine while trying to get off a mountain, for one!) Yes it takes more force for steering and braking, but it's not that much of a loss. It just makes driving more physical, and tiring. Loss of the creature comforts in power assist does not make the vehicle undrivable! The most dangerous aspect of my example was the risk of turning the key too far and locking the steering column: I assure you I was meticulously careful about how far I turned that key! I was fully aware that under the wrong conditions locking the steering column would be irreversible, since the locking pin can bind to the hole in the steering shaft, making it impossible to get steering back. You have probably experienced this yourself... parking on a hill... the car creeps forward/backward a bit and effectively puts a huge amount of force on the steering shaft, thus making it impossible to unlock the shaft without compensation. The compensation is applied by pulling the steering wheel the correct direction to offset the load on the locking pin. I remember watching my mother struggle with that in the first car she owned that had a locking pin.... This can also happen with the parking pin in automatic transmissions! Though, often there is more leverage available to force it out of park. I have had to two-hand the column shift on a car to get it out of park. The whole point of the parking pin(and putting your manual transmission in 1st or Rev.) is to provide more braking force in extreme parking conditions, eg. redundancy!
In a "smart" system we have a problem. The system is not aware of what the real situation is, or why there might be a sudden change in driver interaction with the controls. The facts point to systems where the computer is over-thinking the driving situation. This needs to stop.
Slashdot Mirror
Hey WoW players!!!
You wanna see market manipulation in the small.... go watch the price of a common commodity like 'Goldthorn' or 'Neitherweave bags' it helps if you install and use 'Auctioneer' so you can get some meaningful data to analyze.
So, on Thursday you will see sellers posting their goods for the weekend crowds. By Thursday around midnight server-time count the number of over-priced auctions and the number of auctions that are at or below market price.
Especially take note of the auction details for at market and below market 'neitherweave bags' as these show WHO MADE IT, not just who is selling it.
Count again every few hours. More often than not you will see:
* The number of at or below market auctions decrease, while the number of above market auctions increases by a almost the exact same number.
* Notice that the Seller of the new over-price auctions is the same as previous over-priced auctions, and the creator of the objects were the previous sellers. By Friday evening only the extreme markups are left. The manipulators had the resources to buy out all sellers who were content to sell at or below market.
As they drive the median price up over weeks and weeks of manipulation they gain a hefty profit, and they also end up with a sizable inventory of product purchased below market. When the market price climbs too high for them to effectively push it up any higher, they dump their conserved inventory in large bursts well below current market, but still above the older fair market, thus driving the market back down.... and freeing their warehousing. They then move on to another commodity.
It only takes a few clowns with deep-pockets to do this to a low to medium activity server to dominate any market they enter. Some do it as in-game sport. It also generates gold-farmer inventories. None of it is fair to players just trying to supply their toons, or generate fair return on their legitimate resource farming income if they happen to post during the "dumping cycle" of a market maker.
Or even easier..When your site is setup to limit how many tickets can be bought per session or person, change it to limit how many tickets can be bought per credit card. You really don't think these guys had 5,000 credit cards to buy 20,000 tickets at a time, do you?
Seems it would have been trivial to block by ticketmaster, if they ever cared.
If you actually read the Indictment you would know that they and their brokers used every method they could think of to get control of enough credit cards and snail-mail addresses to avoid attempts by ticket vendors in filtering out exploitive purchases.
Maybe you could read the Indictment and be illuminated on their technique, and why it led to a massive string of Federal charges.
It exploited a feature of the TM system that allows a potential customer to "hold" a ticket selection long enough to enter their CC digits and confirm a sale. These bots would lock the system up by breaking through the CAPTCHA and then holding hundreds to thousands of ticket selections in limbo while their sales agents haggled with ready and waiting "brokers" for the best seats. Legit customers were locked out of the best selections until the brokers put in their orders for the tickets "held" in limbo by Wiseguys' bot array.
IRL, I suppose an equivalent would be a bunch of Thugs storming the ticket office just as it opens, and then barring the doors to the remaining crowd. The clue free ticket agent ends up selling all the best tickets to the thugs and their "friends." The raiding crew then exits through the fire doors... Neither the ticket agent or the legit customers are quite sure what just happened... awareness of the screw-job only becomes apparent later.
So far as I can tell from some of the details in the indictment Wiseguys were a big target because they were very successful at implementing their exploits, and profiting from them.
TicketBastard, et al, are perfectly within their retail rights to set prices, terms for sale, use for their tickets based on their agreements with the venues and artists. The ticket is in effect a temporary lease to a specific part of a PRIVATE VENUE for the purpose of witnessing a specific event.
What is unfair is that Wiseguys methodically and maliciously violated TicketBastard's and other's TOS, and screwed their customers out of the best seats by end-running the system that attempted --however poorly implemented it was-- to give legitimate customers a fair shot at the best seats in the house.
By interfering with TicketBastard's (et al's) direct relationship with their legitimate customers, Wiseguys deprived an unknowable (but large) number of consumers access to goods and services that they had good reason to expect they would have access to, and at a fair (even if artificially set) price. While TicketBastard, et al do not lose revenue, they lose good-will if their "first come; first served" system is perceived by potential customers as exploitable by scalpers, or simply unfair by some unknown influence.
Other's who claim that Wiseguys did not engage in theft or (possibly malware) have not read the Indictment carefully. There are specific charges that they stole code from ReCAPTCHA servers, and also from various authorized ticket vendors to assist in defeating their attempts to enforce TOS on their services. They also appear to have acquired "back-door" access to one or more of the ticket vendor's systems to gain exploit information and possible market information to "build" their attacks.
That Wiseguys' 'bots' did not make use of malware to obtain computation resources is beside the point. If anything it shows that they were careful to avoid direct ties to unquestionably illegal computing resources.
Heck you can go to any number of "freelancer" sites and find employment offerings that are basically thinly(or poorly) disguised attempts to trick/encourage skilled programmers into working on elements of any number of morally questionable projects. I think the current freelance market is rife with potential legal risk for well meaning, and naïve professionals to end up working for some self-styled "Guido."
I'll bet he's worn a trough into the Oval Office rug... pacing and chain smoking....
Wouldn't the stripper ring? "Ding Dong!"
Just sayin'
your measurement would be fail.... it would show 50Hz, and your sense of time would similarly fail in side the time dilated region.
Now... you might notice a slightly bluer cast to the Sun.... that would be a sign to cause worry.
This same kind of nonsense is why beginning electronics students have a rough time with transistor circuits. Electron flow is opposite 'conventional current flow.'
To make matters worse electronic symbols have arrows that point towards the higher electron potential, not away from it. So in effect they are indicating hole flow not electron flow.
The irony is that in electronic diagrams we are told, point the arrows (transistors and diodes in particular) towards the most negative potential expected in the circuit, for typical usage.
It's completely silly. However, we seem to be stuck with it.
In SL:
It used to be possible to trick an avatar to "consent" to being animated. Longer ago... there was this nasty object
called a "skull fucker" that would allow the assailant to simulate a "Skull Fuck" without the victim's consent.
There are still WAY more options for wanna-be greifers in SL than any other platform on the market. Many more have been nerfed. And a huge number of accounts and even entire groups have been banned over the years.
In WoW I get a kick out of the "after-school-special" kids who flip their PvP flag and run into the middle of lower-level group's EvP melee. They try to force a cross-faction PvP by getting hit with an AOE from the victim group.
MacOS 6.X
It's been possible to do this on Apple's 'open slot' machines since NuBus was the sh*t....
Cheers
I cut my teeth on Z-80(Sinclair Zx-80/81) and 6502 when I was 11. I am only now working towards my first BS and your earlier comments about the %2 gap (more like 10% for me) are quite salient. Though at my age I am not going to go for CS. I am going for business admin and project management, as I think this is an area I can best apply my experience with new training.
I don't disagree with the conclusion on LSL: That is LSL is fail. I do think that the intern who designed and implemented LSL did an admirable job considering LL had no idea what users would do with SL. They also needed to keep the execution environment for scripts light-weight, and memory constrained. It does quite well in that regard. I regularly see 4-8K scripts running in a Sim, with only a few % lag over an empty sim. On the other hand, I have seen what happens when some asshat figures out how to get a few hundred scripts to make a sim useless, without attacking the physics engine. Giving the general public execution privileges on a service like SL is not an easy problem to solve. In that context maybe LSL isn't all that bad for what it DOES do.
The issues with manipulating Non-Phys prims are actually related to the way the Havok physics engine handles them, not LSL. Those issues would exist no matter what language were driving the property inputs.
It does need to be replaced. Rebuilding the language on the MONO VM was the first major step in eventually supporting a broad range of languages; possibly even allowing 3rd party compilers.
----
Funny you should mention Lua... I am currently in the process of modifying Lua to run on PIC32MX series micro-controllers. The intent is to provide a development environment for these amazing controllers that is easier for an enterprising 11 year-old to get their head around than embedded C or raw assembly.
One of the worst examples I can think of off the top of my head is LSL (Linden Scripting Language), used in Second Life. It's an absolute nightmare of a language. And yet, it made it into a large-scale product like Second Life.
If you have problems with LSL then you are misusing it. It is a DSL and it's very good at what it was DESIGNED to do. Which is animate CSG link-sets. Using for anything else is asking way too much. Even Linden Labs has forgotten that it's not a generalized language. Abuses abound, including features added to the stdlib that should not be there without redesigning the language!
The crap that many people write in LSL is an example of trying to use a phillips screw driver to install every fucking fastener except phillips-head screws!!!
Programming in LSL has more in common with using an embedded micro-controller with an application specific library for motion control....
Working with LSL has been a kick. One example is building very efficient PID controllers... and other tasks that interact with virtually physical processes.
People that complain about LSL either don't get it, or are actively trying to make it operate in problem domains it was not designed to operate in.
Pre-owned == Pwnd before the sale..... brilliant.... too bad score only goes to 5.... and me sitting here without mod points.... meh...
If it turns out the dna is the only way of doing this properly (or the best way) then we would expect to see it everywhere there is life. For all we know there could have been a number of competitor systems but DNA won hands down due to its superior properties and/or ease of evolutionary access - in which case we can expect it to be ubiquitous as well. This is basically a variation of the contingency vs inevitability argument.
A key point might be made that DNA works for the regime WE evolved in. It works when you are 8 light minutes away from a yellow star and have a fairly substantial atmosphere of hydrogen, oxygen and nitrogen.
It's far less clear what will work under a less forgiving regime.
What goes on with organics in Jupiter's or Saturn's atmosphere, at say 5 - 20 atmospheres?
What about the more sheltered locations on Venus or Mercury?
Maybe not much...
We have hundreds to thousands of years of planetary study yet to accomplish. There is a huge amount of work yet to be done.
YMMV
The thing that always bothered me about pansperima and related theories is that, while exciting, they depend on the premise that there must be a certain concentration of places out in space that are better suited for generating life or its basic compunds than here on earth. I have a hard time imagining such a place, and have yet to see any of the proponents describe even the rudimentary properties of such a place would need to have.
Is it so difficult to imagine that our little patch of galactic sky has had it's share of Pandoras, Endors, Degobahs, Earths, etc... that have bloomed, and become utterly saturated in organic mass?
Would it also be much of a stretch to imagine that some meaningful fraction of such moldy boulders might get shattered by other less interesting rocks?
Would it be too much to expect that some get slung out of orbit, or turned into a ~0.1*c shotgun-blast of interstellar gravel when their local star takes 'The Big Shit?'
How many million years might it take a chunk of one of those organically contaminated splinters to travel a few dozen light years, or even a few hundred?
How long until it might it wander until it got caught in another stellar waltz and hit something? A million years? A few billion years?
Interstellar space seems to be sparse, but it's not THAT sparse. Stars tend to collect shit too.... So do large clouds of dust. In the mean time, the flash-heated, vacuum-frozen, moldy chunks would get a nice protective layer of dust and gas, keeping the remaining organics relatively safe.... maybe.
Do we know that this happens? No. Is it reasonable to expect that it does? I tend to think it might.
5 billion years (give or take a billion) is a long fuxing time. Where will the Pioneer and Voyager probes be in a few million years, for comparison?
We get a constant rain of crap filtering down on this moldy rock -- many tons per year. Almost all of it extra-teresstrial. Some fraction of it probably was not part of the formation of this star system. Some smaller fraction of it is likely organic. How much might that be?
Bringing this up, I am not suggesting that life here was patterned elsewhere. I am saying that it doesn't strike me as fantastic that we'd find complex organics in extra-terresterial debris. I also would not be very surprised that continual influx of such material for billions of years might have influenced the diversity of native organics.
YMMV
In "bucket chemistry" it is not uncommon to have the following situation:
BEGIN CAR ANALOGY:
1) Take a large cement mixer, fill it will enough loose components to manually assemble 10,000 automobiles. ...
2) Agitate, heat, compress and cool the "mixture" while adding a few more components and some tools at appropriate times.... continue for a loooong time...
3) dump resulting mixture through a car-philyic filtering process....
4) not-cars are washed away; leaving a two or three fully assembled cars.
5) Wash. Rinse. Repeat.
6)
7) profit.
END CAR ANALOGY;
Most industrial chemistry works on similar principles. YMMV
Bat strikes are a lot more common.
I'll add, that in particular, an electric power steering module made by Audi does NOT do the right thing. When confronted with a error-heavy bus it shuts down if it does not see an ENGINE_RUN packet every 1500ms. Regardless of the error state of the bus, or any other potential indications (like main bus voltage) that the engine is, in fact still running.
While the application I worked on was not directly related to CANbus applied in a car, I can say that a given controller might have a difficult time deciding what to do if the bus suffered a general communication failure.
The issue at hand is FBW vs MA. For systems like aircraft you get a choice due to advances in redundancy and system voting. In a budget oriented automobile application these solutions are not viable YET. So why go there at all?
The project I referenced was my first with CANbus, and I do find a lot I like about it. I am considering it for some other projects since it does behave very well in failure modes, when using well designed network modules. The catch is that if the other modules in a system do not take a conservative approach to their signaling they can kill the bus. Who knows what an ECM DOES do when confronted with an error-retry overload on the bus? I don't, my application didn't touch on that particular interaction. What I do know is that it doesn't take much to make it happen... just get the bus terminated improperly on a high volume traffic (mine was dealing with 9ms between packets on a 500KHz bus) and it's every controller for themselves in error recovery mode. Your solution would cause a power steering module to shutdown, or an ECM to go into limp mode.... what if that were to happen in heavy rush hour traffic on a stormy night.... I can bet the sudden loss of assist and engine power might create a serious risk. All because a cracked wire got too wet.
That is a serious problem with these systems. It's not root failure that is devastating, it's that the linked systems do not fall back to safe positions in all cases, and that is much harder to test for and verify.
This can be included in the decision tree by noting that that forward motion is ZERO! By the time the car is moving 5 mph there wont be a Accel Brake conflict.
So if your kid is being dumb behind the wheel, you would rather have them die and take their friends and and innocent bystanders out too? maybe my niece?
You sick fuck!
you cant count on the ignorant masses to do the right thing in all cases. Additionally it's often not the idiot who is at risk. That is one reason why there are Big Red Buttons. In a fair number of cases it's a third party that presses those safety shutdowns to save some other fool from hurting someone other than themselves. I have been the fool, and the one pressing the button when others didn't realize that something had gone wrong. Apparently you have done neither. Wake up, fool, social Darwinism does not work like you think it works.
I'd rather that the system took the engine off-line, testosterone be damned.
ACCEL_PEDAL_DOWN(MAX_ACCEL) && BRAKE_PEDAL_DOWN(MAX_BRAKE)
Now how do you interpret the inputs?
what you didn't see is the gradual fraying of the cable, and under the right conditions this could cause the cable to bind in the sheath. However, the reason this didn't happen in a lot of systems and why the most common failure is a cable break at end of life, is because it was designed to make sure that the most stressed portions of the cable are also the most exposed, so they don't have anything to bind against, when they start fraying. also the pedal return spring is quite beefy. Get down there with your paws sometime and push on it... same with the brake pedal... your feet have a lot more power available, even under relaxed regimes, and a good engineer takes full advantage of that.
Currently working on CNC firmware, and safety is job one! If I had mod-points you get one!
another drawback to PARKING BRAKES is that they only engage the rear shoe on drum systems, and a secondary actuator in disc systems. The secondary actuator is off-center from the friction plate, so it does not provide a solid engagement of the caliper. They are parking brakes NOT emergency brakes! Yes in a pinch they can help, but they cannot overcome the engine, and at any significant speed even a well adjusted parking brake will not provide any significant stopping force.
If you examine a typical main brake system you will see that it would take a tremendously unlikely scenario to make it inoperative from the driver's perspective. Losing power assist is not a barrier to putting both feet on that pedal and jamming it through the floorboards. I have driven in situations that required shutting down the engine and coasting. (Overheating engine while trying to get off a mountain, for one!) Yes it takes more force for steering and braking, but it's not that much of a loss. It just makes driving more physical, and tiring. Loss of the creature comforts in power assist does not make the vehicle undrivable! The most dangerous aspect of my example was the risk of turning the key too far and locking the steering column: I assure you I was meticulously careful about how far I turned that key! I was fully aware that under the wrong conditions locking the steering column would be irreversible, since the locking pin can bind to the hole in the steering shaft, making it impossible to get steering back. You have probably experienced this yourself... parking on a hill... the car creeps forward/backward a bit and effectively puts a huge amount of force on the steering shaft, thus making it impossible to unlock the shaft without compensation. The compensation is applied by pulling the steering wheel the correct direction to offset the load on the locking pin. I remember watching my mother struggle with that in the first car she owned that had a locking pin.... This can also happen with the parking pin in automatic transmissions! Though, often there is more leverage available to force it out of park. I have had to two-hand the column shift on a car to get it out of park. The whole point of the parking pin(and putting your manual transmission in 1st or Rev.) is to provide more braking force in extreme parking conditions, eg. redundancy!
In a "smart" system we have a problem. The system is not aware of what the real situation is, or why there might be a sudden change in driver interaction with the controls. The facts point to systems where the computer is over-thinking the driving situation. This needs to stop.