worldwide internet threat map

I never programmed Pascal, but pseudocode-based and interpreted languages (like Python) are a lot safer than running machine code on existing architectures.

I kind of like Python, because it's a lot like Basic.

I've met too many old guys who think that nothing will ever change. Some tube guys gave up electronics because they couldn't understand transistors.

At this point, isn't it pretty obvious JL is just trolling?

Rick C.

Possibly because it's off-topic, do you think? :)

Nothing new under the sun in electronic design. There aren't any more Colpitts, Millers or Hartleys coming down the line. It's all been done. :(

I remember you saying about 20 years ago here that you weren't the least interested in operating systems! What's changed??

-- This message may be freely reproduced without limit or charge only via the Usenet protocol. Reproduction in whole or part through other protocols, whether for profit or not, is conditional upon a charge of GBP10.00 per reproduction. Publication in this manner via non-Usenet protocols constitutes acceptance of this condition.

There's truth in that, but it is entirely reasonable to be hostile to half-baked half-expressed ideas that conflict with solid theory.

I, and others, have seen far too many "revolutionary ideas" that are only "revolutionary" because history has been forgotten (or disguised), or theory not understood.

There's an awful lot of that in the software domain.

Extraordinary claims require extraordinary proof.

I do "work" alone now, but not when I was in HP Labs nor Cambridge Consultants (UK part of Arthur D Little), to name two places you may have heard of.

There was no shortage of ideas; the "problem" was choosing which ones to follow and which to drop.

That was a great "problem" to have!

I toyed with Pascal, and regarded it as a variant of Algol60.

I programmed in C from 82(ish) onwards.

I used Smalltalk professionally starting in 1986, was delighted with it capabilities in a way I never was with LISP nor Prolog. Clearly OOP/OOD was The Way Forward.

Objective-C I quite liked, C++ I loathed.

Modula, Delphi I regarded as me-too copies, and obviously C# is Java without the security, and with a different runtime strategy.

Python is OK, but a bit of a mish-mash. I'm wary that accidentally changing a few whitespace characters will change my program (remember the difference between tab and spaces in makefiles?)

For /hard/ realtime multicore embedded systems, my current preference is xC, since that builds on 40 years of solid theory and experience in a way no other environment does (or even /can/ do).

By and large, I've made few mistakes in selecting which languages to study and ignore.

No, but some of your ideas, as expressed here, are equivalent to solving the halting problem.

Defining "proper" and how they avoid the worst consequences is your next task :)

Capability architectures have been around for many decades, but never commercially. Perhaps their time will come - but not in cost-sensitive embedded systems, unfortunately.

C has become part of the problem, whereas initially it was part of the solution. The committee(s) screwed up by trying to make it simultaneously a high level application language and also a low level embedded language.

And if C++ is the answer, you've asked the wrong question!

Then people run anti-virus programs that waste all that speed.

ISP packet snooping and bad-guy protections at the network level.

Multiprocessor architectures with local cache and serious hardware protections.

Better instruction set architectures and memory management hardware.

Interpreters or pseudocode compilers to avoid running downloaded machine code applications on buggy Intel chips. In both cases, the runtime system could be standardized and safe.

Your ideas are welcome.

The thread is about internet security, which is arguably related to electronic design. The internet uses a lot of electronics.

New circuits keep being invented, but are seldom posted here.

I have a couple of things to post, like my high-jitter oscillator designs, and observations on 1111 capacitors. Maybe later.

Details are necessary to see how the halting problem is avoided.

All modern multiprocessors either avoid the need for caches or have multiple levels of such caches.

The caches are not scaleable beyond a few processors. Basically the cache coherence traffic and latency becomes the limiting factor.

There are some programming paradigms that minimise the problems (especially message passing), but they are relatively unknown and of principal value to only some applications.

I believe MPC will become a dominant paradigm over the coming decades, but I will be dead before then!

None of that is new. As usual, the High Performance Computing brigade is pushing the limits of what is possible in as many directions as they can.

Research their experiences to understand the current pain points.

It needs to be improved. It won't be improved in cost-sensitive applications. Even when improved, it won't solve the problem.

Today's example of the problem is that next Tuesday's Windows10 update appears to delete use files.

