Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Re:Indiscriminate antibiotic use in farm animals.. (Score 2) 296

Bingo. There is almost no point trying to limit excess human use of antibiotics beyond current efforts, when agriculture is using them wildly. In this case, the disease is resistant to antibiotics that are mainly used for agriculture. So the problem is definitely agricultural antibiotics.

Comment Re: Not news (Score 1) 219

You need to cite stuff like this. Not everyone is from England. Someone from half-around the world is unlikely to even know where Rotherham even is, and if they do, they may think you are talking about the nearest Rotherham. There is more than one possibility:

- Rotherham in England (correct)
- Rotherham in New Zealand (nearest to me)
- a misspelling of Rotterdam, Netherlends (my first guess)

This sounds like a major local story, but it wasn't a big international story. Britain has had a number of sex-abuse scandals in recent years. However, you can't expect every slashdot reader to remember all of them. In fact, it would be difficult to have a photographic memory of sex-abuse cases world-wide, and remain sane.

Comment Re:Double edged sword (Score 2) 164

Most brake's can't stop the engine. That's why modern engine's have engine-brake interlocks. Engine power is reduced when the brake pedal is pushed.

I had an old pickup with a stuck gas-pedal. The brakes were completely unable to stop the engine. Luckily, it was in winter, and the truck was on ice. The truck went forward until the front tires hit pavement, and then I had time to experiment. It was a rear-wheel drive vehicle and the rear set of brakes were unable to stop the rear-wheels from spinning.

Comment Re:Most depressing thing I've read all week (Score 1) 139

From your example, the hard drive is over 9,000,000 times slower. It's a big reason why virtual memory doesn't really work right anymore. Any quantity of misses, and a mechanical hard drive will not be able to handle the load. Even an SSD is dead slow in comparison to main RAM.

You have a CPU running at 3 GHz, at 3 BILLION instructions per second. And you have a hard drive with an access time of 3ms (which is ... let's say faster than anything I've seen in a HDD). The CPU would have to wait for over 9,000,000 cycles before the HD could even start to answer its request.

Comment Re:Why they are slow? (Score 1) 766

Many internet concepts and services leading up to websites were in use in 1986.

The foundational blocks of the web were being built and developed in the 1980's:
- BBS systems offered real-time communication and interchange, but no graphics.
- Mail forwarders, mail auto-responders, UUCP and USENET offered internet connectivity, but were store and forward.
- Apple's HyperCard system was brought to market in 1987. This created a web-page like experience, however everything was centered around data files.
- The networks were available: TCP/IP links between universities existed.
- The hardware was ready: 32-bit workstations with MMUs and graphics were on the market.

In the 1990's, the web quickly developed:
- The web came on-stream in the early 1990s (1990-1992).
- By the mid-90's, 32-bit PCs were ubiquitous, and many computers could be upgraded to use the web.
- By the end of 1995, Bill Gates had his conversion: the head of Microsoft was saying the web was important.
- At the end of the 90's the basic internet architecture of Linux servers and Windows web-clients was in use everywhere.

Comment Re:Maybe we should mimic civil engineering (Score 4, Insightful) 280

Civil engineers design with a safety margin such that their building's don't fall down. I work with a bunch of them. Civil engineers dread the thought that their building falls down.

What does this mean in terms of software? Software crashes all the time.

Software systems tend to have really complex side effects. Suppose I design a blood pressure monitoring machine for a hospital. It and a hundred other devices let the hospital run much more efficiently. The hospital only needs 1/2 the number of nurses. Now, someone discovers a bug in security camera, penetrates the network, discovers hundreds of Windows XP Embedded devices, and turns the hospital into a malware farm. (Incidents like this have happened.)

The hospital is screwed. It can't suddenly double the number of nurses, and even if you did, the nurses are used to the automated equipment. They don't know how to fall back to the non-networked way of doing things instantly. They are out of practice.

How could an engineer sign off on a system like this?

On one hand, it is running standard and recommended software (like Windows). Software has went through the FDA approval process. However, on the flip side, the hospital is a sitting duck. These embedded devices are hopelessly insecure, and there is no way to secure them against modern network threats.

I don't think we have proper methods of describing and solving modern safety issues in embedded systems. We have no proper method of understanding safety with machines built in one country, running software written two different countries, and then running somewhere else. The safety interactions even in a relatively stand-alone machine can be very tough to understand. These network enabled threats make things really hard.

Comment Re:Opinions are worthless (Score 1) 198

It appears that if you want people to do something useful in an unusual situation, then they need to practice. People get things really wrong in unusual situations. Automated systems screw up in unusual systems too. Airplane investigations are littered with examples of automation "helping" pilots and causing disasters. There are examples of pilots relying on automation, which didn't work and caused a disaster. There are examples of pilots getting confused, ignoring training and automation, and crashing functioning planes.

I think the only common thread is that if you want people to do something useful in an emergency situation, they need training and practice.

Comment Re:Buffers (Score 1) 497

The user may be doing a save operation because the computer is running out of memory. This means a deep-copy may fail during the save operation. If the computer is simply out-of-memory, then the user will be left without a copy of the most recent document. If you are up against a soft-memory limit (the system is paging to disk madly), then the program will appear to stop while the deep-copy takes place. This can be a long-time. Long enough for the user to give up, end-task the application, and then lose his work.

