Are you sure that's the case even if you enable the separate directory path completion char? That is, PathCompletionChar in addition to CompletionChar. OTOH, I don't see why that \ would be so hard to type anyway...
Uh, it is a COMMAND SHELL? Of course it's text input based. They also claim that future graphical admin tools will render the equivalent commands in a text field, somewhat like what you describe. But this one certainly uses a text-based interface... The object-orientation is just about how commands interact with each other, especially when piping. Plain text piping between commands (note, not processes, the builtin commands are objects that will generally live in the same process as the shell itself) is a limited special case of this.
Forward slashes has been supported in Windows (and DOS, actually) for ages. Back in 1981, there was certainly no universal "/" standard. DOS didn't go for cloning UNIX badly, it tried to emulate CP/M. / was already used as the command option char (among other things) when directories were introduced for real in DOS 2.0. The Mac did use : in all paths all the way up to MacOS 9. I know that this was only an example, but everything is not *NIX. That was definitely the case during the formative years for the up-to-now current Windows command shell.
Hm, what kind of security do you expect in a shell? But, IIRC, you can run scripts under any.NET permission set, which means that you can emulate stricter permissions than the user you are running under (just like the Java VM does). I think there is also some code signing possible, but it's always a tradeoff, isn't it? It's not exactly like you want to log into some kind of stealth mode to just sign a script you have edited.
Not sure what kind of resizing you are not able to do right now, but anyway the console is independent of what you run in it. It's like asking whether bash allows console window transparency in X.
There is absolutely no reason to expect human remains that deep down. That would be very surprising, as it would take a rather intense geological event to move it down there in the short timespan involved.
I beg to disagree. If you look at the peaks of a dual-core system for a desktop user, you still don't reach 100 %. General GUI responsiveness is goodie-goodie, but halving waiting times would also be good. Remember that a P4 with HT will give much of the responsiveness, so a system that could merge threads in theory, but also split them, would be quite nice. (If you solve the "merging" the problem, it seems trivial to split them up again with quite short notice.)
If your codebase only makes the first OR the second assumption, you can tweak the compiler to like you by defines. If you also assume that sizeof(void*) == 4, you have bigger problems. Note that you can do this in rather innocent ways, like dumping a complete structure on disk, knowing that pointer values will be invalid, but just assuming that the structure will be the same size if you read it back later.
In addition, and this is hellish, a 32-bit MOV is (generally) atomic on x86. You can rely on the high-order word and the low-order word staying together, without race conditions. The memory access semantics are different on x64 and many other platforms. This is not related to 64-bitness per se, you could see if you ported to multi-threaded 32-bit PPC as well, but it will still surface if you do the transition to AMD64/EM64T/x64. Or rather, it will result in an additional one-in-a-million crash in your source, that you'll blame on bad memory chips in the user's machine.
I thought so as well, but when I read the original post, a normal Soviet Russia with viruses, I didn't get it. A joke about viruses being called virii iff country == "Soviet Russia" would be funny, but I didn't interpret it that way.
Well, that's enough of joke analysis for tonight. Gotta write some unit tests.
The only caveat is that it would easily kill performance, and that your reliability statements are bogus. Wired hardware isn't reliable because you handle signals. It's relatively reliable because mistakes are expensive. Implement something like a chess AI or a nice user interface without algorithmic parts and without bugs. THAT would impress me.
Actually, that would be the answer to what to do with code that really is multi-threaded on a CPU like this. Give the OS two states (stack + registers and whatnot) to run threads on, but virtualize that above actual cores, so one thread might totally dominate both cores, especially if the other is just executing HLT. I still think this is vaporware close to vacuum, though.
Since when should a virus use any exploit to be a virus. A classical virus is spreading by infecting other binaries. It doesn't need to be clever in doing it.
And something like phase change cooling isn't just very simple applied mechanics and physics? I find it very hard to see why a reasonably complex algorithm should be lesss "practical" than a reasonably complex mechanical machine.
There are lots of places where $1 an hour would be a very significant blocking point against general usage. In locations where a "normal" Internet cafe is commonplace (and affordable), I think that both this device and the hand-driven $100 laptop would be little more than an oddity.
And it's still not relevant, since I'm not saying that the posts are not needed, but that tags that have nothing to do with the story, are not needed. When, and if, we ever want to search for gay and straight/. stories (somehow more likely than wanting to search for pony stories, I suppose), we will just get these.
I don't feel strongly about it, it's just like I would be irritated by code like:
x++;
x--;
Irritated, simply because it's pointless. (Unless we're dealing with doubles, or close to overflow in a bounds-checking sandbox or any other such case). I'm happy with/. being pink and full of more or less funny stories for a day (or two...). You can't really say I've lowered the SNR much by these comments anyway, so why are YOU bugged by me noting this?
I did nothing earlier today when all posts were "gay". I didn't find it especially funny, but overall, I didn't care. When obviously enough people find reason to tag it as straight AS WELL, it just gets pointless. Of course, we can find that funny as well, and then we can tag along and tag with any word we find in the dictionary, but the tagging might after all be used for searching later on, and a total polluting of everything based on the April 1st posts is, well, not needed.
Ok, this is OT, but it's OT for every SINGLE thread where this is posted, but, guys, just stop tagging every story as gay + straight, even if it's an April fool. It doesn't add anything. If you dislike either of them and want to tag the opposite, use the !something tag instead. Or even !gay AND !straight if you find both irrelevant. Please...
The problem is that some of us actually want a future physical human presence in space. If we never wanted to do that, there would of course be much less reason to ever send physical objects now. And, yes, I think it's quite reasonable to believe that it will pay off.
Slashdot Mirror
Are you sure that's the case even if you enable the separate directory path completion char? That is, PathCompletionChar in addition to CompletionChar. OTOH, I don't see why that \ would be so hard to type anyway...
Just when Riker flirts with the inventor's wife.
Uh, it is a COMMAND SHELL? Of course it's text input based. They also claim that future graphical admin tools will render the equivalent commands in a text field, somewhat like what you describe. But this one certainly uses a text-based interface... The object-orientation is just about how commands interact with each other, especially when piping. Plain text piping between commands (note, not processes, the builtin commands are objects that will generally live in the same process as the shell itself) is a limited special case of this.
Forward slashes has been supported in Windows (and DOS, actually) for ages. Back in 1981, there was certainly no universal "/" standard. DOS didn't go for cloning UNIX badly, it tried to emulate CP/M. / was already used as the command option char (among other things) when directories were introduced for real in DOS 2.0. The Mac did use : in all paths all the way up to MacOS 9. I know that this was only an example, but everything is not *NIX. That was definitely the case during the formative years for the up-to-now current Windows command shell.
Hm, what kind of security do you expect in a shell? But, IIRC, you can run scripts under any .NET permission set, which means that you can emulate stricter permissions than the user you are running under (just like the Java VM does). I think there is also some code signing possible, but it's always a tradeoff, isn't it? It's not exactly like you want to log into some kind of stealth mode to just sign a script you have edited.
I didn't :-)
Not sure what kind of resizing you are not able to do right now, but anyway the console is independent of what you run in it. It's like asking whether bash allows console window transparency in X.
It will be a general download to the OS as well. It's just that the admin scripts shipped with Exchange will rely on it.
There is absolutely no reason to expect human remains that deep down. That would be very surprising, as it would take a rather intense geological event to move it down there in the short timespan involved.
I beg to disagree. If you look at the peaks of a dual-core system for a desktop user, you still don't reach 100 %. General GUI responsiveness is goodie-goodie, but halving waiting times would also be good. Remember that a P4 with HT will give much of the responsiveness, so a system that could merge threads in theory, but also split them, would be quite nice. (If you solve the "merging" the problem, it seems trivial to split them up again with quite short notice.)
- sizeof(int) == sizeof(void*), or
- sizeof(int) == 4
If your codebase only makes the first OR the second assumption, you can tweak the compiler to like you by defines. If you also assume that sizeof(void*) == 4, you have bigger problems. Note that you can do this in rather innocent ways, like dumping a complete structure on disk, knowing that pointer values will be invalid, but just assuming that the structure will be the same size if you read it back later.In addition, and this is hellish, a 32-bit MOV is (generally) atomic on x86. You can rely on the high-order word and the low-order word staying together, without race conditions. The memory access semantics are different on x64 and many other platforms. This is not related to 64-bitness per se, you could see if you ported to multi-threaded 32-bit PPC as well, but it will still surface if you do the transition to AMD64/EM64T/x64. Or rather, it will result in an additional one-in-a-million crash in your source, that you'll blame on bad memory chips in the user's machine.
Well, that's enough of joke analysis for tonight. Gotta write some unit tests.
The only caveat is that it would easily kill performance, and that your reliability statements are bogus. Wired hardware isn't reliable because you handle signals. It's relatively reliable because mistakes are expensive. Implement something like a chess AI or a nice user interface without algorithmic parts and without bugs. THAT would impress me.
Actually, that would be the answer to what to do with code that really is multi-threaded on a CPU like this. Give the OS two states (stack + registers and whatnot) to run threads on, but virtualize that above actual cores, so one thread might totally dominate both cores, especially if the other is just executing HLT. I still think this is vaporware close to vacuum, though.
Mod parent up. It's viruses, nothing else. Please. Certainly no viri*.
Since when should a virus use any exploit to be a virus. A classical virus is spreading by infecting other binaries. It doesn't need to be clever in doing it.
And something like phase change cooling isn't just very simple applied mechanics and physics? I find it very hard to see why a reasonably complex algorithm should be lesss "practical" than a reasonably complex mechanical machine.
Ask them, or everyone who was just as able, but never got enough wealthy patrons, what they would have thought of not being paid.
There are lots of places where $1 an hour would be a very significant blocking point against general usage. In locations where a "normal" Internet cafe is commonplace (and affordable), I think that both this device and the hand-driven $100 laptop would be little more than an oddity.
You carbon-based bags of water bastards!
I don't feel strongly about it, it's just like I would be irritated by code like:
x++; x--;
Irritated, simply because it's pointless. (Unless we're dealing with doubles, or close to overflow in a bounds-checking sandbox or any other such case). I'm happy with /. being pink and full of more or less funny stories for a day (or two...). You can't really say I've lowered the SNR much by these comments anyway, so why are YOU bugged by me noting this?
I did nothing earlier today when all posts were "gay". I didn't find it especially funny, but overall, I didn't care. When obviously enough people find reason to tag it as straight AS WELL, it just gets pointless. Of course, we can find that funny as well, and then we can tag along and tag with any word we find in the dictionary, but the tagging might after all be used for searching later on, and a total polluting of everything based on the April 1st posts is, well, not needed.
Ok, this is OT, but it's OT for every SINGLE thread where this is posted, but, guys, just stop tagging every story as gay + straight, even if it's an April fool. It doesn't add anything. If you dislike either of them and want to tag the opposite, use the !something tag instead. Or even !gay AND !straight if you find both irrelevant. Please...
The problem is that some of us actually want a future physical human presence in space. If we never wanted to do that, there would of course be much less reason to ever send physical objects now. And, yes, I think it's quite reasonable to believe that it will pay off.
Light is also just a wave. It just takes a little more work to tune the frequency to get destructive interference, compared to sound.