No, and I have explained this elsewhere today, but I will do so more clearly because it matters. The sign is a fixed location, not near the pumps, so the radiated field in the area of risk is known, predictable and stable. The inverse square law also applies, as with all radiated energy, and I do wish the health risk fanatics would also read up on that. (I do think there is a health risk, or is at least likely to be one, but not usually from the base stations). The primary hazard is the high field strength near to the mobile, the location of which is not controlled, in other words it can go as near as it's owner wants to the pump nozzle.
It is not double standards, although I believe it tends to give a very wrong message to most of the general public, who have never heard of the inverse square law, and might be deceived into thinking that using mobiles anywhere on the premises is safe, when all the evidence says that it is not.
Please, everyone, read and understand what the inverse square law is all about, it is not rocket science (Google should be able to help...), it is a useful thing to know in all sorts of circumstances, and is the main reason that the ignition hazard, and the probable health hazard is from the mobile on your ear or in your pocket, rather than the base station 50 feet away, even if the mobile radiates 1.5 watts and the base station up to 50 watts.
Yes, they can. Immunity from interference in digital systems such as computers is only tested on a statistical basis by the designers, because you can't try every possible variation in timing between the CPU clock and the mobile carrier, for example. It is one reason that computers crash at random, other factors are alpha-particle effects on the RAM (much reduced nowadays by choice of packaging material), and inadequate timing margins to allow for all possible noise and jitter, which typically happens as a result of overclocking. Then of course there are random effects at the disk/head interface etc. But of course the biggest cause of crashes originates from Redmond, and the randomness is in its design.
The presence of one or more mobiles in the room may not directly cause a crash, it may simply use up some of the system's immunity to internal noise. Rectification of RF as occurs in any exposed semiconductor also causes level shifts and such like, which can put analogue things like power supplies and their monitor circuits out of tolerance, and maybe cause a reboot.
Then there is the network. Properly balanced UTP should not radiate interference, if it does not radiate, it will not receive it either (reciprocity theorem). But, it relies totally on the balance of the transceivers in the PC and hub. Anyone who has done any EMC testing (I have so I may know a little bit about the subject!) will know that they radiate a lot, at 100MHZ, harmonics and sub-harmonics maainly (on 100MHz network), therefore they are also susceptible.
I know that in my setup at home, one of my sound cards is affected by my mobile, and I think but can't prove that I have had a couple of crashes when I have left it on the desk. (I can prove the crashes, not the cause...).
So, altogether, I would say that use of a mobile, both in theory and in practice, will degrade the reliability of adjacent computer equipment. It is impossible to say without spending a vast amount of time gathering data with and without mobiles present, whether any specific installation will be vulnerable, so it is better to be safe than sorry. And yes, they do annoy people too......
Curiously, sparks from metal tend to be of very low energy, even if seemingly quite bright. In the days before Sir Humphrey Davey invented the miners safety lamp, coal miners were causing frequent methane explosions by using candles, many disasters were so caused. The safest thing they had at the time was the Spedding Steel Mill, which was a spinning steel disc rubbing on a flint, they worked by the light of the continuous stream of sparks, but methane would not ignite (usually!). It was proved to be unsafe in the end, but did not cause nearly as many explosions as might have been expected.
Much later on, in the 1960s IIRC, a manager at Ford in the UK had some petrol (gasoline to all you US/.ers) poured into pools in the concrete-surfaced yard, then a tractor dragged assorted pieces of scrap iron through it for several hours, no ignition! It was concluded that most car fires following accidents are as a result of sparks from damaged wiring, not friction. However, some believe that repeating the Ford experiment with modern unleaded fuel might give entirely different results, as apparently it does ignite more easily, so is more at risk from friction sparks, or RF sparks from mobiles.
I have actually seen someone smoking while filling a lawn mower from a can. I wonder how many times he got away with it before disaster struck. Never seen it at a filling station though.
No! Incorrect assumptions like that are exactly why these fires and explosions keep occurring worldwide. The battery could obviously cause a fire, all but the very smallest batteries can, but the primary hazard is sparks caused by the RF voltage induced in the pump nozzle. Under certain conditions of dimensions and position there are resonances at some of the cellular frequencies, which will magnify the actual voltage to the level where a spark will occur.
You can get "intrinsically safe" radio equipment which will not generate a spark, or will keep any sparks safely enclosed, for use in hazardous environments, they have a severely restricted RF output. They also use FM, with peak power the same as the average, and even then probably only about 100mW.
In the case of something like a mobile, with digital modulation, the peak power is the important thing as regards ignition hazards. The peak power of a typical mobile is 1.5 watts and is definitely unsafe.
It amazes me how in the UK, where warning notices are to be seen quite often in filling stations, that imbeciles continue their pathetic and unnecessary conversations while filling. If I see one near me, I move, and quickly...... It is a criminal offence under the petroleum spirit regulations, it is time that it was enforced properly.
BTW most HF/VHF/UHF communications equipment is potentially lethal in these circumstances. I know that cellular base stations are sometimes sited on the premises, they are carefully positioned, and the inverse square law ensures that the signal level at the pumps is well below the safety limit.
It is sad that the general public are so ignorant and ill-informed as to constantly put other people's lifes at risk by this stupid behaviour. In the UK the law requires you to switch off before entering the filling station, off means off, not standby, because if the mobile needs to access the network or respond to an incoming call, its first and unpredictable transmission will be at full power!
Don't get me started on where else they are lethal such as on aircraft, at least one businessman is, very properly, in jail in the UK as a result of his wilful ignorance on that score. If I were the judge, I would have made it a life sentence, because he put so many lives at risk, even when told not to. If stiff sentences were handed out for using mobiles in filling stations, the practice would diminish substantially. It would not stop entirely, there is always some idiot who knows better than the safety legislators.
When Unix began, it was a bit like that as you say, but the things that tended to get left unfinished, i.e. doing the easy 90% of the work, were tools, which were really intended only to do simple things. Even the Bourne shell was IMHO left half done, in early versions, but it was better to have a reduced-function but useable tool than no tool at all. The overall package was still way ahead of any possible competition.
I saw no evidence, with one possible exception, that the kernel and file system were left half-done in any commercial version. As Unix was not really well funded in the beginning, it was far better to get good but simplistic things working than to go for complex, all-singing, all-dancing solutions that mostly would not be used.
It has changed nowadays, if you look up the Linux or BSD manuals (or probably Solaris, AIX, SCOundrel etc) the modern options to some of the long-established commands have become positively bewildering. I am not sure that it really represents progress, it may have been better to to the 10% of the work to get 90% of the result, and spend the remaining 90% of the work doing 10% of the work on a set of 9 new tools, if you see what I mean, you nay get better value for money by doing a lot of quick things than one big one.
Of course whether you favour quick and simple, or long and complex, and they are both valid point sof view, the thing that must never be forgotten is quality. A simple little tool that does half the job accurately and dependably can be used to accomplish things, a grossly complex thing that does everything including making a cup of tea, but crashes every Wednesday, unless the wind is from the east, is all but useless. And that, I think, must have been the view of some of the original Unix people, which is why you can do good but limited things with sed, awk, and so on. It is easier to string basic bits together with a pipe than to make the universal panacea.
To put it in perspective, I was doing things under Unix V7 around 1983 easily that still can't be done in any M$ software without a major (and I mean major) programming exercise, or of course by using Cygwin, which sadly is not terribly efficient because the undellying OS is so poor (no fork() for example, it has to be emulated). Credit is due to the developers for getting it to work at all, on top of a so-called Posix-compatible OS that isn't.
Controlling industrial machinery in 95 or even XP? You have got to be kidding, unless of course it is a trivial bit of machinery that can't damage itself or anything/anyone else if it runs out of control. Controlling real machines with that load of excrement is legally, morally and economically highly questionable. Legally, because you will be sued when it BSODs and causes damage, morally because you are putting property and maybe lives at risk, and economically, because it will do your own business no good at all when it crashes.
Yet, sadly I have heard of it being so used, IIRC this has been debated on/. before.
In many countries you would be committing a criminal offence by using non-validated software to control anything that moves and could cause injury, and rightly so.
So, I doubt that the weird APIs are there for controlling machinery, more likely they are there because in the random way he operates, Sir Bill once thought they were a good idea, then found that they were actually useless and was too proud and stubborn to have them removed. The unused and unwanted bloat is likely to be the cause of many of the bugs and security holes, the code tends to be messily commingled with vital bits, in fact the whole of Windoze seems to be structured in the most messy way possible.
It seems that.Net is finally an admission that the Windoze API set was a complete load of rubbish, and it is time to start again, unfortunately sitting it on top of the mess that went before only makes the problem worse, and also sacrifices efficiency.
But you are basically right, the bloat is caused by backwards compatability of the unnecessary kind. Longhorn will be the same, in order to sell it will need to be compatible with the trash that went before, so it will no doubt have an enormous XP emulation layer sitting on top of the new code, to faithfully reproduce the bugs. It is time to call a halt, throw away backwards compatability (except for reading and writing file formats used by applications of course) and start again. But it will never happen until M$ ceases to be significant, the sooner that happens, the better.
I agree about the X386 architecture, it should have gone long ago. It would have been a good time to dump Windoze and get a decent OS as well. The OS is the main problem, not the processor architecture.
But, as chip density increases and word size gets bigger, the CISC vs RISC situation changes. There is also the scenario that a RISC chip reaches a certain level of speed and complexity, then a CISC manages the same. They tend to chase each other, which is good for us end users, in means that both will improve, and that there will be choice.
This has of course been going on since about 1974, the Z80 was in its day almost CISC, while the more minimalist 6502 was tending towards RISC (not quite as we now understand the term, maybe), yet the products they were used in tended to be about equal.
I think that if you were to design a CPU specifically optimised for a multi-tasking OS, it would likely end up with a mixture of RISC and CISC features, and a few things we have not even imagined yet. It certainly would not look like the x386, but I think it would have a comprehensive instruction set, floating point, matrix operations, and lots of registers, in multiple banks that can be switched rapidly, and a special interprocessor bus for multiprocessing (remember the Transputer?) But the main things would be fine-grained control of write access to memory, and the various other security features which are now thought to be a good idea.
The battle will run for ever, the semiconductor manufacturers will fight on, to the benefit of everyone else.
I do wish they would give more attention to reduced power consumption, but that is another thing altogether.
So, classified documents should be typed in a fixed-point font, and maybe have double spaces added at random. Might not look so nice, but this kind of attack will be impossible.
Of course it is fairly stupid to reveal a part-censored document anyway.
That is not the point. The Twice Convicted Monopolist is effectively charging their customers (not me, ever again), for the costs of their criminal activities. That is contrary to the justice system of just about every civilised society. It makes crime pay. It also allows the criminal (for that is what these scumbags are) to profit openly from his crime.
Basically M$ have the morals of a big-time drug dealer, and just like many of the drug dealing cartels, are allowed to get away with it by the wilfil connivance of government. The law in the US will remain in utter disrepute until Gates, Ballmer and a few others are where they belong, in jail.
Ah yes, the eternal debate about monolithic vs modular kernels, in a slightly different guise, and a worthy topic of debate. At least this time, the minimalist microkernel has not been mentioned (yet?). Since I use Linux, OpenBSD and FreeBSD, I have seen their several approaches, they all have their limitations.
Personally, I dislike loadable modules, although my Linux kernels are modular, there are so many errors in the kernel config scripts that if you try to build a minimalist highly-optimised kernel, incorporate some extra drivers permanently, or even remove a few bits that should not be needed, everything breaks, or rather, the build process breaks. There are certain dependencies between diverse things which should not be there. I wil find out tonight if 2.6 is any better, there was a steady increase in build difficulties all the way through the 2.2 and 2.4 series.
Now, the FreeBSD kernel configuration is also broken, my last attempt at a complile failed, at least one source file was missing (likely they forgot to put it on the CD). I have not needed to compile an OpenBSD kernel yet, because that is on a simple machine used as a firewall.
So what has that got to do with whether drivers are in the kernel or not, you may ask? Well, everything and nothing, the point is that first you have to get a robust configure and build process, whether it builds a huge monolith or a modular kernel hardly matters, as long as it works every time, which neither Linux nor FreeBSD do.
But, the tighter the control of the kernel interfaces, the potentially better security, so a modular kernel with the driver modules living in userland would likely be most secure, but slowest. An optimised monolith should be fastest, less indirection and so on, but how do you manage the security, or for that matter even the functional aspects of a kernel which can be built in a million different ways? I don't know of any commercial software with a semi-automated build process which has so many options as a kernel, getting such a thing correct is a huge exercise, so I would favour the topology which minimises the difficulty of doing so, whatever that might be. I would prefer a relaible build process, which resulted in a fully functional and secure kernel, even if it took twice as long to compile, and had a 10% performance penalty.
My suspicion is that we need to see the SCOundrel code to see how it should be done... (only joking!). Seriously, there remains a lot to be done in terms of kernel design, while we still have Unix. It will not be around for ever, something entirely new is bound to be invented to replace it, but will not be called Longhorn.
I hope the microkernel concept has now died. Clearly it was a good way to throw away performance, and it did not solve any problems, because all the external modules for filesystems and so on would still need to be absolutely secure, it was simply creating interfaces between modules for the sake of it. But, as things go in and out of fashion, it will be back, just as CISC is currently in fashion, but RISC will be back......
What we definitely do not need is an abomination which pretends to be an OS, where the API set is scattered throughout a huge assortment of uncontrolled.dlls, making it impossible to achieve either reliability or security. The Twice Convicted Monopolist has demonstrated very clearly how not to do it, I think the whole Linux and xBSD world has learned those lessons long ago.
Please, US voters, get rid of the psychotic little moron this time, so that he can no longer prop up Tony B. Liar. I don't want to wait till the next UK election to get rid of our local malignant dictator.
Of course, it will not entirely fix things, our next PM might be the idiot who recommended Sir Monopolist Bill for his knighthood.
Sad, but true, money talks..... Sir Bill could afford to buy half of Africa (the troubled half, with despots like Mugabe ruining everything, I think the good bits would be beyond a man of even his means), I think India might be a bit more valuable, but he could still probably buy a sizeable chunk.
However, the Indians are capable of turning out good software without outside assistance, I would hate to see their country's reputation tarnished by the likes of M$.
Obviously then you would approve of the Twice Convicted Monopolist, or the SCOundrel, moving to India, as nothing they have done involves creativity or innovation.
The US would be much better off without people like that, they are truly un-American, but I don't think that any other part of the world would want them either.
It actually has a worse track record than most, but my opinion is based on first-hand experience of some of its avionic systems, which are rather ill-conceived. The explanation for the cause of the second accident was also somewhat incorrect, showing that they did not really understand the issues with the flight control computers, but these are not the bits I have direct experience of. Yes, it's performance is quite impressive, for a pile of junk.
Don't get me started on Eurofighter (or a few other things)....... Suffice it to say that the Swedes did slightly better, certainly in terms of project management. IMHO the JSF approach is better than either, there is a lot less gross stupidity by systems designers, they are making positive efforts to keep it simple and use existing commercial technology.
That is not what control engineers understand by hard real time. Yes, your audio was no doubt arriving at the DAC with less than the necessary 200pS jitter (assuming 16 bits, it would be about 12ps at 20 bits, which is well-high impossible to achieve with standard technology), due to well-designed hardware timing, but your latency must have been large. BTW I have designed digital audio systems, albeit for communication management, not hi-fi, so I do understand the issues.
In a control system you can't afford any appreciable latency, so you can't buffer data for more than one timer tick, and the necessary calculations really have to be done on a regular deterministic schedule. Often you need something like 20ms scheduling, with no appreciable sampling jitter, that is easily achieved by a RTOS, or some minimal custom software, but never by any conventional OS. You have to get all the inputs synchronously, and deliver outputs again synchronously to the timer interrupt, which you need to use to schedule the thing. You have to calculate all your lags and integrators and such like within the time frame every time.
If you build a control system using hardware to do what should be done in proper software, you might as well have no software at all.
I have designed control systems also, I did not write the code, but I specified in minute detail how the one hardware interrupt from a timer would control the scheduling, and I designed the I/O hardware to get the inputs into memory, and the outputs out, synchronously. It was actually easy, the Motorola TPU and QSPI peripherals on their microcontrollers are very useful indeed, when you are using serial ADC and DACs. It could not have been made to work on any existing OS, even with source code, except maybe a real time OS, but in fact the OS requirements of control systems are generally minimal. But, for stable control, we really had to achieve 10mS end to end, regularly, and we got that.
I think that to get stable control of a ships rudder might not need 10ms scheduling, maybe 50ms would do, but you are limited by the need to close the loop round the hydraulic servo, there are lots of bandwidth and stability issues, and you still need a truly deterministic schedule. (M$ appears to have managed the amazing feat of putting non-deterministic code in their OS!) It gets worse if you use electric actuation, the characteristics of motors are such that to get good stiffness you need high loop gain, which places limits on the amount of time delay......
Actually, a good example of what is needed in a control system would be to consider an audio system, with which you are clearly familiar, but for real-time use in live performances, where the equalisation is done by things like FIR filters in the software. Now slow it down by a factor of about 50. (of course no-one uses digital EQ in a live situation, because at the LF end you need so much time to do the EQ calculations, several samples at say 30Hz, that the delay makes it useless anyway, no-one is going to sit and listen to a 100ms or so echo.) Still it can't be done, unless you have a deterministic scheduler.
Don't know about that, but the systems I was once familiar with were not exactly examples of good engineering. They had no proper EMC standards, and bad electrical bonding between the skin panels, so flying in mediocre conditions used to cause milions of minute electrical discharges that zapped some of the avionics and crashed the computers in others. Then there was the fly-by-wire rudder, introduced as an emergency measure when the SAAB 2000 was found to be uncomfortably heavy for the pilots..... I have never heard of such a radical change being introduced towards the end of a flight test program.
Basically, getting it right requires good cooperation between the airframe manufacturer and the avionics suppliers, and good engineering competence on both sides, same as procuring anything technical, so that the customer, in this case SAAB, actually gets what he needs, not what he thinks he wants. It evidently did not happen. At a much later date, I was involved in fixing some of the problems, so I do know. It could have been done right, or nearly so, the first time, if they had got their requirement specifications somewhere near correct.
Sadly it is a familiar story, lots (but still a minority) of engineering projects go badly wrong because the requirements were ill-defined or kept being changed at too late a stage. Windoze is a fine example of the latter, every version seems to suffer creeping featurism right up to the end. If Sir Bill was acpable of rigorously defining his requirements at the beginning, and not changing them at random, his progrtammers might be able to get it more nearly right. And yes, Sir Bill is to blame personally, his title is "Chief Software Architect", it is his job function that is being done incompetently.
Oh, just remembered, I did drive a SAAB belonging to ny boss once, can't remember where the ignition key went, but the gearlever knob kept coming apart in my hand, it seemed to be made from an excessive number of pieces. Most people use a simple, reliable solid ball with a tapped hole, but SAAB had been too clever....
It makes me sick to see how often fools, imbeciles and idiots attempt to use an OS which has no real-time capability whatsoever to do real-time work.
NT is known for freezing for periods of up to 10 seconds (maybe more?) at random intervals, quite probably while it defrags the mess it has got its memory into. The same problem happens with Win2000 and I have also seen longish freezes in XP. Controlling a ship, or anything lese for that matter, needs hard real time.
Not only that, in most countries, evidently not Sweden, the software would have to be capable of validation and verification to a suitable standard, that can of course only be accomplished if you have source. The currently fashionable standard assigns criticality levels Sil1 to SIL4, now NT can't even meet SIL1 (SIL4 is the highest, mandatory in life-threatening situations). Previously, lots of people followed the aircraft industry in assigning levels 1,2,3,4 or A,B,C and D (in these cases 1 or A was required in potentially life-threatening cases). An extra level, Z, was introduced, guess why?
I once upon a time thought that the Swedes were generally competent, however with the JAS39 Grippen, and now this, I think that their defence industry has become a complete joke. I could tell you about their SAAB civil aircraft, fortunately they are out of production now.....
The problem is that they will simply kill themselves some other way. It is tragic when a child dies needlessly but if you protect them too much, they never gain any sense of danger, then when they are old enough they have some major disaster. No extreme approach really works, best that they are trained and supervised until they can see for themselves how to avoid danger, and of course the equipment should be made as safe as possible (soft materials, no sharp edges and so on). Children should perhaps be made aware of this accident and how it happened. When I was young, we all knew who had fallen off which roof and broken his leg, so we did not go there, we also knew how to abuse one particular multi-person swing in the local park (a sideways one, prior art!), so it would eject its occupants, because we knew what would happen, we did not do it. Children can be taught to avoid danger, it may take some time, and it helps if they only see adults behaving responsibly, such as crossing the road carefully.
It is really up to the parents to train their children well, sadly many parents nowadays are simply not up to the task, or more commonly, really don't have the time if both need to work, which is common.
Swings should not be banned, although it may happen. A consequence of doing that is that older children will hang an old car tyre from the branch of a tree using any old bit of rope they can find, and use that as an improvised swing. That is somewaht more dangerous, they often swing over an uneven surface so the drop at one extreme, if the rope breaks, can be large, there is no provision for a soft landing, etc.
Of course they would have to include the BSOD and lots of new bugs and security holes, otherwise no-one would believe it was a genuine product of the Twice Convicted Monopolist.
And mine, as long as the browser is Mozilla, not Incompetent Exploder! But I will not be dogmatic, Opera and Konqueror are OK, amongst others. I have not tried all the others.
I would think that in any case, Mozilla is a good place to start, being open source. There is a chance here for FOSS to overtake the Monopolist in a very obvious way, as opposed to the subtle features of the OS which most users don't know or care about, where M$ is about 20 years behind state of the art.
When you think about it, a browser displays text and graphics, and receives user input, possibly in multiple windows, that is all that a GUI needs to do, so conceptually you could have just some sort of framebuffer in which the browser draws its output, and a kernel of course. No X, because you only have one full-screen application all the time. All graphical applications would be browser plug-ins, some already are. I really like simplicity.
The clever bit (all the rest already exists, and is probably very clever too) would be how to define the extra protocols and APIs needed to make the browser efficient for input.
But I think this is an old concept, either Sun or Netscape was going to do away with the OS some years ago, it never happened, although I think that doing away with X and the window manager would be a better place to start, for this type of situation, you do need them elsewhere.
I was getting bored with software, everything seemed so static for a while, but it looks as if we are on the verge of major change, and I don't mean Longhorn.
Just had a thought, doesn't the Amaya browser do some of this, in a very basic way, i.e. it also edits the HTML in situ? I can't check right now, as I only have a boring NT4 machine in front of me here, with no admin privilege, but seem to remember trying it once, it effectively would edit a web page if you had permission. And, a Wiki is a bit like editing a file remotely.
Oh, just had a thought..... (careful, I must not overdo it!). Remote editing, old style, may have a lesson for us. I used to run a Tektroxix 8560, way back in 1984 or so, which ran a Unix V7 derivative, wonderful for its day. Now, that had a rather good editor called ACE, which unlike ed was full screen (text only of course) and ran very well on a 9600 baud serial line, but it needed certain facilities on the terminal which a VT52 had not got (we user Lear Seigler ADM32As IIRC), specifically the ability to insert a character at the cursor, and move the rest of the line along. Now it occurs to me that this simple feature shows that to do remote editing of anything, you need to do the same, i.e. transmit only changes, and have a protocol at each end which keeps the data in step. Now, for ASCII text it was easy (BTW the editor set the tty to "raw" mode, so every keystroke was read immediately without waiting for a \n, so the poor old LSI 11-23 was worked quite hard sometimes), and most importantly, the cursor and text on the screen tracked the user's input quite quickly, as echo was turned off. It would not be very much harder to do something similar for XML as any modern thing would use. HTTP at the moment can only send complete files, an enhancement to the protocol to insert and delete would be almost the only extension necessary. The full image of the document or whatever would only exist on te client machine, the server would simply have an XML file. Actually, both would have copies of the file, they would periodically do CRC checks or whatever on portions to see that they agreed, and send corrections only if needed. I think it would work OK at 9600 baud for word processing or spreadsheets, or for that matter, vector graphics, but no-one in their right mind would do photo editing over a slow link. Even then, only sending changes, it might work, e.g resizing an image would only send a short command.
I think it would work much better than Citrix, which AFAIK has to send complete Windoze GDI calls across the network, as it has to operate between the application and the screen.
But what about the general public, within a large radius. Do they have the choice? That is the point, if some imbecile kills himself, that might be regarded as his affair, but he will likely kill a number of innocent people too.
This will be sooner, rather than later, simply because all the proper control and experience which exists in the aviation industry is not being applied here. This is going much too far, and may kill innocent people a log way from the launch site, in which case no-one will win but the lawyers.
In this day and age there is no justification for reversion to unnecessary risks which would probably have alarmed the Wright brothers.
I am all for progress, but only by properly funded and controlled organisations, without the competitive motive. It only guarantees disaster.
Slashdot Mirror
It is not double standards, although I believe it tends to give a very wrong message to most of the general public, who have never heard of the inverse square law, and might be deceived into thinking that using mobiles anywhere on the premises is safe, when all the evidence says that it is not.
Please, everyone, read and understand what the inverse square law is all about, it is not rocket science (Google should be able to help...), it is a useful thing to know in all sorts of circumstances, and is the main reason that the ignition hazard, and the probable health hazard is from the mobile on your ear or in your pocket, rather than the base station 50 feet away, even if the mobile radiates 1.5 watts and the base station up to 50 watts.
The presence of one or more mobiles in the room may not directly cause a crash, it may simply use up some of the system's immunity to internal noise. Rectification of RF as occurs in any exposed semiconductor also causes level shifts and such like, which can put analogue things like power supplies and their monitor circuits out of tolerance, and maybe cause a reboot.
Then there is the network. Properly balanced UTP should not radiate interference, if it does not radiate, it will not receive it either (reciprocity theorem). But, it relies totally on the balance of the transceivers in the PC and hub. Anyone who has done any EMC testing (I have so I may know a little bit about the subject!) will know that they radiate a lot, at 100MHZ, harmonics and sub-harmonics maainly (on 100MHz network), therefore they are also susceptible.
I know that in my setup at home, one of my sound cards is affected by my mobile, and I think but can't prove that I have had a couple of crashes when I have left it on the desk. (I can prove the crashes, not the cause...).
So, altogether, I would say that use of a mobile, both in theory and in practice, will degrade the reliability of adjacent computer equipment. It is impossible to say without spending a vast amount of time gathering data with and without mobiles present, whether any specific installation will be vulnerable, so it is better to be safe than sorry. And yes, they do annoy people too......
Much later on, in the 1960s IIRC, a manager at Ford in the UK had some petrol (gasoline to all you US /.ers) poured into pools in the concrete-surfaced yard, then a tractor dragged assorted pieces of scrap iron through it for several hours, no ignition! It was concluded that most car fires following accidents are as a result of sparks from damaged wiring, not friction. However, some believe that repeating the Ford experiment with modern unleaded fuel might give entirely different results, as apparently it does ignite more easily, so is more at risk from friction sparks, or RF sparks from mobiles.
I have actually seen someone smoking while filling a lawn mower from a can. I wonder how many times he got away with it before disaster struck. Never seen it at a filling station though.
You can get "intrinsically safe" radio equipment which will not generate a spark, or will keep any sparks safely enclosed, for use in hazardous environments, they have a severely restricted RF output. They also use FM, with peak power the same as the average, and even then probably only about 100mW.
In the case of something like a mobile, with digital modulation, the peak power is the important thing as regards ignition hazards. The peak power of a typical mobile is 1.5 watts and is definitely unsafe.
It amazes me how in the UK, where warning notices are to be seen quite often in filling stations, that imbeciles continue their pathetic and unnecessary conversations while filling. If I see one near me, I move, and quickly...... It is a criminal offence under the petroleum spirit regulations, it is time that it was enforced properly.
BTW most HF/VHF/UHF communications equipment is potentially lethal in these circumstances. I know that cellular base stations are sometimes sited on the premises, they are carefully positioned, and the inverse square law ensures that the signal level at the pumps is well below the safety limit.
It is sad that the general public are so ignorant and ill-informed as to constantly put other people's lifes at risk by this stupid behaviour. In the UK the law requires you to switch off before entering the filling station, off means off, not standby, because if the mobile needs to access the network or respond to an incoming call, its first and unpredictable transmission will be at full power!
Don't get me started on where else they are lethal such as on aircraft, at least one businessman is, very properly, in jail in the UK as a result of his wilful ignorance on that score. If I were the judge, I would have made it a life sentence, because he put so many lives at risk, even when told not to. If stiff sentences were handed out for using mobiles in filling stations, the practice would diminish substantially. It would not stop entirely, there is always some idiot who knows better than the safety legislators.
I saw no evidence, with one possible exception, that the kernel and file system were left half-done in any commercial version. As Unix was not really well funded in the beginning, it was far better to get good but simplistic things working than to go for complex, all-singing, all-dancing solutions that mostly would not be used.
It has changed nowadays, if you look up the Linux or BSD manuals (or probably Solaris, AIX, SCOundrel etc) the modern options to some of the long-established commands have become positively bewildering. I am not sure that it really represents progress, it may have been better to to the 10% of the work to get 90% of the result, and spend the remaining 90% of the work doing 10% of the work on a set of 9 new tools, if you see what I mean, you nay get better value for money by doing a lot of quick things than one big one.
Of course whether you favour quick and simple, or long and complex, and they are both valid point sof view, the thing that must never be forgotten is quality. A simple little tool that does half the job accurately and dependably can be used to accomplish things, a grossly complex thing that does everything including making a cup of tea, but crashes every Wednesday, unless the wind is from the east, is all but useless. And that, I think, must have been the view of some of the original Unix people, which is why you can do good but limited things with sed, awk, and so on. It is easier to string basic bits together with a pipe than to make the universal panacea.
To put it in perspective, I was doing things under Unix V7 around 1983 easily that still can't be done in any M$ software without a major (and I mean major) programming exercise, or of course by using Cygwin, which sadly is not terribly efficient because the undellying OS is so poor (no fork() for example, it has to be emulated). Credit is due to the developers for getting it to work at all, on top of a so-called Posix-compatible OS that isn't.
Yet, sadly I have heard of it being so used, IIRC this has been debated on /. before.
In many countries you would be committing a criminal offence by using non-validated software to control anything that moves and could cause injury, and rightly so.
So, I doubt that the weird APIs are there for controlling machinery, more likely they are there because in the random way he operates, Sir Bill once thought they were a good idea, then found that they were actually useless and was too proud and stubborn to have them removed. The unused and unwanted bloat is likely to be the cause of many of the bugs and security holes, the code tends to be messily commingled with vital bits, in fact the whole of Windoze seems to be structured in the most messy way possible.
It seems that .Net is finally an admission that the Windoze API set was a complete load of rubbish, and it is time to start again, unfortunately sitting it on top of the mess that went before only makes the problem worse, and also sacrifices efficiency.
But you are basically right, the bloat is caused by backwards compatability of the unnecessary kind. Longhorn will be the same, in order to sell it will need to be compatible with the trash that went before, so it will no doubt have an enormous XP emulation layer sitting on top of the new code, to faithfully reproduce the bugs. It is time to call a halt, throw away backwards compatability (except for reading and writing file formats used by applications of course) and start again. But it will never happen until M$ ceases to be significant, the sooner that happens, the better.
But, as chip density increases and word size gets bigger, the CISC vs RISC situation changes. There is also the scenario that a RISC chip reaches a certain level of speed and complexity, then a CISC manages the same. They tend to chase each other, which is good for us end users, in means that both will improve, and that there will be choice.
This has of course been going on since about 1974, the Z80 was in its day almost CISC, while the more minimalist 6502 was tending towards RISC (not quite as we now understand the term, maybe), yet the products they were used in tended to be about equal.
I think that if you were to design a CPU specifically optimised for a multi-tasking OS, it would likely end up with a mixture of RISC and CISC features, and a few things we have not even imagined yet. It certainly would not look like the x386, but I think it would have a comprehensive instruction set, floating point, matrix operations, and lots of registers, in multiple banks that can be switched rapidly, and a special interprocessor bus for multiprocessing (remember the Transputer?) But the main things would be fine-grained control of write access to memory, and the various other security features which are now thought to be a good idea.
The battle will run for ever, the semiconductor manufacturers will fight on, to the benefit of everyone else.
I do wish they would give more attention to reduced power consumption, but that is another thing altogether.
Of course it is fairly stupid to reveal a part-censored document anyway.
Basically M$ have the morals of a big-time drug dealer, and just like many of the drug dealing cartels, are allowed to get away with it by the wilfil connivance of government. The law in the US will remain in utter disrepute until Gates, Ballmer and a few others are where they belong, in jail.
Personally, I dislike loadable modules, although my Linux kernels are modular, there are so many errors in the kernel config scripts that if you try to build a minimalist highly-optimised kernel, incorporate some extra drivers permanently, or even remove a few bits that should not be needed, everything breaks, or rather, the build process breaks. There are certain dependencies between diverse things which should not be there. I wil find out tonight if 2.6 is any better, there was a steady increase in build difficulties all the way through the 2.2 and 2.4 series.
Now, the FreeBSD kernel configuration is also broken, my last attempt at a complile failed, at least one source file was missing (likely they forgot to put it on the CD). I have not needed to compile an OpenBSD kernel yet, because that is on a simple machine used as a firewall.
So what has that got to do with whether drivers are in the kernel or not, you may ask? Well, everything and nothing, the point is that first you have to get a robust configure and build process, whether it builds a huge monolith or a modular kernel hardly matters, as long as it works every time, which neither Linux nor FreeBSD do.
But, the tighter the control of the kernel interfaces, the potentially better security, so a modular kernel with the driver modules living in userland would likely be most secure, but slowest. An optimised monolith should be fastest, less indirection and so on, but how do you manage the security, or for that matter even the functional aspects of a kernel which can be built in a million different ways? I don't know of any commercial software with a semi-automated build process which has so many options as a kernel, getting such a thing correct is a huge exercise, so I would favour the topology which minimises the difficulty of doing so, whatever that might be. I would prefer a relaible build process, which resulted in a fully functional and secure kernel, even if it took twice as long to compile, and had a 10% performance penalty.
My suspicion is that we need to see the SCOundrel code to see how it should be done... (only joking!). Seriously, there remains a lot to be done in terms of kernel design, while we still have Unix. It will not be around for ever, something entirely new is bound to be invented to replace it, but will not be called Longhorn.
I hope the microkernel concept has now died. Clearly it was a good way to throw away performance, and it did not solve any problems, because all the external modules for filesystems and so on would still need to be absolutely secure, it was simply creating interfaces between modules for the sake of it. But, as things go in and out of fashion, it will be back, just as CISC is currently in fashion, but RISC will be back......
What we definitely do not need is an abomination which pretends to be an OS, where the API set is scattered throughout a huge assortment of uncontrolled .dlls, making it impossible to achieve either reliability or security. The Twice Convicted Monopolist has demonstrated very clearly how not to do it, I think the whole Linux and xBSD world has learned those lessons long ago.
Of course, it will not entirely fix things, our next PM might be the idiot who recommended Sir Monopolist Bill for his knighthood.
... such as the output of Redmond?
However, the Indians are capable of turning out good software without outside assistance, I would hate to see their country's reputation tarnished by the likes of M$.
The US would be much better off without people like that, they are truly un-American, but I don't think that any other part of the world would want them either.
Don't get me started on Eurofighter (or a few other things)....... Suffice it to say that the Swedes did slightly better, certainly in terms of project management. IMHO the JSF approach is better than either, there is a lot less gross stupidity by systems designers, they are making positive efforts to keep it simple and use existing commercial technology.
In a control system you can't afford any appreciable latency, so you can't buffer data for more than one timer tick, and the necessary calculations really have to be done on a regular deterministic schedule. Often you need something like 20ms scheduling, with no appreciable sampling jitter, that is easily achieved by a RTOS, or some minimal custom software, but never by any conventional OS. You have to get all the inputs synchronously, and deliver outputs again synchronously to the timer interrupt, which you need to use to schedule the thing. You have to calculate all your lags and integrators and such like within the time frame every time.
If you build a control system using hardware to do what should be done in proper software, you might as well have no software at all.
I have designed control systems also, I did not write the code, but I specified in minute detail how the one hardware interrupt from a timer would control the scheduling, and I designed the I/O hardware to get the inputs into memory, and the outputs out, synchronously. It was actually easy, the Motorola TPU and QSPI peripherals on their microcontrollers are very useful indeed, when you are using serial ADC and DACs. It could not have been made to work on any existing OS, even with source code, except maybe a real time OS, but in fact the OS requirements of control systems are generally minimal. But, for stable control, we really had to achieve 10mS end to end, regularly, and we got that.
I think that to get stable control of a ships rudder might not need 10ms scheduling, maybe 50ms would do, but you are limited by the need to close the loop round the hydraulic servo, there are lots of bandwidth and stability issues, and you still need a truly deterministic schedule. (M$ appears to have managed the amazing feat of putting non-deterministic code in their OS!) It gets worse if you use electric actuation, the characteristics of motors are such that to get good stiffness you need high loop gain, which places limits on the amount of time delay......
Actually, a good example of what is needed in a control system would be to consider an audio system, with which you are clearly familiar, but for real-time use in live performances, where the equalisation is done by things like FIR filters in the software. Now slow it down by a factor of about 50. (of course no-one uses digital EQ in a live situation, because at the LF end you need so much time to do the EQ calculations, several samples at say 30Hz, that the delay makes it useless anyway, no-one is going to sit and listen to a 100ms or so echo.) Still it can't be done, unless you have a deterministic scheduler.
Basically, getting it right requires good cooperation between the airframe manufacturer and the avionics suppliers, and good engineering competence on both sides, same as procuring anything technical, so that the customer, in this case SAAB, actually gets what he needs, not what he thinks he wants. It evidently did not happen. At a much later date, I was involved in fixing some of the problems, so I do know. It could have been done right, or nearly so, the first time, if they had got their requirement specifications somewhere near correct.
Sadly it is a familiar story, lots (but still a minority) of engineering projects go badly wrong because the requirements were ill-defined or kept being changed at too late a stage. Windoze is a fine example of the latter, every version seems to suffer creeping featurism right up to the end. If Sir Bill was acpable of rigorously defining his requirements at the beginning, and not changing them at random, his progrtammers might be able to get it more nearly right. And yes, Sir Bill is to blame personally, his title is "Chief Software Architect", it is his job function that is being done incompetently.
Oh, just remembered, I did drive a SAAB belonging to ny boss once, can't remember where the ignition key went, but the gearlever knob kept coming apart in my hand, it seemed to be made from an excessive number of pieces. Most people use a simple, reliable solid ball with a tapped hole, but SAAB had been too clever....
NT is known for freezing for periods of up to 10 seconds (maybe more?) at random intervals, quite probably while it defrags the mess it has got its memory into. The same problem happens with Win2000 and I have also seen longish freezes in XP. Controlling a ship, or anything lese for that matter, needs hard real time.
Not only that, in most countries, evidently not Sweden, the software would have to be capable of validation and verification to a suitable standard, that can of course only be accomplished if you have source. The currently fashionable standard assigns criticality levels Sil1 to SIL4, now NT can't even meet SIL1 (SIL4 is the highest, mandatory in life-threatening situations). Previously, lots of people followed the aircraft industry in assigning levels 1,2,3,4 or A,B,C and D (in these cases 1 or A was required in potentially life-threatening cases). An extra level, Z, was introduced, guess why?
I once upon a time thought that the Swedes were generally competent, however with the JAS39 Grippen, and now this, I think that their defence industry has become a complete joke. I could tell you about their SAAB civil aircraft, fortunately they are out of production now.....
It is really up to the parents to train their children well, sadly many parents nowadays are simply not up to the task, or more commonly, really don't have the time if both need to work, which is common.
Swings should not be banned, although it may happen. A consequence of doing that is that older children will hang an old car tyre from the branch of a tree using any old bit of rope they can find, and use that as an improvised swing. That is somewaht more dangerous, they often swing over an uneven surface so the drop at one extreme, if the rope breaks, can be large, there is no provision for a soft landing, etc.
Completely and utterly wrong. See http://www.trf.org.au for proof.
Marriage is actually a God-given institution, and nothing to do with Marxism, which is as anti-God as you can get.
Of course they would have to include the BSOD and lots of new bugs and security holes, otherwise no-one would believe it was a genuine product of the Twice Convicted Monopolist.
I would think that in any case, Mozilla is a good place to start, being open source. There is a chance here for FOSS to overtake the Monopolist in a very obvious way, as opposed to the subtle features of the OS which most users don't know or care about, where M$ is about 20 years behind state of the art.
When you think about it, a browser displays text and graphics, and receives user input, possibly in multiple windows, that is all that a GUI needs to do, so conceptually you could have just some sort of framebuffer in which the browser draws its output, and a kernel of course. No X, because you only have one full-screen application all the time. All graphical applications would be browser plug-ins, some already are. I really like simplicity.
The clever bit (all the rest already exists, and is probably very clever too) would be how to define the extra protocols and APIs needed to make the browser efficient for input.
But I think this is an old concept, either Sun or Netscape was going to do away with the OS some years ago, it never happened, although I think that doing away with X and the window manager would be a better place to start, for this type of situation, you do need them elsewhere.
I was getting bored with software, everything seemed so static for a while, but it looks as if we are on the verge of major change, and I don't mean Longhorn.
Just had a thought, doesn't the Amaya browser do some of this, in a very basic way, i.e. it also edits the HTML in situ? I can't check right now, as I only have a boring NT4 machine in front of me here, with no admin privilege, but seem to remember trying it once, it effectively would edit a web page if you had permission. And, a Wiki is a bit like editing a file remotely.
Oh, just had a thought..... (careful, I must not overdo it!). Remote editing, old style, may have a lesson for us. I used to run a Tektroxix 8560, way back in 1984 or so, which ran a Unix V7 derivative, wonderful for its day. Now, that had a rather good editor called ACE, which unlike ed was full screen (text only of course) and ran very well on a 9600 baud serial line, but it needed certain facilities on the terminal which a VT52 had not got (we user Lear Seigler ADM32As IIRC), specifically the ability to insert a character at the cursor, and move the rest of the line along. Now it occurs to me that this simple feature shows that to do remote editing of anything, you need to do the same, i.e. transmit only changes, and have a protocol at each end which keeps the data in step. Now, for ASCII text it was easy (BTW the editor set the tty to "raw" mode, so every keystroke was read immediately without waiting for a \n, so the poor old LSI 11-23 was worked quite hard sometimes), and most importantly, the cursor and text on the screen tracked the user's input quite quickly, as echo was turned off. It would not be very much harder to do something similar for XML as any modern thing would use. HTTP at the moment can only send complete files, an enhancement to the protocol to insert and delete would be almost the only extension necessary. The full image of the document or whatever would only exist on te client machine, the server would simply have an XML file. Actually, both would have copies of the file, they would periodically do CRC checks or whatever on portions to see that they agreed, and send corrections only if needed. I think it would work OK at 9600 baud for word processing or spreadsheets, or for that matter, vector graphics, but no-one in their right mind would do photo editing over a slow link. Even then, only sending changes, it might work, e.g resizing an image would only send a short command.
I think it would work much better than Citrix, which AFAIK has to send complete Windoze GDI calls across the network, as it has to operate between the application and the screen.
But what about the general public, within a large radius. Do they have the choice? That is the point, if some imbecile kills himself, that might be regarded as his affair, but he will likely kill a number of innocent people too.
In this day and age there is no justification for reversion to unnecessary risks which would probably have alarmed the Wright brothers.
I am all for progress, but only by properly funded and controlled organisations, without the competitive motive. It only guarantees disaster.