If the data structure is trivial, then it is safe to make the assumption the computer has lots of memory. However, in this case, the save operation will likely be quick so little advantage is gained from multi-threading. If the data structure is huge, then doubling the memory requirements during saves has significant performance advantages. But it is a no-win situation. The huge-data structure situation is also when the user would benefit from the multi-threading.

Improvements over a Multi-Threaded Deep Copy Save

A better solution than doing a deep copy is to duplicate only the bits of the data structure being modified by the user. Options:
a) Under Unix/Linux, do a fork(). If the fork fails, then serially output the file. If the fork succeeds, then a different process was created with a complete copy of the data structure. Save the file in the second process, and then use any IPC mechanism to communicate success or failure back to the parent process. This is a no-cost solution, because the VM subsystem keeps track of all the duplicate and dirty pages for you.
b) Under Windows. Design a thread-safe main data structure. This is hell. Even in Java, it is hell.

Building thread safe main data structures is hard
1. Performance is lost on every data structure access because the software has to check for the thread lock. This overhead can be worse than not having the data structure at all.
2. With modern processors do delayed writes to main memory, and the delays can reach hundreds of clock-cycles. Suppose a thread-locks are placed around a non-thread safe library/data structure on a large program. How do you protect against a Write after Write bug on a multi-core CPU?

Java's thread-locks may protect your code, but you have no idea what is happening in any non-thread safe third-party libraries. At least in C and C++, the debugger will often debug into those libraries and let you know the errors in your ways. In C# with third-party ActiveX controls, or in Java with low-level libraries, you are screwed.

I'm not saying a multi-threaded save can't work. It is a beautiful thing when done right. It is just a hard thing to do. It works best when the data structures are small, simple, tight and easy to understand.

Comment Re:arrogance is tops (Score 3, Interesting) 497

A related problem is that there is no way for the hiring manager to tell the difference between a very good programmer and a good programmer. All of the first year CS resumes say the candidates are skilled in C, Java, and a few more buzzwords. Every software project has a life-cycle, and the better programmers move between projects. This means all the experienced resumes show people with many projects. This makes it hard to tell the difference between a competent person that makes meaningful contributions then moves on, and a less competent person that is a good talker and drifts.

It's a real problem for the hiring manager. It essentially means that you can't pay more for better programmers. Economists even have terms for this. Product differentiation. If you can't show you are an A+ programmer as opposed to an A programmer or a C programmer, then it becomes difficult to make the case that the A+ programmer is worth four C programmers. It even becomes difficult to tell who the A+ programmers are. This tends to drive out experienced programmers into other careers.

This problem really affects software engineers. I can tell the difference between a skilled electrician and an unskilled electrician in minutes. Great architects win awards. Develop a great piece of real-time engineering on a safety-critical system - no one is ever going to see your work. Sure, you might save lots of lives with your code. But the hiring manager for your next job can't tell the difference.

Comment Re:Buffers (Score 3, Interesting) 497

Microsoft wrote a bunch of code, that in hindsight was a really really bad idea. I'm not really sure that the problems were all Microsoft's fault - they probably didn't invent them. They are Microsoft's fault in that they embedded the concepts into the operating system and then widely popularized them.

The big gotchas all have to do with limitations of C, and the twists used to optimize Microsoft's programming for the 8086 architecture. I'm thinking of:

char string[MAX_PATH];
What can possibly go wrong? Especially before MAX_PATH was invented.

malloc() new() and friends
For any non-trivial program, it's almost impossible to get correct. They only really work for something like a C compiler which will allocate a variable amount of memory, do a task, and then end. If you miss a few free() calls along the way - they will be cleaned up when the compiler terminates.

GlobalAlloc(), LocalAlloc() and friends
Just in case you couldn't make it work with malloc, try the operating system version of the call. Using OS calls really opened the window to some famous bugs - OpenSSH comes to mind.

Multi-threading in C
For any non-trivial problem - it doesn't work. Firstly, for any non-simple piece of code, it is tough to do correctly. Secondly, for a trivial piece of code, like a save operation, you need to somehow make the memory being stored immutable for the duration of the save. For most save operations, this defeats the purpose, as the first thing the user wants to do after save is to change the document. Thirdly, if you really need multi-threading, there is a good chance some of your users need parallel-processing across machines. Multi-threaded code and parallel-processing code are not the same things at all.

Embedding code in data.
Firstly, the x86 architecture encouraged this, by not having proper page protections. Secondly, it completely opens the system up to malicious code. ActiveX, JPEG libraries, font libraries, everywhere Microsoft had an API that embedded code in data, it was all exploited.

Comment Re:Windows CE - hmmmm (Score 1) 292

GM did you a favor. I have a Kia with the Microsoft system. An Apple iPhone can crash the system so hard that it needs a full reboot. You have to stop the car, turn the engine-off and restart to get the phone interface working again. The system doesn't work with Android properly either. I assume Microsoft's system must work well with a Zune or a Lumia phone, however I have never seen one to try it out. :-)

Keep the engine stuff separate than the entertainment stuff. If you let Microsoft near your car controls, then it will be like the old Bill Gates compares Windows to a GM car joke.

Slashdot Top Deals

Numeric stability is probably not all that important when you're guessing.

Working...