Valve could also cater more for Linux users, and port the games natively to Linux. Would it be too hard?
Probably considerably harder than would warrant the return they'd make on that investment, yes. This is the stalemate that companies find themselves in. Although some engines use various methods to achieve cross-platform capabilities, for some companies the return just doesn't justify it.
Games on Linux are suffering because nobody plays games on Linux, and nobody plays games on Linux because they're suffering. It's a horrible Catch-22 situation, but it's just one of those loops (like more vendor support) that's hopefully going to be broken at some point, when it becomes profitable for people to offer Linux desktop systems on a wide scale. The shift appears to be happening now, though, to some degree.
Probably referring to the lack of ability (in the default software) for taking media files back off of an iPod once they're on there. Although this is easily circumvented with third-party software, there doesn't seem a good reason that the ability would be missing in the first place.
No, any company can use the AAC codec and can attach DRM to the format. Apple isn't excluding anybody.
Not DRM that the iPod can read. Apple's DRM can only be used by ITMS, they have refused to licence it to third parties. Weren't they trying to legislate against Rhapsody (or something like that?) for selling DRMed content that the iPod could play?
XP Home is something like $60 (you'll need to excuse me, I'm not American so I'm guessing from a quick online search), and that'd be 12 months of Cedega if it's tied to the subscription like that. I'm still a bit hesitant for things like that, personally.
But here's a question for you. If you're required to give "any other recipients of the Work or Derivative Works a copy of this License", does that mean that the extended work has to be under this license?
I think that that clause is intended to ensure that the distributers of the derived work let people know that the system is based upon a system with a more "free" licence, to ensure that those who buy the derivative work know that these parts (which are likely to be substantial, in this case) are included.
I expect it's something which is perfect wording in legalese but looks funny to us Average Joes and Joannes trying to inspect it. I am not a lawyer, etc., though.
Judging by the title of your parent's post, I think he was more concerned that Taco's "department" was the "stuff-to-read" department, yet the main link is in fact an audio recording...
The only person who's looking silly is the person who's defending the security model of Windows.
I guess when I mentioned its fallacies last time I must've stuttered. Apologies.
Giving Windows to script kiddies is giving them the gun. Giving them MSH is giving them the bullets.
Nah. I just don't buy that argument. The security is lax so we should remove useful utilities? No. Fix the security, don't cripple the platform. Nobody advocates replacing bash with something simpler when an SSH vulnerability is discovered. It's just not a sensible course of action. In this way, though, a finely-grained security model (like that of SELinux, or apparently Windows - I can't say I've used it in any depth, and obviously this doesn't apply to desktop installs where everyone runs as Administrator, seemingly for kicks) helps. There's no need for an overall administrator, each subsection is (can be, that is) controlled by another user. But I digress.
To date, even if Moz did have the vulns that IE does, GNU/Linux distros still don't have the level of big-brother all-encompassing integrated security nightmare OS oversight that Windows has.
I like and use Mozilla (and GNU/Linux). I just don't see why this is such a prime-looking opportunity to you to go on about the security model of a completely different set of systems. I mean, an attacker could probably just install a minimal Cygwin install (and this could be automated) if they really wanted a half-decent command shell. It adds no value to them, since most simple things are easily available through cmd.exe, and more complex things would require pre-written scripts (for which they could use VBScript, rather than binary code) anyway. I just don't see why MSH changes anything on this level.
I hold out hope that Vista cures the security model of Windows. Not much hope, but some. I mean it's only really broken on the desktop (and in IE, but I try to ignore that because defending IE is just laughable). But isn't SELinux trying to implement the sort of "big-brother all-encompassing integrated security nightmare" that works very well in a networked system? Correct me if I'm wrong.
If I were less in control I'd call you all sorts of insulting and intellectually degrading names and every single one of them would be applicable.
You'd only end up making yourself look silly now, wouldn't you. Threatening to degrade someone's intellect by calling them names doesn't seem like a fantastic move to me.:)
So they run the ActiveX exploit through IE. Then get the ability to execute arbitrary code. How does MSH help here? They could use VBScript just as easily, or send an executable payload. This is not a fault in MSH. Hell, the fact that it interacts with ActiveX means... wait for it... nothing! Since once you've gotten in through an ActiveX exploit, you could just run whatever you like! If it didn't interact with ActiveX, you could just execute it! Is any of this getting through to you whatsoever?
This adds no real vulnerabilities, that I can see. If you can give any sort of concrete example I'd very much like to hear it.
And so can all the malware, spyware, crippleware, middleware, trojans, worms, viruses, and anyone with even a mild desire to make life difficult for people around them. I bet it'll be even easier to hide shadow processes on the system from the unwary user thus increasing Microsoft's ability to sell the world's desktop out to corporate marketing departments. Imagine banner ads, not in your browser, but legally (via click through EULAs) on your desktop. There's nothing you'll be able to do about it.
You appear to have neither any knowledge of security (if they're using the shell, they can already execute arbitrary code — convenience methods don't make any difference whatsoever) or.NET (which has consistently been proven secure, and is very well-written), and didn't even read the article. This argument:
Between that line and the information that MSH will interface with other programs through ActiveX I can see a whole new world of exploits.
...is just totally flawed. How, pray tell, does this open a new world of exploits exactly?
Looks good! I'll certainly give it a go, I've not used it before though. I was warned by someone that they'd seen a Python shell replacement, but firstly that was ages ago, and secondly it may not have even been the same project. That looks a little like it might be intended as a Python debugger as well as a shell though, which makes me quite apprehensive, but I'll give it a shot. Thanks for mentioning.
Possible. I wouldn't dismiss it so easily though, it's all to be seen, and it does look like an interesting departure, if nothing else.
Windows has been missing a powerful shell, and although Cygwin helps, it's not really geared to the "Windows view" of filesystems. Whether or not MS would've been wiser creating something which was more of a clone of bash or the likes is a matter of opinion, at least for now, but I feel it's always good to see people at least trying something new.
That's not at all what I meant — Python is designed as a full OO programming language. Its commands for manipulating files and data are buried in libraries, it's fully designed to create programs, not manipulate files directly (although obviously it's possible). Although things like MSH and Python are both erring into each other's territory to some degree, I don't believe they're really the same thing, they have fundamentally different aims and emphasises (or whatever the plural of "emphasis" is, if there even is one).
The tab completion and general poor interface sounds disturbing though, particularly with the fairly long commands (the command names wouldn't be a problem at all with competent tab completion, obviously). It would be disappointing to see something which looks to have so much potential be let down on such a small (but important) feature.
Very true. I think this system could work well though, despite not having used it, but I guess I'll have to give it a go to really know. Kinda worried about the noted limitations of its tab-completion though — that's one feature that I'd, at the very least, find difficult to let go.
As for more arbitrary pipes, there is some degree of good news in the discussion thread which goes along with the article, in particular this little gem:
You can essentially make an alias in MSH that associates a short name with the full path of one of the Cygwin command line apps. It's nice being able to occasionally use awk, sed and grep from the MSH command line.
I'm not sure how far this aliasing can be taken, it's possible it only works on text rather than bitstreams, but it's encouraging that the *nix command line apps can be aliased and seem to "play nice" with the MSH system.
I agree, to some degree, but if you look at how they've implemented object orientation on the command line, it's certainly consistent. On one hand it's easier to apply generic operations to strings, but then there's only so much one can achieve when treating everything as a string.
As a consequence of what you mention, though, looking at the commands it seems as though there are slightly more "basic building block" commands than in the *nix world, with slightly more specific purposes. I'm not convinced it's a bad thing, though, although it could add a little complexity to simpler tasks (it looks as though they've been quite careful at this though).
The fact that UNIX has a larger toolbox is not so relevant when you consider that this is still pre-release — if it's a competent shell, it'll have equivalents to most of the useful functions available to the *nix world before very long.
Slashdot Mirror
Most other players on the market allow this. It does not affect the iTMS files as they are DRMed and tied to a (set of) computer(s).
Probably considerably harder than would warrant the return they'd make on that investment, yes. This is the stalemate that companies find themselves in. Although some engines use various methods to achieve cross-platform capabilities, for some companies the return just doesn't justify it.
Games on Linux are suffering because nobody plays games on Linux, and nobody plays games on Linux because they're suffering. It's a horrible Catch-22 situation, but it's just one of those loops (like more vendor support) that's hopefully going to be broken at some point, when it becomes profitable for people to offer Linux desktop systems on a wide scale. The shift appears to be happening now, though, to some degree.
Probably referring to the lack of ability (in the default software) for taking media files back off of an iPod once they're on there. Although this is easily circumvented with third-party software, there doesn't seem a good reason that the ability would be missing in the first place.
Not DRM that the iPod can read. Apple's DRM can only be used by ITMS, they have refused to licence it to third parties. Weren't they trying to legislate against Rhapsody (or something like that?) for selling DRMed content that the iPod could play?
Yeah, cheers. I'm aware of the various systems, it's just a pity that there's such a need for them at all. Better than nothing, however.
Thanks for the clarification. Still, though, it's annoying.
XP Home is something like $60 (you'll need to excuse me, I'm not American so I'm guessing from a quick online search), and that'd be 12 months of Cedega if it's tied to the subscription like that. I'm still a bit hesitant for things like that, personally.
Not a bad heuristic, really...
...unless you were an imaging professional or similar, yes. But on the other hand, TFTs aren't really suitable (yet) for these people anyway.
I think that that clause is intended to ensure that the distributers of the derived work let people know that the system is based upon a system with a more "free" licence, to ensure that those who buy the derivative work know that these parts (which are likely to be substantial, in this case) are included.
I expect it's something which is perfect wording in legalese but looks funny to us Average Joes and Joannes trying to inspect it. I am not a lawyer, etc., though.
Judging by the title of your parent's post, I think he was more concerned that Taco's "department" was the "stuff-to-read" department, yet the main link is in fact an audio recording...
Were you meaning to reply to me? You seem to be agreeing with me.
Not convinced. You've given no evidence for your opinions on security systems, and they contrast with the research and the the views of the experts.
I'm bored of talking in circles though, we're either going to agree to disagree, or just plain disagree. :)
I guess when I mentioned its fallacies last time I must've stuttered. Apologies.
Nah. I just don't buy that argument. The security is lax so we should remove useful utilities? No. Fix the security, don't cripple the platform. Nobody advocates replacing bash with something simpler when an SSH vulnerability is discovered. It's just not a sensible course of action. In this way, though, a finely-grained security model (like that of SELinux, or apparently Windows - I can't say I've used it in any depth, and obviously this doesn't apply to desktop installs where everyone runs as Administrator, seemingly for kicks) helps. There's no need for an overall administrator, each subsection is (can be, that is) controlled by another user. But I digress.
I like and use Mozilla (and GNU/Linux). I just don't see why this is such a prime-looking opportunity to you to go on about the security model of a completely different set of systems. I mean, an attacker could probably just install a minimal Cygwin install (and this could be automated) if they really wanted a half-decent command shell. It adds no value to them, since most simple things are easily available through cmd.exe, and more complex things would require pre-written scripts (for which they could use VBScript, rather than binary code) anyway. I just don't see why MSH changes anything on this level.
I hold out hope that Vista cures the security model of Windows. Not much hope, but some. I mean it's only really broken on the desktop (and in IE, but I try to ignore that because defending IE is just laughable). But isn't SELinux trying to implement the sort of "big-brother all-encompassing integrated security nightmare" that works very well in a networked system? Correct me if I'm wrong.
You'd only end up making yourself look silly now, wouldn't you. Threatening to degrade someone's intellect by calling them names doesn't seem like a fantastic move to me. :)
Right. ActiveX exploits. Through IE.
So they run the ActiveX exploit through IE. Then get the ability to execute arbitrary code. How does MSH help here? They could use VBScript just as easily, or send an executable payload. This is not a fault in MSH. Hell, the fact that it interacts with ActiveX means... wait for it... nothing! Since once you've gotten in through an ActiveX exploit, you could just run whatever you like! If it didn't interact with ActiveX, you could just execute it! Is any of this getting through to you whatsoever?
This adds no real vulnerabilities, that I can see. If you can give any sort of concrete example I'd very much like to hear it.
I think you just proved his point.
You appear to have neither any knowledge of security (if they're using the shell, they can already execute arbitrary code — convenience methods don't make any difference whatsoever) or .NET (which has consistently been proven secure, and is very well-written), and didn't even read the article. This argument:
...is just totally flawed. How, pray tell, does this open a new world of exploits exactly?
Looks good! I'll certainly give it a go, I've not used it before though. I was warned by someone that they'd seen a Python shell replacement, but firstly that was ages ago, and secondly it may not have even been the same project. That looks a little like it might be intended as a Python debugger as well as a shell though, which makes me quite apprehensive, but I'll give it a shot. Thanks for mentioning.
Possible. I wouldn't dismiss it so easily though, it's all to be seen, and it does look like an interesting departure, if nothing else.
Windows has been missing a powerful shell, and although Cygwin helps, it's not really geared to the "Windows view" of filesystems. Whether or not MS would've been wiser creating something which was more of a clone of bash or the likes is a matter of opinion, at least for now, but I feel it's always good to see people at least trying something new.
That's not at all what I meant — Python is designed as a full OO programming language. Its commands for manipulating files and data are buried in libraries, it's fully designed to create programs, not manipulate files directly (although obviously it's possible). Although things like MSH and Python are both erring into each other's territory to some degree, I don't believe they're really the same thing, they have fundamentally different aims and emphasises (or whatever the plural of "emphasis" is, if there even is one).
The tab completion and general poor interface sounds disturbing though, particularly with the fairly long commands (the command names wouldn't be a problem at all with competent tab completion, obviously). It would be disappointing to see something which looks to have so much potential be let down on such a small (but important) feature.
From the Ars discussion of the article:
Bad example.
Very true. I think this system could work well though, despite not having used it, but I guess I'll have to give it a go to really know. Kinda worried about the noted limitations of its tab-completion though — that's one feature that I'd, at the very least, find difficult to let go.
As for more arbitrary pipes, there is some degree of good news in the discussion thread which goes along with the article, in particular this little gem:
I'm not sure how far this aliasing can be taken, it's possible it only works on text rather than bitstreams, but it's encouraging that the *nix command line apps can be aliased and seem to "play nice" with the MSH system.
I agree, to some degree, but if you look at how they've implemented object orientation on the command line, it's certainly consistent. On one hand it's easier to apply generic operations to strings, but then there's only so much one can achieve when treating everything as a string.
As a consequence of what you mention, though, looking at the commands it seems as though there are slightly more "basic building block" commands than in the *nix world, with slightly more specific purposes. I'm not convinced it's a bad thing, though, although it could add a little complexity to simpler tasks (it looks as though they've been quite careful at this though).
The fact that UNIX has a larger toolbox is not so relevant when you consider that this is still pre-release — if it's a competent shell, it'll have equivalents to most of the useful functions available to the *nix world before very long.