Would your proposed concept therefore interfere with the transmission of the updates? What /will/ they trust?

See CAP processors, XMOS xCORE/xC.

That deals with some classes of problem, but not others.

Well, that centralizes control of the internet in "ISP" hands, which is pretty nasty intrinsically. It also is defeated by end-to-end encryption, and by TOR or other anonymizers, so requires obligatory disclosure of all your traffic contents and metadata. The disclosed data, of course, can be used steganographically to bypass the protection.

Police states would like to do this, but aren't very successful at it. I don't cheer at their occasional local victories.

I'm not sure that's true, but there is tons of room for improvement. Seat belts don't guarantee no injuries, but they sure help.

Don't write off improvements because they are not perfect.

Absolutely.

Not me, but one guy who works for me has. He does bare-metal apps that do ethernet and web pages. Absolutely virus-proof. I mostly design hardware these days.

I did write some RTOSs and compilers and stuff. But coding is boring to me, compared to designing hardware, so now I brainstorm architectures and delegate the actual coding. This is an electronic design group.

It is interesting to consider the realtime limits of the code when designing the hardware. Like moving some math into FPGAs to take the load off little ARMs. We do some square-and-average stuff in FPGAs for RMS measurements, and let the ARM take over and do the less-frequent square root and calibrations. But we have one product where the ARM generates DDS sine waves in software, straight into its own DAC.

Last week we decided that an ARM can use its ADC to scan the ground-leg supply current of 12 synchro driver amplifier channels, and shut them down before anything really bad happens, if our customers start shorting things. That's simpler than doing it analog, with comparators and stuff.

Some of our products compute mosfet power dissipation in real time, and calculate junction temperature based on a thermal model. That lets us push the fets really hard. I wrote that code in 68K assembly.

Don't furnish connections to hazards. Don't transport bad web pages. Don't transport email that has viruses inside or linked to. Perform the AV functions at the network level.

Really, that's not too difficult a concept. Some of that is being done now, just not universally and automatically.

Really, typing NEXT isn't such a burden.

Asking ISPs to not deliver infected web pages is equivalent to the halting problem?

Or enforcing i/d space separation? Trapping on a stack overflow? That was standard in some systems decades ago.

Start by never executing data. Your own data, or someone else's.

n,

One thing no one has addressed are business issues. If you buy AVS and it doesn't work, the AVS company protects themselves from legal action by the user agreement. Your only course of action would be to stop paying them an d buy a different brand of AVS. This is enough to spur the AVS companies t o keep current with the threats.

If AVS functioned at the network level, how would you ever hold anyone resp onsible in any way? It is not likely to be done by your ISP as they would not want to add all the extra hardware and would want to push it to the bac kbone providers. At that point it becomes an issue like the government mai ntaining the public street. If they don't do a good job you have no recour se other than paying a repair shop to fix your broken suspension... so you will still run AV software to protect your computers.

It is a silly thing to talk about in such general terms. No one has propos ed solutions because there aren't any obvious ones. There aren't even any subtle ones. But there are LOTS of reasons why it won't work which is what people have been posting.

I don't compare this to the halting problem. I compare it to perpetual mot ion. JL is looking for an over unity solution.

Rick C.

ts of

ewer

efined

take

te

nd

ho

sult

You haven't explained how this would be done! Are they running PCs in para llel with your PC so that every page is imported to them before it is provi ded to you? It's not like stopping drugs at the border. You can't spot an infected web page as the packets stream by unless you buffer it all up. E ncryption prevents you from doing anything with the web pages.

Why are you so dense that you can't understand this? How many people have explained it to you and you still don't get it?

They do that in current systems I thought. That's one of the reasons why W in32Forth is flagged as a virus on many AVS packages. It does things to be efficient. AVS sees that and calls "foul"!

I believe that is the rule. The problem is when the people writing softwar e make mistakes. The stuff you design is not as complex to test so you can build things that don't have so many bugs, but then they do relatively sim ple tasks.

Rick C.

about two seconds after DNS filtering was mandated by court to "protect the children" the politicians and copyright lawyers lined up to have what see as "suspect" IP addresses added to the filter