Thanks for the info. Is the "concurrent it is not" an implementation detail, or is something that they could change without breaking (too many) cmdlets by running them in multiple threads or something like that?
And then there's a proposal to use JSON to pass around structured data (such as "ls") output - but that's still not quite objects.
I consider JSON to be close enough to objects to fit into that category, though you're right that there are differences. (The one that worries me is the weaker typing, but that's not inherently wrong especially for typical shell pipelines.)
Especially the separation of "data" and "view" pipes - PS doesn't do that, it's always text (which is to say, a String object) in the end
I did notice the separate pipes thing, and I don't know if I appreciate what exactly what he means; I think I'd need to see an example. I'm not sure I like the idea though, if what he means is that a command is going to produce both the text and data outputs, and the receiver just pays attention to whichever one it wants.
Also, one other deficiency of PS is that, so far as I know, it doesn't have the concept of streaming objects - you pass around structures, but they're eager, not lazy. This thing still passes binary streams on the lowest level, so apps can stream properly and process data lazily if they deem it worthwhile.
I'm not sure how PS works in this regard either, though I think calling it eager/lazy isn't quite right. (Can you tell I'm a PL person?:-)) The difference is more whether the commands run concurrently or not: if I say foo | bar, can bar proceed on foo's partial output? (True laziness would be that bar controls execution and foo only ever runs long enough to produce enough data to satisfy bar *right now*, then gets suspended again.)
Now, Wikipedia's comparison of command shells does have PS down as "objects/concurrent" for how the pipes work, so assuming that's accurate and not misleading (because it, for instance, has sequential object pipes but concurrent text pipes), that doesn't actually arise in practice.
Good thing those don't always do the same thing then. (Though fortunately I now have access to a new enough version of Grep that my main use case for where they differ is obviated.)
It generally doesn't bother me that much, but I guess if, as long as output that needs to line up vertically can be made to do so, variable-width fonts aren't too bad.
What I'm thinking is more adaptive... the application should specify how things should be rendered, the terminal should guess when it doesn't, and the user should be easily able to override either decision easily.
I strongly suspect that a program could make a really good guess as to whether to treat as text and render variable-width or treat as characters and render as monospace. There're a lot of hints: how much of the text is in an English dictionary (or other natural language), how much spacing there is between words, where hard line breaks fall, etc.
Then you can use another tool to filter the object from the first to the second if you have object piping. And it'll probably be easier because you don't have to parse crap.
I've considered the first idea to be basically a no-brainer for some time and hopes it becomes common in the Linux world. I like the second idea, but you're right that it's less compelling. I'm also not enamored with some of the decisions he's made.
But I think looking beyond the standard terminal is something that does not get nearly as much attention. There's a lot of things you could do. For instance, I don't like reading actual text in the terminal, because the default line wrapping sucks and monospace font isn't very good for that task. There's other text formatting you could do as well, like bolds or different sizes or something. So it'd be nice to render that in proportional fonts. Or, from the link, the fact that we do progress bars with ======== is pretty silly.
I think there's a lot you could do to make the Unix CLI more friendly even for experienced users. That said, I'm not sure that TermKit is quite on-target with some of at least its default decisions.
The same thing that happens when the text format output by one program isn't understood by the text input format of a second.
Object piping isn't a magical cureall for compatibility between programs, but don't pretend that text is either. What objects do is eliminate the need to parse stuff in what is half the time a broken manner. (Ever run something like "find... | xargs" without using -print0 and -0? It's buggy.)
I disagree. I view the big pro of a command line is composibility of programs -- and this doesn't do anything to hurt that. (At least once a few equivalents to the standard utilities are built up.) In fact, I personally suspect widespread use of something like this would make it easier to compose, but that would have to wait over time.
And while I don't know if it supports scripts, there's no fundamental reason it couldn't do that either.
That's not really fair on two points. First, TermKit combines two different "re"-envisionings of the shell. The first is object-piping. That is very Powershellish, though TermKit does things in a rather different manner behind the scenes. The changes have a few different tradeoffs which I'm not sure I fully appreciate.
The second part though is moving beyond a text interface, and Powershell really doesn't do this. There is a new terminal built around PS called POSH that is moving in this direction, but TermKit seems to take it even further.
In short, the ideas are not fundamentally new, but very little ever is. There are some specifics that appear to be, and he's actually gotten it working, which is a far cry from almost everyone who came before.
Being able to bypass them is a testament to their bad implementation......my understanding is that ASLR's implementation isn't the best, but IMO it's more like "is a testament to the fact that needing ASLR at all is patching a gunshot with a bandaid".
And you say C++ is insecure and has stupid control structures, but then suggest writing it in C? Really?
By the same token, "works the same way as what Ken Thompson decided in 1970" does not mean better. In the case of Powershell's object pipes, I give a number of benefits.
[Disclaimer: I have only a little experience with Powershell, and certainly don't use it on anything like on a regular basis.]
It's not different in the sense that they are little programs that you write and primarily interact with from the shell. Where the big difference comes into play is that when you pipe one cmdlet to another, what gets piped is objects, not text.
This has a number of useful benefits. First, they are strongly-typed. Second, no parsing is needed on the receiving end -- and this means fewer possibilities for introducing bugs. (E.g. how many times do you see people actually use 'find... -print0 | xargs -0' instead of just 'find... | xargs'?) Third, the scripts have access to.Net natively, which will give you way more than any shell script (though not more than, say, Perl).
I think a fourth benefit is most intriguing, though this is mostly speculation on my part. Lets say you have a shell pipeline 'foo | bar'. There are many times under the Unix way that the way you invoke 'foo' depends on what you want to follow it in the pipeline, but under Powershell it needn't. Why not? Take ls for example. Suppose that you wanted to list the files in the current directory, sorted by size (and say for the moment that ls couldn't do this by itself, so you want to send it to some 'sort'). Under the Unix way, you'd have to do something like 'ls -l | sort...'. Note that you had to pass -l to ls. In the Powershell world, the ls equivalent I think just spits out a sequence of objects that represent files in the current directory. If you just type 'ls', by default it would just print the file name. But those other fields are still there for things later in the pipeline to access if they need to. So with my hypothetical example, you can eliminate the -l argument.
Money Island is in the "additional games" section at the end. I'm not sure, but I sort of get the impression that those were chosen by the Smithsonian's own judges instead of popular vote.
If MS can kill the stylus and make a touch UI on top of the Windows Explorer shell that doesn't suck, they could have something.
The sad thing to me about that statement is you're probably right... I have a convertible tablet with a stylus now, and I love it. I use OneNote for note taking, and it's one of the only pieces of software that I use that I actually mostly like using. (I hate most software.) Take away the stylus and you take away most of the reason I have a tablet.
I don't want to dispute your overall point, but I do think that 'print' and 'print preview' being in the file menu make fine sense. What are you printing? The file. I don't have an older version of Word installed, but OpenOffice's menus are File, Edit, View, Insert, Format, Table, Tools, Window, and Help. The only one besides 'file' that even remotely makes sense is 'tools', and that's pretty far out. So 'print' in the 'file' menu is fine I think.
As for 'print preview', if features lived in isolation, then yes, 'print preview' in the 'view' menu would make sense. Unfortunately, they don't, and it is more important that 'print' and 'print preview' are next to each other than 'print preview' is in the most logical spot on its own.
And the fact that 'print' is under 'file' in almost every other program under the sun means that moving both commands to the 'view' menu is the wrong move.
If you want to pick on one of those, it's that the 'page setup' dialog, where you go to do things like format the margins, is under 'file' instead of 'format'.
Besides, anyone who knows how to take advantage of the extra features won't have any problem downloading it except in the complete absence of an internet connection. It's not like it's a 100 MB download with an installer or something like that. Sure, it's an extra step, but it's almost always a really easy extra step.
I can think of some other issues as well. Even though MS owns the code, that doesn't mean it's been vetted to the extent that other Windows components have. I can see Process Explorer doing some really nasty, fragile stuff internally.
You can't blame the voters for the two-party system; such a system naturally falls out of our election method: non-proportional, one-vote, winner-takes-all. If you want more than two viable parties, that's where you should be looking.
Re:Fructose is processed like a toxin, that is tru
on
Is Sugar Toxic?
·
· Score: 1
The big name fruit juice brands add sweeteners...
Um, maybe some do; Tropicana doesn't.
I like the Simply Apple, for example. It tastes much better than the typical "from concentrate" crap and it is healthier.
Simply Orange "Grove Made" (high pulp) also has 0 fiber too. (Simply Apple as well, but that's more obvious.)
Re:Fructose is processed like a toxin, that is tru
on
Is Sugar Toxic?
·
· Score: 1
That's all fair... I just have one addition. If you're going to have the OJ, why not just eat the orange? If you won't, I'm not going to try to discourage you from that 4oz glass or whatever, but if you will, that'll be better for you than the juice.
I made a few changes in my diet a year ago or so, and replacing drinking a fair bit of juice with the actual fruit instead (actually mostly grape juice to eating apples) I suspect had a big effect.
What I meant was "saying calories in vs calories out" doesn't do anything to say whether your choice of food affects your metabolism.
Then you eat less to cut your calories in, and exercise more to increase your calories out. If this is done persistently, with a significant calorie deficit, it will always work.... But you are a human, not an insect. You can choose to eat or not.
Yes, it's true, but what I'm saying is that if you actually want to get people to do it, it pays to make it easier. If you say "you can choose to eat (and be fat) or be hungry", how many people are going to choose "constant hunger"? What if that choice becomes "modify your diet a bit so you can still eat the same amount, but of more nutritious food, and you won't be hungry?" Now all of a sudden it becomes way easier.
The reason people talk about calories in > calories out is that there are 10,000 fake diets out there that tell you you can eat ice cream and chips all day and lose weight. Just buy my book or my pills or whatever. They don't work, and people don't like being swindled.
This is a fair point, and it's a good reason to push that idea somewhat. That being said, it's not the whole story.
Re:Sugar is not only toxic but it's addictive.
on
Is Sugar Toxic?
·
· Score: 1
The timecube guy didn't spend 90 minutes citing refereed journal articles supporting his point.
I'm not saying he's right, but to lump Lustig's presentation in with the timecube is just as crazy as the timecube guy. While there a couple rebuttals around, there's certainly nothing that has made me say "ah, this is a slam dunk, Lustig's wrong."
It definitely seems likely that there's a strong element of truth in what he says, but it's not as extreme. Compare to the anti-fat craze. Over time, we've found out that there are "good fats" and "bad fats". The "all fats are bad" mantra turned out to be wrong, but it's pretty well accepted that you should limit intake of saturated fats (and those dreaded trans fats). There's likely not something completely analogous in this situation -- I don't think there are multiple kinds of fructose, so we can't have "good fructose" and "bad fructose" -- but perhaps our understanding of the effects on the body will be refined instead. (Alternately, maybe this could be the refinement: "fructose is the bad sugar.") I dunno.
But if you want to talk about lunacy, sure, just go ahead and dismiss him out of hand...
Slashdot Mirror
Try using a clicky keyboard and you will know why it is better.
Because the sound drives you insane enough that you think it's better? :-)
Thanks for the info. Is the "concurrent it is not" an implementation detail, or is something that they could change without breaking (too many) cmdlets by running them in multiple threads or something like that?
MS has a couple legit free licenses; both the MS-PL and MS-RL are copyleft (though of course GPL incompatible).
Not everything up there is under one of those of course, but it's not like everything is under a shared source license or something like that.
And then there's a proposal to use JSON to pass around structured data (such as "ls") output - but that's still not quite objects.
I consider JSON to be close enough to objects to fit into that category, though you're right that there are differences. (The one that worries me is the weaker typing, but that's not inherently wrong especially for typical shell pipelines.)
Especially the separation of "data" and "view" pipes - PS doesn't do that, it's always text (which is to say, a String object) in the end
I did notice the separate pipes thing, and I don't know if I appreciate what exactly what he means; I think I'd need to see an example. I'm not sure I like the idea though, if what he means is that a command is going to produce both the text and data outputs, and the receiver just pays attention to whichever one it wants.
Also, one other deficiency of PS is that, so far as I know, it doesn't have the concept of streaming objects - you pass around structures, but they're eager, not lazy. This thing still passes binary streams on the lowest level, so apps can stream properly and process data lazily if they deem it worthwhile.
I'm not sure how PS works in this regard either, though I think calling it eager/lazy isn't quite right. (Can you tell I'm a PL person? :-)) The difference is more whether the commands run concurrently or not: if I say foo | bar, can bar proceed on foo's partial output? (True laziness would be that bar controls execution and foo only ever runs long enough to produce enough data to satisfy bar *right now*, then gets suspended again.)
Now, Wikipedia's comparison of command shells does have PS down as "objects/concurrent" for how the pipes work, so assuming that's accurate and not misleading (because it, for instance, has sequential object pipes but concurrent text pipes), that doesn't actually arise in practice.
Good thing those don't always do the same thing then. (Though fortunately I now have access to a new enough version of Grep that my main use case for where they differ is obviated.)
It generally doesn't bother me that much, but I guess if, as long as output that needs to line up vertically can be made to do so, variable-width fonts aren't too bad.
What I'm thinking is more adaptive... the application should specify how things should be rendered, the terminal should guess when it doesn't, and the user should be easily able to override either decision easily.
I strongly suspect that a program could make a really good guess as to whether to treat as text and render variable-width or treat as characters and render as monospace. There're a lot of hints: how much of the text is in an English dictionary (or other natural language), how much spacing there is between words, where hard line breaks fall, etc.
Then you can use another tool to filter the object from the first to the second if you have object piping. And it'll probably be easier because you don't have to parse crap.
I've considered the first idea to be basically a no-brainer for some time and hopes it becomes common in the Linux world. I like the second idea, but you're right that it's less compelling. I'm also not enamored with some of the decisions he's made.
But I think looking beyond the standard terminal is something that does not get nearly as much attention. There's a lot of things you could do. For instance, I don't like reading actual text in the terminal, because the default line wrapping sucks and monospace font isn't very good for that task. There's other text formatting you could do as well, like bolds or different sizes or something. So it'd be nice to render that in proportional fonts. Or, from the link, the fact that we do progress bars with ======== is pretty silly.
I think there's a lot you could do to make the Unix CLI more friendly even for experienced users. That said, I'm not sure that TermKit is quite on-target with some of at least its default decisions.
The same thing that happens when the text format output by one program isn't understood by the text input format of a second.
Object piping isn't a magical cureall for compatibility between programs, but don't pretend that text is either. What objects do is eliminate the need to parse stuff in what is half the time a broken manner. (Ever run something like "find ... | xargs" without using -print0 and -0? It's buggy.)
I disagree. I view the big pro of a command line is composibility of programs -- and this doesn't do anything to hurt that. (At least once a few equivalents to the standard utilities are built up.) In fact, I personally suspect widespread use of something like this would make it easier to compose, but that would have to wait over time.
And while I don't know if it supports scripts, there's no fundamental reason it couldn't do that either.
That's not really fair on two points. First, TermKit combines two different "re"-envisionings of the shell. The first is object-piping. That is very Powershellish, though TermKit does things in a rather different manner behind the scenes. The changes have a few different tradeoffs which I'm not sure I fully appreciate.
The second part though is moving beyond a text interface, and Powershell really doesn't do this. There is a new terminal built around PS called POSH that is moving in this direction, but TermKit seems to take it even further.
In short, the ideas are not fundamentally new, but very little ever is. There are some specifics that appear to be, and he's actually gotten it working, which is a far cry from almost everyone who came before.
Being able to bypass them is a testament to their bad implementation... ...my understanding is that ASLR's implementation isn't the best, but IMO it's more like "is a testament to the fact that needing ASLR at all is patching a gunshot with a bandaid".
And you say C++ is insecure and has stupid control structures, but then suggest writing it in C? Really?
By the same token, "works the same way as what Ken Thompson decided in 1970" does not mean better. In the case of Powershell's object pipes, I give a number of benefits.
[Disclaimer: I have only a little experience with Powershell, and certainly don't use it on anything like on a regular basis.]
It's not different in the sense that they are little programs that you write and primarily interact with from the shell. Where the big difference comes into play is that when you pipe one cmdlet to another, what gets piped is objects, not text.
This has a number of useful benefits. First, they are strongly-typed. Second, no parsing is needed on the receiving end -- and this means fewer possibilities for introducing bugs. (E.g. how many times do you see people actually use 'find ... -print0 | xargs -0' instead of just 'find ... | xargs'?) Third, the scripts have access to .Net natively, which will give you way more than any shell script (though not more than, say, Perl).
I think a fourth benefit is most intriguing, though this is mostly speculation on my part. Lets say you have a shell pipeline 'foo | bar'. There are many times under the Unix way that the way you invoke 'foo' depends on what you want to follow it in the pipeline, but under Powershell it needn't. Why not? Take ls for example. Suppose that you wanted to list the files in the current directory, sorted by size (and say for the moment that ls couldn't do this by itself, so you want to send it to some 'sort'). Under the Unix way, you'd have to do something like 'ls -l | sort ...'. Note that you had to pass -l to ls. In the Powershell world, the ls equivalent I think just spits out a sequence of objects that represent files in the current directory. If you just type 'ls', by default it would just print the file name. But those other fields are still there for things later in the pipeline to access if they need to. So with my hypothetical example, you can eliminate the -l argument.
Money Island is in the "additional games" section at the end. I'm not sure, but I sort of get the impression that those were chosen by the Smithsonian's own judges instead of popular vote.
I believe they do NXDomain crap, but I use OpenDNS. They do it too but I have at least chosen them
Consider Google DNS if that's important to you. They don't do NX Domain hijacking near as I can tell. That's what I use, for that reason.
If MS can kill the stylus and make a touch UI on top of the Windows Explorer shell that doesn't suck, they could have something.
The sad thing to me about that statement is you're probably right... I have a convertible tablet with a stylus now, and I love it. I use OneNote for note taking, and it's one of the only pieces of software that I use that I actually mostly like using. (I hate most software.) Take away the stylus and you take away most of the reason I have a tablet.
I don't want to dispute your overall point, but I do think that 'print' and 'print preview' being in the file menu make fine sense. What are you printing? The file. I don't have an older version of Word installed, but OpenOffice's menus are File, Edit, View, Insert, Format, Table, Tools, Window, and Help. The only one besides 'file' that even remotely makes sense is 'tools', and that's pretty far out. So 'print' in the 'file' menu is fine I think.
As for 'print preview', if features lived in isolation, then yes, 'print preview' in the 'view' menu would make sense. Unfortunately, they don't, and it is more important that 'print' and 'print preview' are next to each other than 'print preview' is in the most logical spot on its own.
And the fact that 'print' is under 'file' in almost every other program under the sun means that moving both commands to the 'view' menu is the wrong move.
If you want to pick on one of those, it's that the 'page setup' dialog, where you go to do things like format the margins, is under 'file' instead of 'format'.
In addition, can you think of the support calls?
Besides, anyone who knows how to take advantage of the extra features won't have any problem downloading it except in the complete absence of an internet connection. It's not like it's a 100 MB download with an installer or something like that. Sure, it's an extra step, but it's almost always a really easy extra step.
I can think of some other issues as well. Even though MS owns the code, that doesn't mean it's been vetted to the extent that other Windows components have. I can see Process Explorer doing some really nasty, fragile stuff internally.
Besides, it's not quite right. While Ubuntu doesn't have any, Fedora has 6 projects.
You can't blame the voters for the two-party system; such a system naturally falls out of our election method: non-proportional, one-vote, winner-takes-all. If you want more than two viable parties, that's where you should be looking.
The big name fruit juice brands add sweeteners...
Um, maybe some do; Tropicana doesn't.
I like the Simply Apple, for example. It tastes much better than the typical "from concentrate" crap and it is healthier.
Simply Orange "Grove Made" (high pulp) also has 0 fiber too. (Simply Apple as well, but that's more obvious.)
That's all fair... I just have one addition. If you're going to have the OJ, why not just eat the orange? If you won't, I'm not going to try to discourage you from that 4oz glass or whatever, but if you will, that'll be better for you than the juice.
I made a few changes in my diet a year ago or so, and replacing drinking a fair bit of juice with the actual fruit instead (actually mostly grape juice to eating apples) I suspect had a big effect.
Except if you want to lose weight.
What I meant was "saying calories in vs calories out" doesn't do anything to say whether your choice of food affects your metabolism.
Then you eat less to cut your calories in, and exercise more to increase your calories out. If this is done persistently, with a significant calorie deficit, it will always work. ... But you are a human, not an insect. You can choose to eat or not.
Yes, it's true, but what I'm saying is that if you actually want to get people to do it, it pays to make it easier. If you say "you can choose to eat (and be fat) or be hungry", how many people are going to choose "constant hunger"? What if that choice becomes "modify your diet a bit so you can still eat the same amount, but of more nutritious food, and you won't be hungry?" Now all of a sudden it becomes way easier.
The reason people talk about calories in > calories out is that there are 10,000 fake diets out there that tell you you can eat ice cream and chips all day and lose weight. Just buy my book or my pills or whatever. They don't work, and people don't like being swindled.
This is a fair point, and it's a good reason to push that idea somewhat. That being said, it's not the whole story.
The timecube guy didn't spend 90 minutes citing refereed journal articles supporting his point.
I'm not saying he's right, but to lump Lustig's presentation in with the timecube is just as crazy as the timecube guy. While there a couple rebuttals around, there's certainly nothing that has made me say "ah, this is a slam dunk, Lustig's wrong."
It definitely seems likely that there's a strong element of truth in what he says, but it's not as extreme. Compare to the anti-fat craze. Over time, we've found out that there are "good fats" and "bad fats". The "all fats are bad" mantra turned out to be wrong, but it's pretty well accepted that you should limit intake of saturated fats (and those dreaded trans fats). There's likely not something completely analogous in this situation -- I don't think there are multiple kinds of fructose, so we can't have "good fructose" and "bad fructose" -- but perhaps our understanding of the effects on the body will be refined instead. (Alternately, maybe this could be the refinement: "fructose is the bad sugar.") I dunno.
But if you want to talk about lunacy, sure, just go ahead and dismiss him out of hand...