"iff they required different resources (for example, integer and floating-point)" - this is a bit dated, modern processors have multiple execution units for most things. Hyperthreading was to allow free execution units to be assigned to another thread while the pipeline on the primary thread isn't at the point where it can send instructions to the execution units.
Hyperthreading was a cheap half way house *because* different threads of a process share the same address space, so don't need their own everything's, such as TLBs etc.
Multi-processors/are/ capable of running different processes, as each core will have it's own everything. But, because of this, smart enough OS's will try to keep threads of a single processes to one core (overflowing to the other when it makes sense to) to make use of the cached TLBs etc.
To cut a long story short, I'd say your "No, it's bad information from the GP poster" is unwarranted, the educated mind would class the chip as multiprocess, not multithread, and recognise that Namarrgon's post was a lot more informative and helpful than yours.
(unless anyone wants to tell me that both cores share the same TLBs???)
1. In a development system for compiling source listings into program code for operating a digital computer, said digital computer having a microprocessor and a system memory, said source listings
So once we get nano-processors, patents such as this won't apply?:-p
And where did you study the effects of time travel? No it doesn't matter when it's publicized, as long as it does get publicized. Not publicizing beforehand, and then deciding to not-publicize after the not-successful event, will lead to doubt over whether no one turned up because it wasn't publicized. Just because the not-publicizing occurs after the not-successful event, doesn't mean that it isn't the cause! We are talking about travelling back in time here.
a controlled dose of an NMDA-antagonist could help here... as it cuts off sensory input from your body, you stop thinking about your body, and use the information you have to hand to figure out what you are and what you have etc. So instead of thinking you're a person flying a spaceship around the environment, you could *be* the spaceship (or the spaceship's 'AI') flying around the environment, with no knowledge of the human body you're physically attached to. THAT's escaping reality!
I rarely use the feature anymore (use xvnc server now so I can reconnect and take my session around with me), and when I do, is only ever across private LAN's so encryption 'n secrets would be a bit dumb. (Plus haven't used distro's in years, so dunno how they set things up).
Sometimes the simple solution's sufficient. YMMV.
-2A
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 2, Informative
Or even use the task manager to work with minimised windows!
imagine moving one window over another. The X-server can do this within it's own process. If each app took care of it itself, that's two processes that needs CPU time to perform the same action.
You need [at least] a single entity to manage the whole desktop, to manage where input is sent, where things are drawn (as I said in prev post, each window would need to know which windows are in front of it. Without a single entity managing this, each app would have to communicate with each other app to ask it "do you have a window in front of me?").
This entity could be a server, such as X, or built into the kernel. Inside the kernel is faster as there are less context switches required, but you don't get the protection of running in userspace.
Perhaps being able to upload code into the kernel? Either interpreted bytecode, or a bytecode checked 'n compiled to 'safe' native code?
As for 'messaging the location of your mouse at each instant' - to each running process? How do you know if it's interested? You're better off registering to have events sent to you with the managing entity, so it can tell you when the mouse moves, moves over/out an area, clicks, etc.
Oh one other thing, threads still require a context switch, although reusing the same address space means not having to flush TLD's, you still have to save/restore CPU flags/registers/etc states.
Slashdot - never let the facts get in the way of a good argument! I love it when people say that "xxx OS doesn't even support simple feature yyy", just because they don't know how to do it. Especially when it's as easy as this one!
Or is it so advanced that it requires that display #1 be on the left and display #2 on the right -- that is if I want the mouse cursor to appear in the right place when moving it from display to display?
Right click desktop -> properties -> advanced.
You see both your monitors there. You can drag 'n drop them around each other where they are physically located, monitor 1 can be to the left, right, above, or below monitor 2. Top left pixel on monitor 2 doesn't have to be by top right pixel on monitor 1. Just drag them around!
It's much more appealing when switching from window to window to see the old window quickly tear apart or fold itself away, and the new window to quickly and smoothly slide into place than for the windows to just suddenly change.
That depends on whether your computer's already slowing you down or not. I want an accelerated interface, not one that throws a bunch of extra frames in between the one's I can use. An animated interface is only any good for people who don't use their computers enough to be as fast as it is.
The more people have to wait to see what they already know is there, the more they'll be turned away.
So... you want every single process that draws to the screen to have to deal with talking to the display driver itself? Each application you want needs to have support built in for each graphics card that X would do? How would each window know whether to draw on top of other windows or behind them? How would they know whether keyboard input was meant for them?
You'd need a single process to manage all of that... and guess what?!
Or did you only want to display one application on the screen at any one time?
If you swing a ball round on a piece of string, and as you're doing it, lengthen the string (equivelent to climbing the elevator), the ball has to be travel faster for it to be spinning round the same.
So, up the elevator, you might still be directly above the base of the elevator, but you're horizontal velocity is still a lot faster.
All of this doesn't really matter I s'pose, as it's your velocity relative to the air you're hitting that's important.
If a pilot is lost or confused, blinding him with a bright light is going to help him a lot.
Well what do you suggest blinding him with, mace? How the hell are you gonna spray mace into some guys eyes when he's in a plane thousands of feet above you?
they could just spend an extra coupla quid and put a shape cutout (like, of an arrow) over the laser, so it draws an arrow pointing which direction to go! My mate had all sorts of shapes he could project using his laser over a distance, smiley face (could mean "okay you're going the right way now"), a love heart, a cat, an erm... tin of beans...
Slashdot Mirror
MRSA?
"iff they required different resources (for example, integer and floating-point)" - this is a bit dated, modern processors have multiple execution units for most things. Hyperthreading was to allow free execution units to be assigned to another thread while the pipeline on the primary thread isn't at the point where it can send instructions to the execution units.
/are/ capable of running different processes, as each core will have it's own everything. But, because of this, smart enough OS's will try to keep threads of a single processes to one core (overflowing to the other when it makes sense to) to make use of the cached TLBs etc.
Hyperthreading was a cheap half way house *because* different threads of a process share the same address space, so don't need their own everything's, such as TLBs etc.
Multi-processors
To cut a long story short, I'd say your "No, it's bad information from the GP poster" is unwarranted, the educated mind would class the chip as multiprocess, not multithread, and recognise that Namarrgon's post was a lot more informative and helpful than yours.
(unless anyone wants to tell me that both cores share the same TLBs???)
Assuming that people who aren't travelling aren't moving, but that would be an incorrect assumtion.
1. In a development system for compiling source listings into program code for operating a digital computer, said digital computer having a microprocessor and a system memory, said source listings
:-p
So once we get nano-processors, patents such as this won't apply?
huh, next you're gonna tell me there's no santa
-2A
And where did you study the effects of time travel? No it doesn't matter when it's publicized, as long as it does get publicized. Not publicizing beforehand, and then deciding to not-publicize after the not-successful event, will lead to doubt over whether no one turned up because it wasn't publicized. Just because the not-publicizing occurs after the not-successful event, doesn't mean that it isn't the cause! We are talking about travelling back in time here.
-2A
a controlled dose of an NMDA-antagonist could help here... as it cuts off sensory input from your body, you stop thinking about your body, and use the information you have to hand to figure out what you are and what you have etc. So instead of thinking you're a person flying a spaceship around the environment, you could *be* the spaceship (or the spaceship's 'AI') flying around the environment, with no knowledge of the human body you're physically attached to. THAT's escaping reality!
-2A
cuz not publicizing the event could be the reason that no one turned up!
-2A
I rarely use the feature anymore (use xvnc server now so I can reconnect and take my session around with me), and when I do, is only ever across private LAN's so encryption 'n secrets would be a bit dumb. (Plus haven't used distro's in years, so dunno how they set things up).
Sometimes the simple solution's sufficient. YMMV.
-2A
Or even use the task manager to work with minimised windows!
-2A
imagine moving one window over another. The X-server can do this within it's own process. If each app took care of it itself, that's two processes that needs CPU time to perform the same action.
And imagine the nightmare of transparency!
-2A
You need [at least] a single entity to manage the whole desktop, to manage where input is sent, where things are drawn (as I said in prev post, each window would need to know which windows are in front of it. Without a single entity managing this, each app would have to communicate with each other app to ask it "do you have a window in front of me?").
This entity could be a server, such as X, or built into the kernel. Inside the kernel is faster as there are less context switches required, but you don't get the protection of running in userspace.
Perhaps being able to upload code into the kernel? Either interpreted bytecode, or a bytecode checked 'n compiled to 'safe' native code?
As for 'messaging the location of your mouse at each instant' - to each running process? How do you know if it's interested? You're better off registering to have events sent to you with the managing entity, so it can tell you when the mouse moves, moves over/out an area, clicks, etc.
Oh one other thing, threads still require a context switch, although reusing the same address space means not having to flush TLD's, you still have to save/restore CPU flags/registers/etc states.
-2A
Dunno if gentoo does anything different, but to tell X to allow connection from a host, just run:
xhost +client_address
eg: xhost +192.168.0.1 -will allow connection from that IP address (needs to be run on the machine running the X server)
Appologies if tha's not what you were askin.
-2A
You see both your monitors there. You can drag 'n drop them around each other where they are physically located, monitor 1 can be to the left, right, above, or below monitor 2. Top left pixel on monitor 2 doesn't have to be by top right pixel on monitor 1. Just drag them around!
-2A
The more people have to wait to see what they already know is there, the more they'll be turned away.
-2A
So... you want every single process that draws to the screen to have to deal with talking to the display driver itself? Each application you want needs to have support built in for each graphics card that X would do? How would each window know whether to draw on top of other windows or behind them? How would they know whether keyboard input was meant for them?
You'd need a single process to manage all of that... and guess what?!
Or did you only want to display one application on the screen at any one time?
-2A
While you're taking your time to figure out where the enemy cities etc are, it's off sleeping with your girlfriend :-/
-2A
...that's roughly what I was meaning :-)
-2A
If you swing a ball round on a piece of string, and as you're doing it, lengthen the string (equivelent to climbing the elevator), the ball has to be travel faster for it to be spinning round the same.
So, up the elevator, you might still be directly above the base of the elevator, but you're horizontal velocity is still a lot faster.
All of this doesn't really matter I s'pose, as it's your velocity relative to the air you're hitting that's important.
-2A
-2A
Lasers will be shined into air-traffic-controllers eyes if planes they are partly responsible for enter into restricted airspace.
-2A
"there is a laser guided missile heading towards that dot... I suggest you move away from it. You've got until it hits you."
they could just spend an extra coupla quid and put a shape cutout (like, of an arrow) over the laser, so it draws an arrow pointing which direction to go! My mate had all sorts of shapes he could project using his laser over a distance, smiley face (could mean "okay you're going the right way now"), a love heart, a cat, an erm... tin of beans...
-2A
red-green-red obviously means stop-go-stop!
-2A