Personally, I think they should've at least looked into cfengine [...]
Maybe they did ? I looked into cfengine for automating our server configurations and my head asploded.
Then I experimenting with it for a few weeks, but I could never quite grok how it was supposed to work and always had the feeling that "this is as much work as managing all the systems manually anyway". It seems extremely capable, but it's very difficult to use if you want to do anything that's more trivial than pushing (or pulling) a bunch of files (for which some rsync fiddling is _vastly_ easier).
Indeed, one should remember that Microsoft don't have any moral qualms about exploiting OSS when it suits them.
Why should anyone have "moral qualms" about using software precisely as its creators wanted it to be used ?
Their first TCP/IP implementation was swiped straight from BSD, something they're not in a hurry to remind anyone.
That's hardly remarkable. Pretty much *everyone's* first TCP/IP implementation was "swiped straight from BSD" (how do you "swipe" something that's free ?).
As for Hotmail, unless things have changed, last I heard, the servers run on BSD too because Windows is too unstable. They hardly walk their talk...
It's well and truly Windows now. On the upside, the first, failed Hotmail migration is probably the biggest reason Windows 2003 is a better product than it would otherwise have been.
As a former Windows programmer, I can assure you that there were many undocumented, aka. secret, aka. internal, API calls which provided functionality not available in any of the documented Windows APIs.
I am not disagreeing there are undocumented APIs. All platforms have "undocumented APIs" in one form or another, and always will. I am arguing that they were never used in a "nefarious" fashion by anyone at Microsoft.
What keeps Patchguard running in the presence of intentionally bad code with full run of the system? What stops code that can and does modify the kernel from turning off or NOPing Patchguard?
It halts the entire machine when something tries to modify it, thus stopping them from doing that.
If the answer is something other than "by obfuscation" it would be educational to hear it.
If you have better alternatives, I'm sure Microsoft's software engineers would be interested to hear about them.
However, the arguments which come out of anti-DRM people et al really come across as being pathetic at times. There is a pervading sense that fundamental human rights are being trampled on, when we are talking about entertainment product. Nobody needs the latest hit singles. Nobody needs box sets, DVD extras, or music libraries of 10,000 songs. We want them.
"Entertainment" == culture. People don't "need" those things, no (but then again, apart from food and shelter, what do people really "need"), but they are a critical part of a mature and functional society.
The entertainment industry, as in any other area of business, relies on supply and demand, and (as I have commented on before in/. threads), the huge amount of piracy which occurs only proves to the entertainment industry that demand is there.
The problem is, mass reproduction and distribution of copyrighted material breaks the supply and demand model, because the supply is infinite.
Anyone who argues against DRM or says the entertainment industry is somehow ripping off "the people", yet fights this through anti-DRM software, or some sort of piracy, or other means of getting the industry product they want on their own terms, they lose some respect from me.
The problem isn't DRM, the problem is the fundamental business models that copyright encourages. It's taken the "digital revolution" with widespread, easy, cheap access to essentially free reproduction and distribution infrastructure to really make this obvious though.
The "fine grained" security isn't used in desktop installations of Windows, only servers.
False.
A configuration semantic (default user is an Administrator) does not change the inherent attributes of the platform.
That the default user in OS X is an "Admin" does not make all the file permissions stopping "non-Admin" users from easily causing damage to the system to disappear.
On most desktops, it's not only customary to run as "Administrator", it's required because most applications won't run right otherwise. Is that the application developers' fault? Maybe, but back in the Win95/98/Me days, multiple users didn't exist, so MS has made this normal and only recently tried to change it.
Not maybe, definitely.
Microsoft have been telling developers to write *mainstream* software that works on multiuser systems since ca. 1997. They put significant effort into making writing software for NT-based and DOS-based Windows similar, with regards to isolating variable data to user-specific areas (per-user profiles, Registry hives, etc). While DOS-based Windows certainly can't _enforce_ system/user/user separation, they have the capabilities for developers to write their software to _respect_ it.
For developers who actually did this, their software works fine on multiuser versions of Windows, in unpriveleged accounts, without modification, even if it was never meant to run on anything except Windows 98.
No developer, anywhere, has had any excuse for writing an application that needlessly requires elevated privileges to run for *at least* the last 5-6 years. Considering that multiuser Window has existed since 1993 and has always been promoted as eventually replacing single-user Windows, I'd argue that timeframe is closer to 9 - 10 years.
Of course, they could add code to their newest OSes to cause applications like this to simply not run at all, but MS won't do anything to hurt its monopoly position which requires that it be compatible with all this software.
Microsoft would get into _vastly_ more trouble from an anti-trust perspective if they started deliberately breaking applications, even if those applications were already broken.
This is before even taking into account customer backlash. Heck, just look at how much press XP's SP2 generated, despite breaking only a handful of applications that were already broken to start with.
As we've discussed, most malware takes advantage of the ease with which executable code can be run from email attachments or web pages.
Running executables directly from modern, up to date email clients is damn near impossible in my experience - and it's _always_ been discouraged (even in the earliest versions of Outlook). The problem has never been that the security risk wasn't understood, but that consumers value convenience significantly higher than security and, since the two are inversely related, convenience took the higher precedence at the cost of making it easier for the user to shoot themselves in the foot.
With the latter, this is an OS-level problem since the internet browser is indeed a component of the operating system, as declared by MS in court. With the former, Outlook and OE are usually bundled with Windows as well, so it's still all part of the same ball of wax.
Bad things that happen in user space at the deliberate behest of end users, are not flaws in OS-level security, unless they circumvent permissions.
Or, on other words, IE (and Outlook Express and Outlook) don't do anything any other application can't do. That they arguably do the wrong thing, does not represent a flaw in, or lack of, OS-level security infrastructure.
A musician should get to decide, because the musician is the one who put time and energy into creating something, even if it is something that has the unfortunate property of being more easily replicable than producible.
Note that as soon as "entertainment" moves from a model of mass duplicated copies to live performance, this argument becomes moot.
People who (rationally and reasonably) oppose the copyright regime do so because they do not believe someone being able to exploit a single piece of work multiple times with, essentially, no additional effort on their part is fair.
Copyright exists solely to artificially impose scarcity on something that inherently has infinite supply. As soon as the "artist" is creating a "product" that *doesn't* have that inherently unlimited supply, the whole argument for copyright pretty much evaporates.
And what does freely copying an artist's music do for the artist?
Increases their popularity.
Also would you guess at whether a service like iTunes would exist if the original Napster had not been pulled down by the entertainment industry?
Of course. No matter what FUD copyright whores like to spew, people *will* choose the legal option if it is quicker, easier and delivers better service than the illegal version.
If you can sell bottled water, you can sell anything. To suggest that a product as desirable as entertainment couldn't be sold, is ridiculous on its face.
They do have a way of making profit; it's called "selling copies of songs".
Why do you feel you have a moral right to charge multiple times for a single piece of work ?
They did it admirably until people worked out how to get songs for free.
Yeah. That would have been back when the first two sticks were banged together. It's called "listening".
Just because it's possible to get songs for free, at the complete cost of those who financed and facilitated their production, does not mean that is something the record industry should "adjust" to. Frankly, I think a lot of the hostility towards the RIAA is more people afraid of them pissing on their free music parade.
In the RIAA's ideal world, people would be automatically charged a fee every time they hummed a few bars of music to themselves.
Copyright is _ludicrously_ skewed in favour of content producers (more accurately, content distributors) and against content consumers. File sharing is a perfectly understandable and reasonable reaction to that injustice.
Obviously, you know little about software if you really think OS X or any other OS would be nearly as susceptible to viruses if they had more marketshare. It's not about marketshare, it's about designing security into the system as a required feature instead of tacking a fake illusion of security on later after too many problems are discovered.
Windows has _more_ security "designed into" it than OS X (eg: Windows has no superuser, Windows has a much finer-grained and pervasive permissions system). This is objective, verifiable fact, and any examination of the internals of both OSes can show it.
Ergo, OS-level security features (or lack thereof) are not a significant contributor towards the disparity of malicious code on both platforms.
(Supporting evidence is that a significant proportion of malware requires user intervention of some sort to get started.)
This goes back to something I say daily... 'develop on the platform you are releasing for'. If you are releasing something for Windows, Mac and Linux, develop and test on all. I myself do web dev and insisted that I use Linux as my desktop since our server is a LAMP install. This has proven useful since the other developers using Windows have had several problems with end of line characters in Windows causing issues with files as well as our versioning control system. Always develop and test on the platform you are releasing for.
On the flipside, only doing this dramatically increases the chances your code will rely on a specific implementation rather than the objective specification.
PatchGuard, quite simply, is "security through obscurity".
No, it's not. Saying PatchGuard is "security through obscurity" is like saying passwords, etc are "security through obscurity".
Basically, while the kernel is running, a hidden background thread continuously hashes the code sections of the kernel and validates that nothing has changed. If something changes, the system bugchecks (blue screens). PatchGuard's security comes from it being obfuscated.
No, PatchGuard's security comes from not allowing unknown code to execute in kernel space. Ie: it stops things like rootkits from functioning by crashing the OS when it detects unauthorised activity.
PatchGuard doesn't offer true security.
No one measure offers "true security". PatchGuard is just another part of a layered security model.
It has nothing to do with escalation of privilege - if you're able to modify the kernel, it's already too late.
No, only if you *actually can* modify the kernel, is it already too late [for the kinds of attacks PatchGuard is protecting against]. Which is why the system crash-dumps - because there's not much else you can do in the face of an attacker who has already reached that level of privilege.
PatchGuard was intended to stop commercial products from patching the kernel because frequently they do so improperly, and end up causing instability and local privilege elevation exploits. If a company got around PatchGuard, their product would only work until the next second Tuesday. However, rootkit authors may not care about that "time limit".
PatchGuard is there to stop malicious and unknown interceptions of low-level system calls. In other words, the kind of stuff rootkits (in addition to badly written, but legitimate applications) do.
In the ideal world, if Windows were secure, there would be loads of competition for email software on Windows, but anti-virus software would just not exist at all.
Rubbish. AV software and OS security are only vaguely related.
Only the inane ramblings of technically incompetent hacks has caused the clueless to think that "no viruses" and "secure" are synonyms. Anyone remotely knowledgable understands that AV software and OS security are solutions to almost completely different problems that go hand in hand, not one against the other.
This makes me wonder what all the complaining is really about.
The complaining is about Symantec and McAfee having to rewrite their software _properly_ and use public APIs rather than just rehashing the same POS every year that hooks into undocumented parts of the Windows kernel at will.
There's two sides to this issue. From the security vendor's standpoint, MS is just making it harder for them to work with Vista.
Indeed. Now, instead of just trundling around wantonly in kernel space with their buggy software, they'd have to actually stick to known and documented APIs. The horror !
While there are locking down the OS somewhat, MS will be releasing competing security products.
Which use the same APIs available to _all_ "security software" vendors.
Despite Slashdot folklore, the whole "secret APIs make Microsoft software work better with Windows" has never been more than an urban legend.
On the other hand, Trend Micro has been able to work through the changes in Vista.
Exactly. Which tells you everything you need to know about the validity of McAfee and Symantec's claims.
While I do agree that there is no compelling reason to upgrade to Vista--they fixed nothing that needed to be fixed and added more crap than Congress--please try to validate your arguments.
If, on the other hand, you're one of these people who uses ridiculous sophistry (like saying you primarily use Windows/Linux or some other OS that's not Mac OS X on your new Intel-based Mac, and therefore you should be able to reuse that license on a non-Apple PC), I'd just say that's pretty much bullshit, because if you had an Intel-based Mac, you'd just run Mac OS X on that, instead of using an ugly, ugly hack to shoehorn it into running on non-Apple hardware.
I can think of at least one reason why this argument is perfectly valid - you want better value for money by using OS X on hardware that doesn't fit into one of Apple's 3 market niches.
Yeah, yeah, I know, "What if I have a non-Apple laptop and really want to take Mac OS X with me?" Sure, just keep making things up. I'll tell you what: why don't you find a person who is actually trying to stay legal by doing this imaginary scenario instead of continually bringing this up as a justification?
I can't see any reason why installing a copy of OS X you legally own, that you aren't running on your Mac, should be considered at all morally or ethically wrong. I have an Intel Mac Mini running Windows MCE for my HTPC. Hence, I have a "spare" OS X license that is not being used. Why should feel even the slightest twinge of guilt at installing a hacked up copy onto a clone PC ?
(Not that I have any great interest in doing so for other reasons, but that's besides the point - and I doubt I can even legally sell my unused copy of OS X to someone.)
Right, but this is dangerous (this allows to lure users) and this doesn't bring anything to the user. After all the trouble it caused, why hasn't MS simply made the default to show the complete filename ?
Same reason Apple hides them - because numerous UI studies have shown that most end users don't like them, don't know what they mean and generally find them confusing.
Because an application like a mail reader shouldn't expect to receive executable code from an e-mail.
People use email for exchanging files. Lots of people seem to think this is a bad thing, but nevertheless, that's what it gets used for (largely because there aren't any alternatives that are similarly quick and easy).
So the file shouldn't be executable. Again, a minor tweak that could save people a lot of problems. Why on hell should a data file (a file generated with a "Save As..." dialog) be executable ?
Because *it's an executable binary*.
It would be a minor tweak in default Windows permissions, not to put the "Execute" flag.
And a UI nightmare as people try to figure out why they hell they can't run things.
Ok, so some minor progress from MS...
That happened years ago. Your criticisms would carry more weight if they were a bit more current.
No, sorry this is wrong.
No, it's not. Most GUIs like KDE and GNOME try to identify filetypes by snooping inside them to see what they are (equivalent to the file(1) utility). They typically make no attempt to determine whether or not a binary that just happens to be called "blah.txt" really is a text file.
The mechanism is to associate a file extension with a program to view it.
This is how Windows works.
mpg files are associated with xine or mplayer typically. If you feed mplayer with an executable, it would say something like unknown file format, no codec found for this file, etc... txt files are associated with KEdit, typically. When there is no extension, the file isen't associated with anything and the user can eventually choose a program to open with. But the file is never run.
If you copy a binary (say, xeyes) onto your GNOME or KDE desktop, rename it to something like xeyes.txt then double-click it, xeyes will open (or should, at any rate - it does on Ubuntu). It will *not* open it up in a text editor (which is what Windows would do, because its filetype handling is based on extensions).
I agree for a home PC. (mono-user) Else there are other's users files that are more important.
This discussion is not about managed desktop PCs. They are a completely different ballgame to unmanaged (ie: home) desktop PCs with radically different exposure and risk profiles. Servers are radically different again.
Right... There could be an attack vector here. But this assumes that the user has already executed a rogue executable.
As do most of your Windows examples.
Well, we're talking here about people needing to reinstall Windows every 6 months due to spyware and the like...
Which is basically irrelevant compared to losing, say, twelve months worth of Doctoral thesis work or all the original photos and movies from your daughter's wedding.
Sorry, this does not really work like this.
Yes, it does. A particularly prolific virus could easily infect thousands of Windows machines in a matter of hours.
A software developer first badly codes something.
Virus and malware attacks are frequently not the result of bad coding.
After a delay between hours and years, it's discovered by someone and eventually other people.
Viruses and malware do not typically exploit OS vulnerabilities.
In the open source world, it's then corrected.
If someone can be bothered.
In the Windows world, noone cares to correct this. (In fact, people are typically not even allowed to correct it)
In KDE and Windows, this is not enforced, so I run into the situation of EVERYTHING being hidden in alt+tab.
This is a *good* thing, as it lets you quickly and easily move between *arbitrary windows*, rather than making moving from one arbitrary window to another often a multi-step, multi-key affair.
I have never seen any benefit to OS X's method. If you want to switch between windows within an application (Apple+~), Ctrl+Tab in Windows achieves tihs. If you don't and want to switch between windows in different apps, Alt+Tab does this on Windows, but has no equivalent on OS X. I have never seen any point or benefit in switching to an "entire application" and then raising all its windows to the top of the stack.
Ironically (at least in terms of your attitude), the whole point of Expose is to make Windows-like task switching (between arbitrary windows) easier.
Consider: are subdirectories a good thing? Would you rather everything was in one root directory, each time having to search it for a file you want? No.
Alt+Tab is designed for quickly switching between 2 - 3 windows, as the Z-order is stored in a Most-Recently-Used stack. This was done because that's the typical usage pattern.
Hiding applications is another thing I've never seen the point in, although I can see its usefulness due to how much the Dock sucks at pretty much everything it's supposed to do.
In MacOS, if I go into the system Applications directory, there are maybe 20 programs. I can live with that (do full development, documentation, office work, etc).
Your comparison is broken. Have a look in/usr/bin on your Mac.
In MacOS, applications and their support files and libraries are bundled into.app files I can easily drag into my ~/Applications directory (to install), and delete (to uninstall). Have fun doing that on Linux!
I agree this is an excellent feature, although it must be remembered that Trashed apps can leave files hanging around the system (primarily in the user's home directory), which is one argument for proper uninstallers/package managers.
KDE is great if you are used to Windows, which is a bad paradigm to begin with, but it's trash if you've used a real GUI system.
Please. OS X is as far from GUI nirvana as Windows is. The Dock is a great place to start (a UI train wreck in nearly every respect, albeit becoming more and more irrelevant with every OS X update), closely followed by Finder (horrible for file management in deep and complex directory structures, almost as bad as the old Chooser was for accessing networked resources, but fortunately similarly becoming less and less relevant - it seems Apple's plan is not to fix the things that are broken, but work around them), the poor level of keyboard-accessibility (something Windows has _always_ excelled at), the way some apps quit when their window is closed and others don't and the largely random application of different themes to different applications. I'll mention the overall sluggishness of the UI as well, but that's really an implementation, rather than conceptual or design, problem.
MacOS Classic was a better GUI in nearly every respect to OS X. Relatively minor updates (including making it "lickable") - some of which *are* actually in OS X - would have been the best thing Apple could have done. Instead, it got Steved and has subsequently taken four major releases to work around most of the brokenness.
PatchGuard, quite simply, is "security through obscurity". Basically, while the kernel is running, a hidden background thread continuously hashes the code sections of the kernel and validates that nothing has changed. If something changes, the system bugchecks (blue screens). PatchGuard's security comes from it being obfuscated.
You do not understand what you are talking about.
PatchGuard is not "security by obscurity". "Security be obscurity" would be if, for example, the APIs existed and didn't check for digital signatures, but were undocumented.
Since what PatchGuard does (and how) is documented and known, it is not obscured. It provides security by only allowing known quantities (ie: digitally signed code) certain levels of access.
PatchGuard doesn't offer true security. It has nothing to do with escalation of privilege - if you're able to modify the kernel, it's already too late.
No, it's not, because the kernel commits suicide before you _can_ modify it, therefore protecting itself and the user from damage. When dealing with an attacker that has already reached the point of being able to attempt such an exploit, there's not really anything else it can do.
If you dont believe me do this simple test. Set your view setting to show hidden & system files, go into c:\windown\system32\DLLCache and rename iexplore.exe. Ignore the FUD warning, then go into the explorer folder in the program files folder. Rename iexplore.exe and you will be IE free.
This is like taking the hubcaps off a car and saying "Look ! No wheels !".
This action prevents programs that will attempt to call IE directly from screwing your system.
No, it doesn't.
Microsofts little kernel game here is nothing but that, its a game to shut out the competition, nothing more nothing less.
Microsoft aren't shutting anyone out. As demonstrated by the vendors who have *already* released AV software that works with the published API, as it is supposed to.
Slashdot Mirror
Personally, I think they should've at least looked into cfengine [...]
Maybe they did ? I looked into cfengine for automating our server configurations and my head asploded.
Then I experimenting with it for a few weeks, but I could never quite grok how it was supposed to work and always had the feeling that "this is as much work as managing all the systems manually anyway". It seems extremely capable, but it's very difficult to use if you want to do anything that's more trivial than pushing (or pulling) a bunch of files (for which some rsync fiddling is _vastly_ easier).
Indeed, one should remember that Microsoft don't have any moral qualms about exploiting OSS when it suits them.
Why should anyone have "moral qualms" about using software precisely as its creators wanted it to be used ?
Their first TCP/IP implementation was swiped straight from BSD, something they're not in a hurry to remind anyone.
That's hardly remarkable. Pretty much *everyone's* first TCP/IP implementation was "swiped straight from BSD" (how do you "swipe" something that's free ?).
As for Hotmail, unless things have changed, last I heard, the servers run on BSD too because Windows is too unstable. They hardly walk their talk...
It's well and truly Windows now. On the upside, the first, failed Hotmail migration is probably the biggest reason Windows 2003 is a better product than it would otherwise have been.
As a former Windows programmer, I can assure you that there were many undocumented, aka. secret, aka. internal, API calls which provided functionality not available in any of the documented Windows APIs.
I am not disagreeing there are undocumented APIs. All platforms have "undocumented APIs" in one form or another, and always will. I am arguing that they were never used in a "nefarious" fashion by anyone at Microsoft.
What keeps Patchguard running in the presence of intentionally bad code with full run of the system? What stops code that can and does modify the kernel from turning off or NOPing Patchguard?
It halts the entire machine when something tries to modify it, thus stopping them from doing that.
If the answer is something other than "by obfuscation" it would be educational to hear it.
If you have better alternatives, I'm sure Microsoft's software engineers would be interested to hear about them.
However, the arguments which come out of anti-DRM people et al really come across as being pathetic at times. There is a pervading sense that fundamental human rights are being trampled on, when we are talking about entertainment product. Nobody needs the latest hit singles. Nobody needs box sets, DVD extras, or music libraries of 10,000 songs. We want them.
"Entertainment" == culture. People don't "need" those things, no (but then again, apart from food and shelter, what do people really "need"), but they are a critical part of a mature and functional society.
The entertainment industry, as in any other area of business, relies on supply and demand, and (as I have commented on before in /. threads), the huge amount of piracy which occurs only proves to the entertainment industry that demand is there.
The problem is, mass reproduction and distribution of copyrighted material breaks the supply and demand model, because the supply is infinite.
Anyone who argues against DRM or says the entertainment industry is somehow ripping off "the people", yet fights this through anti-DRM software, or some sort of piracy, or other means of getting the industry product they want on their own terms, they lose some respect from me.
The problem isn't DRM, the problem is the fundamental business models that copyright encourages. It's taken the "digital revolution" with widespread, easy, cheap access to essentially free reproduction and distribution infrastructure to really make this obvious though.
The "fine grained" security isn't used in desktop installations of Windows, only servers.
False.
A configuration semantic (default user is an Administrator) does not change the inherent attributes of the platform.
That the default user in OS X is an "Admin" does not make all the file permissions stopping "non-Admin" users from easily causing damage to the system to disappear.
On most desktops, it's not only customary to run as "Administrator", it's required because most applications won't run right otherwise. Is that the application developers' fault? Maybe, but back in the Win95/98/Me days, multiple users didn't exist, so MS has made this normal and only recently tried to change it.
Not maybe, definitely.
Microsoft have been telling developers to write *mainstream* software that works on multiuser systems since ca. 1997. They put significant effort into making writing software for NT-based and DOS-based Windows similar, with regards to isolating variable data to user-specific areas (per-user profiles, Registry hives, etc). While DOS-based Windows certainly can't _enforce_ system/user/user separation, they have the capabilities for developers to write their software to _respect_ it.
For developers who actually did this, their software works fine on multiuser versions of Windows, in unpriveleged accounts, without modification, even if it was never meant to run on anything except Windows 98.
No developer, anywhere, has had any excuse for writing an application that needlessly requires elevated privileges to run for *at least* the last 5-6 years. Considering that multiuser Window has existed since 1993 and has always been promoted as eventually replacing single-user Windows, I'd argue that timeframe is closer to 9 - 10 years.
Of course, they could add code to their newest OSes to cause applications like this to simply not run at all, but MS won't do anything to hurt its monopoly position which requires that it be compatible with all this software.
Microsoft would get into _vastly_ more trouble from an anti-trust perspective if they started deliberately breaking applications, even if those applications were already broken.
This is before even taking into account customer backlash. Heck, just look at how much press XP's SP2 generated, despite breaking only a handful of applications that were already broken to start with.
As we've discussed, most malware takes advantage of the ease with which executable code can be run from email attachments or web pages.
Running executables directly from modern, up to date email clients is damn near impossible in my experience - and it's _always_ been discouraged (even in the earliest versions of Outlook). The problem has never been that the security risk wasn't understood, but that consumers value convenience significantly higher than security and, since the two are inversely related, convenience took the higher precedence at the cost of making it easier for the user to shoot themselves in the foot.
With the latter, this is an OS-level problem since the internet browser is indeed a component of the operating system, as declared by MS in court. With the former, Outlook and OE are usually bundled with Windows as well, so it's still all part of the same ball of wax.
Bad things that happen in user space at the deliberate behest of end users, are not flaws in OS-level security, unless they circumvent permissions.
Or, on other words, IE (and Outlook Express and Outlook) don't do anything any other application can't do. That they arguably do the wrong thing, does not represent a flaw in, or lack of, OS-level security infrastructure.
A musician should get to decide, because the musician is the one who put time and energy into creating something, even if it is something that has the unfortunate property of being more easily replicable than producible.
Note that as soon as "entertainment" moves from a model of mass duplicated copies to live performance, this argument becomes moot.
People who (rationally and reasonably) oppose the copyright regime do so because they do not believe someone being able to exploit a single piece of work multiple times with, essentially, no additional effort on their part is fair.
Copyright exists solely to artificially impose scarcity on something that inherently has infinite supply. As soon as the "artist" is creating a "product" that *doesn't* have that inherently unlimited supply, the whole argument for copyright pretty much evaporates.
And what does freely copying an artist's music do for the artist?
Increases their popularity.
Also would you guess at whether a service like iTunes would exist if the original Napster had not been pulled down by the entertainment industry?
Of course. No matter what FUD copyright whores like to spew, people *will* choose the legal option if it is quicker, easier and delivers better service than the illegal version.
If you can sell bottled water, you can sell anything. To suggest that a product as desirable as entertainment couldn't be sold, is ridiculous on its face.
They do have a way of making profit; it's called "selling copies of songs".
Why do you feel you have a moral right to charge multiple times for a single piece of work ?
They did it admirably until people worked out how to get songs for free.
Yeah. That would have been back when the first two sticks were banged together. It's called "listening".
Just because it's possible to get songs for free, at the complete cost of those who financed and facilitated their production, does not mean that is something the record industry should "adjust" to. Frankly, I think a lot of the hostility towards the RIAA is more people afraid of them pissing on their free music parade.
In the RIAA's ideal world, people would be automatically charged a fee every time they hummed a few bars of music to themselves.
Copyright is _ludicrously_ skewed in favour of content producers (more accurately, content distributors) and against content consumers. File sharing is a perfectly understandable and reasonable reaction to that injustice.
Obviously, you know little about software if you really think OS X or any other OS would be nearly as susceptible to viruses if they had more marketshare. It's not about marketshare, it's about designing security into the system as a required feature instead of tacking a fake illusion of security on later after too many problems are discovered.
Windows has _more_ security "designed into" it than OS X (eg: Windows has no superuser, Windows has a much finer-grained and pervasive permissions system). This is objective, verifiable fact, and any examination of the internals of both OSes can show it.
Ergo, OS-level security features (or lack thereof) are not a significant contributor towards the disparity of malicious code on both platforms.
(Supporting evidence is that a significant proportion of malware requires user intervention of some sort to get started.)
How come people always cite an unintended "rm -rf /" as the most terrifying and catostrophic event ever?
Because it's short, succint and to the point.
Also because posting a few pages of code to do more interesting things probably wouldn't get past the lameness filter.
This goes back to something I say daily... 'develop on the platform you are releasing for'. If you are releasing something for Windows, Mac and Linux, develop and test on all. I myself do web dev and insisted that I use Linux as my desktop since our server is a LAMP install. This has proven useful since the other developers using Windows have had several problems with end of line characters in Windows causing issues with files as well as our versioning control system. Always develop and test on the platform you are releasing for.
On the flipside, only doing this dramatically increases the chances your code will rely on a specific implementation rather than the objective specification.
This seems like a great way someone to cause my computer to crash.
Considering the alternative, it's a reasonable tradeoff.
It's no different than any other OS that crashes instead of letting rogue code go tromping all over the kernel.
When will the patch come out for this denial of service attack?
Probably as soon as someone can come up with a better way of defending against the more important kernel attack.
PatchGuard, quite simply, is "security through obscurity".
No, it's not. Saying PatchGuard is "security through obscurity" is like saying passwords, etc are "security through obscurity".
Basically, while the kernel is running, a hidden background thread continuously hashes the code sections of the kernel and validates that nothing has changed. If something changes, the system bugchecks (blue screens). PatchGuard's security comes from it being obfuscated.
No, PatchGuard's security comes from not allowing unknown code to execute in kernel space. Ie: it stops things like rootkits from functioning by crashing the OS when it detects unauthorised activity.
PatchGuard doesn't offer true security.
No one measure offers "true security". PatchGuard is just another part of a layered security model.
It has nothing to do with escalation of privilege - if you're able to modify the kernel, it's already too late.
No, only if you *actually can* modify the kernel, is it already too late [for the kinds of attacks PatchGuard is protecting against]. Which is why the system crash-dumps - because there's not much else you can do in the face of an attacker who has already reached that level of privilege.
PatchGuard was intended to stop commercial products from patching the kernel because frequently they do so improperly, and end up causing instability and local privilege elevation exploits. If a company got around PatchGuard, their product would only work until the next second Tuesday. However, rootkit authors may not care about that "time limit".
PatchGuard is there to stop malicious and unknown interceptions of low-level system calls. In other words, the kind of stuff rootkits (in addition to badly written, but legitimate applications) do.
In the ideal world, if Windows were secure, there would be loads of competition for email software on Windows, but anti-virus software would just not exist at all.
Rubbish. AV software and OS security are only vaguely related.
Only the inane ramblings of technically incompetent hacks has caused the clueless to think that "no viruses" and "secure" are synonyms. Anyone remotely knowledgable understands that AV software and OS security are solutions to almost completely different problems that go hand in hand, not one against the other.
This makes me wonder what all the complaining is really about.
The complaining is about Symantec and McAfee having to rewrite their software _properly_ and use public APIs rather than just rehashing the same POS every year that hooks into undocumented parts of the Windows kernel at will.
There's two sides to this issue. From the security vendor's standpoint, MS is just making it harder for them to work with Vista.
Indeed. Now, instead of just trundling around wantonly in kernel space with their buggy software, they'd have to actually stick to known and documented APIs. The horror !
While there are locking down the OS somewhat, MS will be releasing competing security products.
Which use the same APIs available to _all_ "security software" vendors.
Despite Slashdot folklore, the whole "secret APIs make Microsoft software work better with Windows" has never been more than an urban legend.
On the other hand, Trend Micro has been able to work through the changes in Vista.
Exactly. Which tells you everything you need to know about the validity of McAfee and Symantec's claims.
While I do agree that there is no compelling reason to upgrade to Vista--they fixed nothing that needed to be fixed and added more crap than Congress--please try to validate your arguments.
What didn't they fix "that needed to be fixed" ?
If, on the other hand, you're one of these people who uses ridiculous sophistry (like saying you primarily use Windows/Linux or some other OS that's not Mac OS X on your new Intel-based Mac, and therefore you should be able to reuse that license on a non-Apple PC), I'd just say that's pretty much bullshit, because if you had an Intel-based Mac, you'd just run Mac OS X on that, instead of using an ugly, ugly hack to shoehorn it into running on non-Apple hardware.
I can think of at least one reason why this argument is perfectly valid - you want better value for money by using OS X on hardware that doesn't fit into one of Apple's 3 market niches.
Yeah, yeah, I know, "What if I have a non-Apple laptop and really want to take Mac OS X with me?" Sure, just keep making things up. I'll tell you what: why don't you find a person who is actually trying to stay legal by doing this imaginary scenario instead of continually bringing this up as a justification?
I can't see any reason why installing a copy of OS X you legally own, that you aren't running on your Mac, should be considered at all morally or ethically wrong. I have an Intel Mac Mini running Windows MCE for my HTPC. Hence, I have a "spare" OS X license that is not being used. Why should feel even the slightest twinge of guilt at installing a hacked up copy onto a clone PC ?
(Not that I have any great interest in doing so for other reasons, but that's besides the point - and I doubt I can even legally sell my unused copy of OS X to someone.)
I seem to recall that on /., anything Pro-Microsoft is suspiciously Pro-Microsoft.
It's more like anything that isn't obviously anti-Microsoft, is suspiciously pro-Microsoft.
Right, but this is dangerous (this allows to lure users) and this doesn't bring anything to the user. After all the trouble it caused, why hasn't MS simply made the default to show the complete filename ?
Same reason Apple hides them - because numerous UI studies have shown that most end users don't like them, don't know what they mean and generally find them confusing.
Because an application like a mail reader shouldn't expect to receive executable code from an e-mail.
People use email for exchanging files. Lots of people seem to think this is a bad thing, but nevertheless, that's what it gets used for (largely because there aren't any alternatives that are similarly quick and easy).
So the file shouldn't be executable. Again, a minor tweak that could save people a lot of problems. Why on hell should a data file (a file generated with a "Save As..." dialog) be executable ?
Because *it's an executable binary*.
It would be a minor tweak in default Windows permissions, not to put the "Execute" flag.
And a UI nightmare as people try to figure out why they hell they can't run things.
Ok, so some minor progress from MS...
That happened years ago. Your criticisms would carry more weight if they were a bit more current.
No, sorry this is wrong.
No, it's not. Most GUIs like KDE and GNOME try to identify filetypes by snooping inside them to see what they are (equivalent to the file(1) utility). They typically make no attempt to determine whether or not a binary that just happens to be called "blah.txt" really is a text file.
The mechanism is to associate a file extension with a program to view it.
This is how Windows works.
mpg files are associated with xine or mplayer typically. If you feed mplayer with an executable, it would say something like unknown file format, no codec found for this file, etc... txt files are associated with KEdit, typically. When there is no extension, the file isen't associated with anything and the user can eventually choose a program to open with. But the file is never run.
If you copy a binary (say, xeyes) onto your GNOME or KDE desktop, rename it to something like xeyes.txt then double-click it, xeyes will open (or should, at any rate - it does on Ubuntu). It will *not* open it up in a text editor (which is what Windows would do, because its filetype handling is based on extensions).
I agree for a home PC. (mono-user) Else there are other's users files that are more important.
This discussion is not about managed desktop PCs. They are a completely different ballgame to unmanaged (ie: home) desktop PCs with radically different exposure and risk profiles. Servers are radically different again.
Right... There could be an attack vector here. But this assumes that the user has already executed a rogue executable.
As do most of your Windows examples.
Well, we're talking here about people needing to reinstall Windows every 6 months due to spyware and the like...
Which is basically irrelevant compared to losing, say, twelve months worth of Doctoral thesis work or all the original photos and movies from your daughter's wedding.
Sorry, this does not really work like this.
Yes, it does. A particularly prolific virus could easily infect thousands of Windows machines in a matter of hours.
A software developer first badly codes something.
Virus and malware attacks are frequently not the result of bad coding.
After a delay between hours and years, it's discovered by someone and eventually other people.
Viruses and malware do not typically exploit OS vulnerabilities.
In the open source world, it's then corrected.
If someone can be bothered.
In the Windows world, noone cares to correct this. (In fact, people are typically not even allowed to correct it)
False. No ma
In KDE and Windows, this is not enforced, so I run into the situation of EVERYTHING being hidden in alt+tab.
This is a *good* thing, as it lets you quickly and easily move between *arbitrary windows*, rather than making moving from one arbitrary window to another often a multi-step, multi-key affair.
I have never seen any benefit to OS X's method. If you want to switch between windows within an application (Apple+~), Ctrl+Tab in Windows achieves tihs. If you don't and want to switch between windows in different apps, Alt+Tab does this on Windows, but has no equivalent on OS X. I have never seen any point or benefit in switching to an "entire application" and then raising all its windows to the top of the stack.
Ironically (at least in terms of your attitude), the whole point of Expose is to make Windows-like task switching (between arbitrary windows) easier.
Consider: are subdirectories a good thing? Would you rather everything was in one root directory, each time having to search it for a file you want? No.
Alt+Tab is designed for quickly switching between 2 - 3 windows, as the Z-order is stored in a Most-Recently-Used stack. This was done because that's the typical usage pattern.
Hiding applications is another thing I've never seen the point in, although I can see its usefulness due to how much the Dock sucks at pretty much everything it's supposed to do.
In MacOS, if I go into the system Applications directory, there are maybe 20 programs. I can live with that (do full development, documentation, office work, etc).
Your comparison is broken. Have a look in /usr/bin on your Mac.
In MacOS, applications and their support files and libraries are bundled into .app files I can easily drag into my ~/Applications directory (to install), and delete (to uninstall). Have fun doing that on Linux!
I agree this is an excellent feature, although it must be remembered that Trashed apps can leave files hanging around the system (primarily in the user's home directory), which is one argument for proper uninstallers/package managers.
KDE is great if you are used to Windows, which is a bad paradigm to begin with, but it's trash if you've used a real GUI system.
Please. OS X is as far from GUI nirvana as Windows is. The Dock is a great place to start (a UI train wreck in nearly every respect, albeit becoming more and more irrelevant with every OS X update), closely followed by Finder (horrible for file management in deep and complex directory structures, almost as bad as the old Chooser was for accessing networked resources, but fortunately similarly becoming less and less relevant - it seems Apple's plan is not to fix the things that are broken, but work around them), the poor level of keyboard-accessibility (something Windows has _always_ excelled at), the way some apps quit when their window is closed and others don't and the largely random application of different themes to different applications. I'll mention the overall sluggishness of the UI as well, but that's really an implementation, rather than conceptual or design, problem.
MacOS Classic was a better GUI in nearly every respect to OS X. Relatively minor updates (including making it "lickable") - some of which *are* actually in OS X - would have been the best thing Apple could have done. Instead, it got Steved and has subsequently taken four major releases to work around most of the brokenness.
PatchGuard, quite simply, is "security through obscurity". Basically, while the kernel is running, a hidden background thread continuously hashes the code sections of the kernel and validates that nothing has changed. If something changes, the system bugchecks (blue screens). PatchGuard's security comes from it being obfuscated.
You do not understand what you are talking about.
PatchGuard is not "security by obscurity". "Security be obscurity" would be if, for example, the APIs existed and didn't check for digital signatures, but were undocumented.
Since what PatchGuard does (and how) is documented and known, it is not obscured. It provides security by only allowing known quantities (ie: digitally signed code) certain levels of access.
PatchGuard doesn't offer true security. It has nothing to do with escalation of privilege - if you're able to modify the kernel, it's already too late.
No, it's not, because the kernel commits suicide before you _can_ modify it, therefore protecting itself and the user from damage. When dealing with an attacker that has already reached the point of being able to attempt such an exploit, there's not really anything else it can do.
If you dont believe me do this simple test. Set your view setting to show hidden & system files, go into c:\windown\system32\DLLCache and rename iexplore.exe. Ignore the FUD warning, then go into the explorer folder in the program files folder. Rename iexplore.exe and you will be IE free.
This is like taking the hubcaps off a car and saying "Look ! No wheels !".
This action prevents programs that will attempt to call IE directly from screwing your system.
No, it doesn't.
Microsofts little kernel game here is nothing but that, its a game to shut out the competition, nothing more nothing less.
Microsoft aren't shutting anyone out. As demonstrated by the vendors who have *already* released AV software that works with the published API, as it is supposed to.
That wasn't the only course of action they could have taken. They could have just actually made a better browser than Netscape.
That *is* what they did, with IE4 (*before* Windows 98 was released).