Interesting that people are more uncomfortable with a 3 hour downtime on gmail than they are with a 3 hour downtime on their local mail server. My guess is that it is the feeling of being out of control. If it is a local problem, there is someone to curse; if it is remote, then you don't even know when it is going to be fixed. This is a good example of how we are psychologically more adverse to unknown failures than we are to known ones.
I can see the lateral thinking in your idea. However, it would actually complicate the engineering, because now every component would be subjected to high pressure, not just the shell. There would be all sorts of unexpected effects. The plastic in semiconductor packages would deform and damage the internals, capacitors would compress and change value, solenoids and motors would have to be filled with oil (which would result in too much frictional loss), optics paths and lighting would be filled with oil, and there would be all sorts of mechanical stresses caused by variations in materials and "in-gassing" of the oil into plastics. It's not that these problems couldn't be accounted for, but the effort would be more than the effort to build the hull.
Interesting that we are so focused on images in our culture (film, advertising, etc), that when we discuss the concept of text-free, we assume it means a GUI. But as anyone who has played charades will know, a visual is often not worth even one word.
If we want to retain the strengths of language, the alternative to a textual interface is an audio one, though you'd have to say it is a number of years away yet (especially the speech recognition side).
I'm not saying that pictures don't have a place (an image of a face can communicate emotion more effectively than a word), but words have an economy that is unrivaled. We are language animals.
Yeah, I'll second that revocation. The problem now is indeed total bandwidth. Although it should be noted that peer-to-peer could help if it were designed to prioritize local links over distant ones (but it isn't now), and if most people are transferring the same stuff (likely with content like commercial video, unlikely with apps like VOIP). Because this isn't quite like water flow: information can be replicated in a distributed way; water can't.
> Why is everyone so blinkered they always assume Microsoft employees are evil and anti-OSS?
Because the employee is speaking for the employer. Microsoft is a company that thrives on buying out software projects and gluing them (with varying degrees of success) into their collection. Their issue with free software projects is that they cannot always buy them out. If the project is not "monetarized", then it cannot be easily manipulated. It is all about corporate control.
Interesting idea, a time-t based (or n-instruction based) interrupt disable. Still a bit open for abuse if it was called too often, but at least a single user task couldn't hang the system for long.
It doesn't typically improve on a basic spin-lock, unless a significant amount of time is being spent in locked code. And turning off interrupts would normally be seen as a heavy-handed way of protecting code, because it affects every other process, even if that process will never access that code (and adds latency to interrupts). But arguably it could reduce the number of process switches where tasks of equal priority are competing for a resources.
Inefficiencies in multitasking settings are often not simple to fix. For example, in a situation where one task is producing an item and another is consuming the item, and both run at equal priority, then you can get the situation where a task switch occurs on every item produced (instead of batching them). If the processing of the item is fast, then the task switch can dominate the time taken. There are hacks that most operating systems use, but it isn't as simple as just making the semaphores go faster.
It comes down to a mismatch between the heaviness of a thread (each having a significant amount of state information) compared to the efficiency of processing code fragments. Current architectures are oriented around processing a single task, not around fine-grained parallelism (and rightly so, since that is how we write our programs). But it does mean that we try to find ways to avoid parallelism (and struggle with how to structure it).
The issue for me is how code fragments should communicate in a highly parallel environment. If, for example, they use queues, then sure, it makes sense to develop hardware that optimizes these queues. But at the moment we don't even know how to write highly parallel programs (except for the problems where we model fields of elements, where the parallelism is obvious and highly regular, such as in fluid flow analysis).
Once we know how we want to write these parallel systems (and kernels are one of the complex and heteregenous examples of what we want to be able to do), then we can start thinking about hardware optimizations. Unfortunately any change in paradigm has major ramifications; for example, moving from stacks to queues would have implications for memory caching strategies (or even whether memory should be distributed rather than global).
I'll respond because it is fantastic to see new people thinking about these issues. But I must agree with twizmer on this - grabbing multiple resources might solve the problem, but it is very clumsy. Some resources (eg storage) may take milliseconds to complete, whereas others (eg graphics) might take only microseconds. Holding up the fast ones while the slow ones complete is very undesirable (for all the reasons twizmer gives).
There are techniques that are used for problems like deadlocks and starvation: changing priorities on the fly; or enforcing mutex ordering; or even 'prodding' deadlocked tasks, but they are somewhat ugly. You'll find chapters in any book on OS design.
The essential problem is that the use of semaphores (and mutexes etc) is a low level way to control multiple processes; it is analogous to using the goto for flow control. There are languages that have attempted to address this (eg Occam or Modula I) with slightly higher level constructs, but they have not become popular, and are not totally radical.
I believe that we will need new programming languages to achieve safer parallelism. My bet would be on a language with message passing primitives (since they fit well with our object oriented models), and perhaps the use of Petri net formalism to prevent deadlocks. I gather that Nokia's phone OS uses this message passing model.
It should be noted that current processor design does not suit efficient message passing (the emphasis is more on an efficient stack, since that corresponds to the procedural flow of control - an exception may be the old Transputer architecture). However, I think the languages need to be developed first, even if they are not efficient to compile; processor development will support the most popular languages (as it has grown to support the use of C and other procedural languages).
Slashdot Mirror
yep, we need mass production of another greenhouse gas~
It's not the step down transformers, it's the linear regulators on the output that are wasteful. Anyway, most power packs are switch mode these days.
The switch mode supplies are less like bricks, but as a colleague of mine says, with a switcher on the mains, you are only 20ms away from disaster.
at least until Russia and the USA start using some of those advanced nuclear tools they have fashioned.
Maybe people don't want to read the unedited autobiographies of boring fascists. After all, there are plenty of interesting fascists out there.
you could run an election...
Interesting that people are more uncomfortable with a 3 hour downtime on gmail than they are with a 3 hour downtime on their local mail server. My guess is that it is the feeling of being out of control. If it is a local problem, there is someone to curse; if it is remote, then you don't even know when it is going to be fixed. This is a good example of how we are psychologically more adverse to unknown failures than we are to known ones.
"Spam, spam, spam, spam, spam, spam, baked beans, spam, spam, spam and spam."
I guess it must have been one of those baked beans kind of days.
I can see the lateral thinking in your idea. However, it would actually complicate the engineering, because now every component would be subjected to high pressure, not just the shell. There would be all sorts of unexpected effects. The plastic in semiconductor packages would deform and damage the internals, capacitors would compress and change value, solenoids and motors would have to be filled with oil (which would result in too much frictional loss), optics paths and lighting would be filled with oil, and there would be all sorts of mechanical stresses caused by variations in materials and "in-gassing" of the oil into plastics. It's not that these problems couldn't be accounted for, but the effort would be more than the effort to build the hull.
I open MS Word documents in OpenOffice and one time it was readable.
Interesting that we are so focused on images in our culture (film, advertising, etc), that when we discuss the concept of text-free, we assume it means a GUI. But as anyone who has played charades will know, a visual is often not worth even one word.
If we want to retain the strengths of language, the alternative to a textual interface is an audio one, though you'd have to say it is a number of years away yet (especially the speech recognition side).
I'm not saying that pictures don't have a place (an image of a face can communicate emotion more effectively than a word), but words have an economy that is unrivaled. We are language animals.
What's a zune?
Can Windows move forward with a secure OS and still keep legacy insecurity? Sounds like a job for PR man.
the bloke was complaining about function nesting and you suggested Lisp?
- partitioning of problems
- well defined interfaces
- trained/experienced software engineers
- adequate time
yeah, I know, it's a dream...kind of loses something in translation, doesn't it...
Yeah, I'll second that revocation. The problem now is indeed total bandwidth. Although it should be noted that peer-to-peer could help if it were designed to prioritize local links over distant ones (but it isn't now), and if most people are transferring the same stuff (likely with content like commercial video, unlikely with apps like VOIP). Because this isn't quite like water flow: information can be replicated in a distributed way; water can't.
And just when I thought bovines were halal, too...
maybe they just haven't been contacted before by people who think that digital watches are a neat idea...
Because the employee is speaking for the employer. Microsoft is a company that thrives on buying out software projects and gluing them (with varying degrees of success) into their collection. Their issue with free software projects is that they cannot always buy them out. If the project is not "monetarized", then it cannot be easily manipulated. It is all about corporate control.
perhaps the first million could go on decoding that cryptic note!
Would you rather that they copy the Mac, or come up with their own ideas. Now that's a scary thought...
...or is no-one that dumb :-)
In some jurisdictions you'd be put on a list just for reading this post on slashdot.
Come to think of it, imagine what they'd do to you if you actually bothered to type a response and pressed sub...
Interesting idea, a time-t based (or n-instruction based) interrupt disable. Still a bit open for abuse if it was called too often, but at least a single user task couldn't hang the system for long.
It doesn't typically improve on a basic spin-lock, unless a significant amount of time is being spent in locked code. And turning off interrupts would normally be seen as a heavy-handed way of protecting code, because it affects every other process, even if that process will never access that code (and adds latency to interrupts). But arguably it could reduce the number of process switches where tasks of equal priority are competing for a resources.
Inefficiencies in multitasking settings are often not simple to fix. For example, in a situation where one task is producing an item and another is consuming the item, and both run at equal priority, then you can get the situation where a task switch occurs on every item produced (instead of batching them). If the processing of the item is fast, then the task switch can dominate the time taken. There are hacks that most operating systems use, but it isn't as simple as just making the semaphores go faster.
It comes down to a mismatch between the heaviness of a thread (each having a significant amount of state information) compared to the efficiency of processing code fragments. Current architectures are oriented around processing a single task, not around fine-grained parallelism (and rightly so, since that is how we write our programs). But it does mean that we try to find ways to avoid parallelism (and struggle with how to structure it).
The issue for me is how code fragments should communicate in a highly parallel environment. If, for example, they use queues, then sure, it makes sense to develop hardware that optimizes these queues. But at the moment we don't even know how to write highly parallel programs (except for the problems where we model fields of elements, where the parallelism is obvious and highly regular, such as in fluid flow analysis).
Once we know how we want to write these parallel systems (and kernels are one of the complex and heteregenous examples of what we want to be able to do), then we can start thinking about hardware optimizations. Unfortunately any change in paradigm has major ramifications; for example, moving from stacks to queues would have implications for memory caching strategies (or even whether memory should be distributed rather than global).
I'll respond because it is fantastic to see new people thinking about these issues. But I must agree with twizmer on this - grabbing multiple resources might solve the problem, but it is very clumsy. Some resources (eg storage) may take milliseconds to complete, whereas others (eg graphics) might take only microseconds. Holding up the fast ones while the slow ones complete is very undesirable (for all the reasons twizmer gives).
There are techniques that are used for problems like deadlocks and starvation: changing priorities on the fly; or enforcing mutex ordering; or even 'prodding' deadlocked tasks, but they are somewhat ugly. You'll find chapters in any book on OS design.
The essential problem is that the use of semaphores (and mutexes etc) is a low level way to control multiple processes; it is analogous to using the goto for flow control. There are languages that have attempted to address this (eg Occam or Modula I) with slightly higher level constructs, but they have not become popular, and are not totally radical.
I believe that we will need new programming languages to achieve safer parallelism. My bet would be on a language with message passing primitives (since they fit well with our object oriented models), and perhaps the use of Petri net formalism to prevent deadlocks. I gather that Nokia's phone OS uses this message passing model.
It should be noted that current processor design does not suit efficient message passing (the emphasis is more on an efficient stack, since that corresponds to the procedural flow of control - an exception may be the old Transputer architecture). However, I think the languages need to be developed first, even if they are not efficient to compile; processor development will support the most popular languages (as it has grown to support the use of C and other procedural languages).