The second link in this post leads to a ZDNet article about a Trojan infected Unreal IRC Server package. There has been a lot of debate on that article about the significance, or lack of significance, of this exploit. In particular, Linux advocates have claimed that the package was not released as part of an official distribution. In fact, it was. It was rolled into Gentoo.
And what is the Gentoo bug report response?
"The unrealircd taball in the gentoo mirrors _is_ affected (
Unreal3.2.8.1.tar.gz ) but the Manifest file?s signatures match the
_unaffected_ tarball. This discrepancy is how the backdoor was discovered.
So, please just flush the tar.gz from gentoo?s mirrors, teach people to not
blindly run ?ebuild *.ebuild manifest?, and unrealircd?s SRC_URI does not
include the current upstream tarball location:"
this is *exactly* the kind of Linux community blame-shifting I'm talking about. The tone used, "teach people to not *blindly* run ebuild... etc"... is the typical Linux lack of accountability. The implication is that it is LUSER fault for "blindly" running "ebuild *.ebuild manifest" . Not, "we blew it, we didn't check things, and we put a compromised package in our official distro repo. Our bad..." but instead, "it is your responsibility to check things out before you run it. Can't blame us. It is your fault. Linux is flawless".
Follow the link, read the responses. Interesting stuff there.
Discussion on:
View:
Show:
That is just like MS putting the blame on some other third-party app.
Who cares about a "Year of Linux" or any other such dreck. The crowd into that sort of thing, as with similar things, may be vocal (I don't hear them, though) but minimal.
Now, a valid response might be, ?Did you do anything to address this issue or alert Ubuntu support or development?? No, I did not. Do you know why? When I encounter a problem on OS X or Win32/64, usually if I just wait a little while, Microsoft or Apple fixes the problem.
More BS. And if no one tells them, how could it ever get fixed? Never mind how often MS and Apple fail to patch long-time well-known bugs. If you don't update and upgrade, your problem. Seems to me that if there is a patch, the problem hasn't been ignored.
I know what I can trust Linux to deliver and what I can?t.
Very, very good.
If the Linux community was more forthcoming and honest about Linux strengths and weaknesses ? rather than hiding those weaknesses or trying to misdirect the blame for its limitations ? it would benefit, not hurt, the entire Linux community.
Meh. Prove this happens enough to even begin to compete with those who write Windows and the software for it. Yeah, I don't like hearing it all from the open source community, but then again, I can't say I've heard it much. Valid point, if true. If true.
Edit: I'll have to give you this one, since I've been reminded of it, and have further info: X.org's display manager with the new autoconfig, which doesn't always work. Apparently (according to Jaqui), the devs deny there is anything in need of remediation.
I confess to not having incorporated it into my active, working vocabulary. I have seen it, many times. Haven't incorporated it, though.
Instruct me.
Instruct me.
Is what you resort to when you have nothing better original.
From you, I look to original.
From you, I look to original.
Then I have to explain myself constantly.
Same as using conventional words with too many syllables for the company you're in.
We decided early on not to use baby talk with our daughter. We poured it full-on from the gitgo. Paid off.
I have no patience with those who profess themselves adult, incapable otherwise.
(My little one -- she is a professor, now)
I have no patience with those who profess themselves adult, incapable otherwise.
(My little one -- she is a professor, now)
So basically "made up" for people too bone idle to speak english words of more than 2 syllables... thought as much...
there's a word.
Actually, most english words are two syllables at most (actually, most are just one, at least phonetically).
The long ones? Look close enough, and you'll see.
Actually, most english words are two syllables at most (actually, most are just one, at least phonetically).
The long ones? Look close enough, and you'll see.
I'm not sure when it came into favor, but it strikes me as a dismissive term with overtones of the derogatory. I would regard your incorporation as a ill-advised merger.
That's a dismissive term that I've called people on in real life, where they couldn't get away. I dislike it intensely, so now, of course, more people will use it against me.
Whatever.
Whatever.
Pretty much every piece of software in Ubuntu is upgraded in the latest two versions, meaning there WILL be patches and fixes in them. Not upgrading to them and then claiming, "my problem hasn't been fixed because the developers are ********" is like not upgrading to a Windows service pack and complaining that your issue still isn't resolved.
Shift onto 10.04 and stick with that for two years. It's a LTS release so it will continue to receive bug fixes and support.
Back up your data and do the usual install process from the LiveCD, with one difference: opt to manually partition the drive, then tell it NOT to format /. It will delete and replace the system files without touching /home, leaving your documents intact.
And I hate to break it to you, but you ARE also responsible for your system: developers can work their asses off to fix bugs, but if you don't upgrade and carry on complaining, then yes, that's YOUR fault, not theirs.
Also, stop being dickish. You haven't tried a re-install and you haven't tried the latest version of Ubuntu to see if the problem is resolved, yet you claim that it's not your responsibility and the developers are just being spiteful. Really? Did it ever, seriously, cross your mind that YOU have to take a little responsibility for YOUR computer, too? Ever consider that the reason the developers may be ignoring your is because you HAVEN'T checked if the problem persists in the latest versions?
Shift onto 10.04 and stick with that for two years. It's a LTS release so it will continue to receive bug fixes and support.
Back up your data and do the usual install process from the LiveCD, with one difference: opt to manually partition the drive, then tell it NOT to format /. It will delete and replace the system files without touching /home, leaving your documents intact.
And I hate to break it to you, but you ARE also responsible for your system: developers can work their asses off to fix bugs, but if you don't upgrade and carry on complaining, then yes, that's YOUR fault, not theirs.
Also, stop being dickish. You haven't tried a re-install and you haven't tried the latest version of Ubuntu to see if the problem is resolved, yet you claim that it's not your responsibility and the developers are just being spiteful. Really? Did it ever, seriously, cross your mind that YOU have to take a little responsibility for YOUR computer, too? Ever consider that the reason the developers may be ignoring your is because you HAVEN'T checked if the problem persists in the latest versions?
So, I'm O.K. with dealing with my own medicine. It is dismissive, and potentially derogatory. The OP took the time and expended the effort to quote the parts he disagreed with, and explain why - which is a lot better than I often get, so while I disagree with him, I'm willing to engage in discussion without worrying excessively about the tone of his post. There was a lot of meat to his post to get needlessly sidetracked by his use of a common phrase in the internet vernacular. I often read "meh" to say, "you may be right, you may be wrong, I don't think it is really a hugely relevant to the discussion".
Not that I don't appreciate your individual opinions on the subject, either. I can see both perspectives, for certain.
Not that I don't appreciate your individual opinions on the subject, either. I can see both perspectives, for certain.
I meant nothing in this sidebar to detract from seanferd's otherwise well-expressed points.
I didn't get that vibe from the original post where "meh" was used.
It depends - if the problem is actually the fault of the third party app. If the problem is because of Microsoft's core platform (a security weakness inherent in the OS that causes the app to be exploitable) - then it isn't. Case by case. Now, if Microsoft took an app with an exploit in it, their fault or not, and rolled it *into* their core OS - then it becomes Microsoft's fault for not checking that app out thoroughly before bundling it in. In effect, when the app was added as an app in the repository, with the exploit in place, it became Gentoo's problem too - and shifting the blame to, "users shouldn't blindly run code, regardless", you're shifting blame back to the users - exactly the kind of tactics I accuse the Linux community of using when dealing with faults with *Linux*, which is what this is about.
You're probably right about the "Year of Linux" thing - mostly journalists and Linux acolytes and witnesses are the ones guilty of this kind of hyperbole. I think a large core of the Linux audience today just uses it, without evangelizing. The thing is, not only is that sub-group of Linux-Evangelists vocal, they've historically been a significant part of the Linux community. If the penguin has changed his tuxedo, it'll take time for the rest of the world to forget that.
You missed my point on "notification". With the critical mass of OS X and Windows, I can rely on lots of other people experiencing the problem, and reporting it, to a commercial support group that exists just to address those kind of concerns, with an emphasis on keeping paying customers happy. So fixes on those platforms generally just *happen*. Not so on Linux. I've seen it too many times. The commercial OS platforms, something changes, breaks - and everyone knows, and it gets fixed. Linux, something breaks, you go scouring forums, and you see the developers going, "Man, we do this in our free time, it is probably something YOU'RE doing, if it is a big problem, rather than complain, why don't you join in and help us fix it". A great *nix example would be that FreeBSD 6 and Linux distros around that time had a well reported issue with SMB speed over gigabyte copper. It just dragged on and on, and ultimately the fix was, "It is just going to remain this way, but FreeBSD 7 will address the issue". That kind of "support" wouldn't fly with a well reported and documented issue on OS X or Windows. I've got countless more examples, but I don't want to write a whole other article responding to you. (Although I probably will, anyhow). Regardless, you're right, there have been well known issues not addressed by Microsoft and Apple. That really supports my arguments that one OS platform really *isn't* any different than the next, once you boil it down. The Linux community likes to act as if they're special. The "Many eyes" claim about platform stability isn't my OWN - it comes from the Linux community. But the "many eyes" claim didn't work in this case, any *better* than the "for profit motivation" claim has ever worked for the other platforms.
On the last, this was really my central thesis. Turning issues back around on the users is a major liability in the Linux community, and it has existed since Linux arrived. "RTFM" became a recognized term in popular culture because of the Linux community, and nothing better illustrates the contempt for the user and the disrespect for their inability to resolve "their own problems" - even when "their own problems" are clearly being experienced by a large group of people and not their own fault.
I get it, when you write code for free and release it into the open source out of the goodness of your heart and then a bunch of yahoos come and constantly complain about the things that are wrong with it - that can be a little frustrating. Point is, that is why the Linux model isn't good for companies, corporations, or casual end users. Linux is for hackers, coders, and the technically adept - those who enjoy tweaking with settings and puzzling through challenges with the OS. The constant goal to try and erode desktop OS market share in the office and at the home just isn't something that the support and development model is well designed to handle - and it never will be. It is fundamentally at odds with itself.
You're probably right about the "Year of Linux" thing - mostly journalists and Linux acolytes and witnesses are the ones guilty of this kind of hyperbole. I think a large core of the Linux audience today just uses it, without evangelizing. The thing is, not only is that sub-group of Linux-Evangelists vocal, they've historically been a significant part of the Linux community. If the penguin has changed his tuxedo, it'll take time for the rest of the world to forget that.
You missed my point on "notification". With the critical mass of OS X and Windows, I can rely on lots of other people experiencing the problem, and reporting it, to a commercial support group that exists just to address those kind of concerns, with an emphasis on keeping paying customers happy. So fixes on those platforms generally just *happen*. Not so on Linux. I've seen it too many times. The commercial OS platforms, something changes, breaks - and everyone knows, and it gets fixed. Linux, something breaks, you go scouring forums, and you see the developers going, "Man, we do this in our free time, it is probably something YOU'RE doing, if it is a big problem, rather than complain, why don't you join in and help us fix it". A great *nix example would be that FreeBSD 6 and Linux distros around that time had a well reported issue with SMB speed over gigabyte copper. It just dragged on and on, and ultimately the fix was, "It is just going to remain this way, but FreeBSD 7 will address the issue". That kind of "support" wouldn't fly with a well reported and documented issue on OS X or Windows. I've got countless more examples, but I don't want to write a whole other article responding to you. (Although I probably will, anyhow). Regardless, you're right, there have been well known issues not addressed by Microsoft and Apple. That really supports my arguments that one OS platform really *isn't* any different than the next, once you boil it down. The Linux community likes to act as if they're special. The "Many eyes" claim about platform stability isn't my OWN - it comes from the Linux community. But the "many eyes" claim didn't work in this case, any *better* than the "for profit motivation" claim has ever worked for the other platforms.
On the last, this was really my central thesis. Turning issues back around on the users is a major liability in the Linux community, and it has existed since Linux arrived. "RTFM" became a recognized term in popular culture because of the Linux community, and nothing better illustrates the contempt for the user and the disrespect for their inability to resolve "their own problems" - even when "their own problems" are clearly being experienced by a large group of people and not their own fault.
I get it, when you write code for free and release it into the open source out of the goodness of your heart and then a bunch of yahoos come and constantly complain about the things that are wrong with it - that can be a little frustrating. Point is, that is why the Linux model isn't good for companies, corporations, or casual end users. Linux is for hackers, coders, and the technically adept - those who enjoy tweaking with settings and puzzling through challenges with the OS. The constant goal to try and erode desktop OS market share in the office and at the home just isn't something that the support and development model is well designed to handle - and it never will be. It is fundamentally at odds with itself.
Very well put and also very true. In my case I have to agree on every point you made. Also, Linux driver support is terrible. Just because it has a driver doesn't mean it is good. The driver is usually a generic and sub-par performance at best. Example, I run a small video production business on the side and have tried Linux, but the ATI drivers never work and they are slow rendering compared to Windows.
Also, why would I want to go from a point and click user interface to having to type in command lines and recompile code? That, to me is a big step backward. Get with it Linux.
Also, why would I want to go from a point and click user interface to having to type in command lines and recompile code? That, to me is a big step backward. Get with it Linux.
"What it comes down to is that people working on testing and development during evenings and weekends (on their own time) aren?t ever going to be as responsive as multi-billion dollar, multi-national corporations."
Are you kidding me? Are you referring to Linux kernel contributors such as Red Hat, IBM, Intel, Novell, Oracle, HP, and Fujitsu? Are those the "weekend testers" you are referring to?
As others have pointed out, you still don't understand that Linux is the KERNEL ONLY. All the rest is userspace. There's much more to GNU/Linux than Ubuntu, and all its derivatives.
I'm surprised you are in an IT department, in any capacity. You don't even do basic research.
Are you kidding me? Are you referring to Linux kernel contributors such as Red Hat, IBM, Intel, Novell, Oracle, HP, and Fujitsu? Are those the "weekend testers" you are referring to?
As others have pointed out, you still don't understand that Linux is the KERNEL ONLY. All the rest is userspace. There's much more to GNU/Linux than Ubuntu, and all its derivatives.
I'm surprised you are in an IT department, in any capacity. You don't even do basic research.
Not right to generalize.
Even Canonical isn't a group of weekend testers. And look at Slax-live, supposedly by one individual: runs perfectly.
It's a question of what you want to do. Saying Linux in general is all b*** is not right. How it compares to Windows as a desktop OS, is another issue.
Even Canonical isn't a group of weekend testers. And look at Slax-live, supposedly by one individual: runs perfectly.
It's a question of what you want to do. Saying Linux in general is all b*** is not right. How it compares to Windows as a desktop OS, is another issue.
She didn't say Linux in general is all bad, she said it's not up to snuff, and she's right. You still need to be a geek or a hacker if you hope to get a machine running non-Apple Linux to do everything you're used to doing on a Windows or Mac OS machine "out of the box", and you still may not succeed.
(Incidently, I heard those good things about Mint, too; but when I tried it, it didn't even boot reliably on the a machine Ubuntu and XUbuntu work fine on...)
(Incidently, I heard those good things about Mint, too; but when I tried it, it didn't even boot reliably on the a machine Ubuntu and XUbuntu work fine on...)
Hate it. Despise it. The Linux camp trots this one out when convenient, but ignores it when they want to argue about Linux superiority to Windows or OS X. This is the "We want our cake and eat it, too" defense among Linux advocates.
And of course, here comes that Linux tendency to start launching "ad hominem" attacks on anyone that speaks ill about the Holiest of Kernels (don't you DARE call it an OS, you ignorant moron who doesn't deserve to work in IT).
You'll split hairs when it serves your arguments, but for the sake of practical discussion with a broad audience, Linux is an "OS" platform, speaking in a generic sense. I'm not writing here specifically only for Linux-dorks who live, eat and breath Linux - and the majority of people (read: those that aren't hardcore Linux geeks) aren't going to understand the difference between GNU/Herd and the Linux kernel. Drawing distinctions between Linux and your windows manager and your graphic subsystem is another trick that the Linux camp likes to play. Linux-shenanigans, distractions, and smoke and mirrors. The combo of Linux, XFree86 and GIMP is directly relatable to Windows 32 as an OS interface for general discussion.
Trotting out the big companies that support specific distros of Linux fails to impress me, as well. First off, none of those companies has even a fraction of the OS market share, enterprise, business desktop, or consumer desktop, that either Microsoft or Apple has - and you can be assured their investment in their particular distros has similar limitations due to their small market share. So IBM and HP may be large companies, but they're not putting the same kind of cash and support into their OS that Apple and Microsoft are. That is # 1.
#2 is that many of the packages rolled into any particular distro are maintained by package maintainers EXTERNAL to these big companies - I suppose your big company could take the open source code from those external package developers and maintainers and create their own FORK of that development tree, but that presents unique problems and challenges itself. Otherwise, critical components of your Linux kernel distro may be (almost positively ARE) dependent on third party developers who DO work on weekends and nights on maintaining those packages. And you *know* this as well as I do.
Third, and this is just a minor quibble compared to the other two points above - Linux overall market share is a fraction of the share of Windows or OS X. Of that, a smaller fraction represent distros supported by the large companies that are purchased and have support contracts. Of *those*, you can be fairly certain that the vast MAJORITY of those distros are in specific, specialized ENTERPRISE class roles.
Hardly relevant.
Thank you, djohnston, for illustrating *exactly* what I was talking about in the original article. You're a poster child for the problems with the Linux community.
And of course, here comes that Linux tendency to start launching "ad hominem" attacks on anyone that speaks ill about the Holiest of Kernels (don't you DARE call it an OS, you ignorant moron who doesn't deserve to work in IT).
You'll split hairs when it serves your arguments, but for the sake of practical discussion with a broad audience, Linux is an "OS" platform, speaking in a generic sense. I'm not writing here specifically only for Linux-dorks who live, eat and breath Linux - and the majority of people (read: those that aren't hardcore Linux geeks) aren't going to understand the difference between GNU/Herd and the Linux kernel. Drawing distinctions between Linux and your windows manager and your graphic subsystem is another trick that the Linux camp likes to play. Linux-shenanigans, distractions, and smoke and mirrors. The combo of Linux, XFree86 and GIMP is directly relatable to Windows 32 as an OS interface for general discussion.
Trotting out the big companies that support specific distros of Linux fails to impress me, as well. First off, none of those companies has even a fraction of the OS market share, enterprise, business desktop, or consumer desktop, that either Microsoft or Apple has - and you can be assured their investment in their particular distros has similar limitations due to their small market share. So IBM and HP may be large companies, but they're not putting the same kind of cash and support into their OS that Apple and Microsoft are. That is # 1.
#2 is that many of the packages rolled into any particular distro are maintained by package maintainers EXTERNAL to these big companies - I suppose your big company could take the open source code from those external package developers and maintainers and create their own FORK of that development tree, but that presents unique problems and challenges itself. Otherwise, critical components of your Linux kernel distro may be (almost positively ARE) dependent on third party developers who DO work on weekends and nights on maintaining those packages. And you *know* this as well as I do.
Third, and this is just a minor quibble compared to the other two points above - Linux overall market share is a fraction of the share of Windows or OS X. Of that, a smaller fraction represent distros supported by the large companies that are purchased and have support contracts. Of *those*, you can be fairly certain that the vast MAJORITY of those distros are in specific, specialized ENTERPRISE class roles.
Hardly relevant.
Thank you, djohnston, for illustrating *exactly* what I was talking about in the original article. You're a poster child for the problems with the Linux community.
...linux IS a kernel...not an OS. This is NOT an "argument" but ABSOLUTE FACT.
An engine != a car
If my tires are flat, the engine is not to blame.
If the tires are flat on my Toyata, Ford is not to blame.
Individual distributions != linux
Repeat the line above.
I COULD compile this infected software on an openbsd server. Does this make openbsd bad?
It boils down to application. Always. Gentoo blew it by letting that into their repos. That's not the doing of Linux, that's the doing of gentoo.
I agree with you only as much as to say, NOTHING is perfect. If you're an administrator you need to go with what you know and what you have confidence in. FWIW, I wouldn't have been putting ANY distro on a company desktop....for certain not ubuntu.
An engine != a car
If my tires are flat, the engine is not to blame.
If the tires are flat on my Toyata, Ford is not to blame.
Individual distributions != linux
Repeat the line above.
I COULD compile this infected software on an openbsd server. Does this make openbsd bad?
It boils down to application. Always. Gentoo blew it by letting that into their repos. That's not the doing of Linux, that's the doing of gentoo.
I agree with you only as much as to say, NOTHING is perfect. If you're an administrator you need to go with what you know and what you have confidence in. FWIW, I wouldn't have been putting ANY distro on a company desktop....for certain not ubuntu.
It will never be "Year of the Linux Desktop", since Linux isn't an OS.
...to assert LINUX is insecure because of this malware in gentoo's repos and an issue he's having with Unbunu screensavers....thus BROADENING the discussion outside of the "Linux Desktop argument."
The truth is most distros are not what most users are used to working with. I put Microsoft Windows on client workstations. Probably always will. But it's sure not because it's more secure than most linux distros.
The truth is most distros are not what most users are used to working with. I put Microsoft Windows on client workstations. Probably always will. But it's sure not because it's more secure than most linux distros.
You are technically right, too. I don't think either one of us is absolutely wrong, from that perspective.
If Ubuntu is going to have a "Year of Ubuntu" on "the desktop OS", it seems unlikely that Fedora, SuSE or even Debian is going to be what delivers it. It seems far more likely that, much the same way that Google became generic for "web-crawler", Ubuntu has the most likely chance of becoming generic for "Linux".
And that is how I used it here.
In fact, if we broaden it to a year of *nix, then heck, Apple delivered that long ago. iOS is built on OS-X which is built on FreeBSD, right? Combine all those numbers, and the year of Unix has been going on for the last few years. (Personally, I kind of like it that old, tired, dull Unix became more of a commercial success, in far less time, than Linux has ever been able to achieve. But that is just because I'm mean and like to hate on Linux).
I think that should address *this* criticism with the article? There are literally dozens more we can focus on, though, to keep the love going.
If Ubuntu is going to have a "Year of Ubuntu" on "the desktop OS", it seems unlikely that Fedora, SuSE or even Debian is going to be what delivers it. It seems far more likely that, much the same way that Google became generic for "web-crawler", Ubuntu has the most likely chance of becoming generic for "Linux".
And that is how I used it here.
In fact, if we broaden it to a year of *nix, then heck, Apple delivered that long ago. iOS is built on OS-X which is built on FreeBSD, right? Combine all those numbers, and the year of Unix has been going on for the last few years. (Personally, I kind of like it that old, tired, dull Unix became more of a commercial success, in far less time, than Linux has ever been able to achieve. But that is just because I'm mean and like to hate on Linux).
I think that should address *this* criticism with the article? There are literally dozens more we can focus on, though, to keep the love going.
Which also illustrates my claim that the target for Linux is moving, and the definition is cherry-picked by Linux advocates when it suits them. You won't *often* see someone making this claim when the article has a pro-linux bent to it. (Although there is sometimes that odd-ball, Linux purist who is so caught up on syntax and semantics that they'll throw this rant regardless of in what light Linux has been called an "OS".)
Listen... is the UnrealIRC exploit something that can be executed and exploited on Windows or any other non *nix OS without significant recoding and a recompile or with some other abstraction layer (VM, whatever) in place?
No. This only affects *nix.
I feel like there is something dishonest in claiming, "This is not a Linux issue", when it is only Linux (and possibly *nix variants) that are going to be easily impacted by the exploit. It is dodging the issue. It makes me think of something a politician would do. It affects Linux - it is Linux malware... getting pedantic over the "absolute" details seems like avoiding the truth.
Obviously my perspective has touched a nerve. I've noted with no irony that Ed Bott is receiving heap-loads of similar criticism in the forums for his post, much of it equally nasty and personal to what I am seeing here - which again, is a common theme that I touched on in this and other articles. The Linux community is simply intolerant of criticism and does not handle it well, at all.
Listen... is the UnrealIRC exploit something that can be executed and exploited on Windows or any other non *nix OS without significant recoding and a recompile or with some other abstraction layer (VM, whatever) in place?
No. This only affects *nix.
I feel like there is something dishonest in claiming, "This is not a Linux issue", when it is only Linux (and possibly *nix variants) that are going to be easily impacted by the exploit. It is dodging the issue. It makes me think of something a politician would do. It affects Linux - it is Linux malware... getting pedantic over the "absolute" details seems like avoiding the truth.
Obviously my perspective has touched a nerve. I've noted with no irony that Ed Bott is receiving heap-loads of similar criticism in the forums for his post, much of it equally nasty and personal to what I am seeing here - which again, is a common theme that I touched on in this and other articles. The Linux community is simply intolerant of criticism and does not handle it well, at all.
But I have never tried to compel people to switch to Linux desktops. Many of the "fly-by-night" crowd and article writers push this ridiculous agenda.
I'm on no crusade. Notice my posts. I recommend and deploy ONLY Windows desktops for clients.
But the distinction between a kernel, userland tools, and additional software is not just semantics. It is dishonest to say that malware that is not in stock Red Hat repos, or Debian, or Slackware, or whatever, but found it's way into Gentoo's repos is a Linux issue when in fact the only time something is a Linux issue is when the kernel is not working correctly. Everything else is a function of individual software and the distribution. Actually the "kernel" argument is the real honest argument in this debate.
Open source software is a collection of tools that CAN be misapplied, misconfigured, and misused just like proprietary software.
I'm on no crusade. Notice my posts. I recommend and deploy ONLY Windows desktops for clients.
But the distinction between a kernel, userland tools, and additional software is not just semantics. It is dishonest to say that malware that is not in stock Red Hat repos, or Debian, or Slackware, or whatever, but found it's way into Gentoo's repos is a Linux issue when in fact the only time something is a Linux issue is when the kernel is not working correctly. Everything else is a function of individual software and the distribution. Actually the "kernel" argument is the real honest argument in this debate.
Open source software is a collection of tools that CAN be misapplied, misconfigured, and misused just like proprietary software.
By that logic, wouldn't it be safe to say that the vast majority of modern Windows malware doesn't actually exploit weaknesses in the Windows kernel, it uses social engineering to get end users to install and activate it.
The arguments here are:
Linux is *not* inherently more secure (at least not anymore, and not by any significant margin) - than Windows, or any other OS kernel.
Even if it is - it is really a moot point, because stand alone apps with backdoors or other malware payloads that use social engineering are the most common vector for attack - and something like that isn't really dependent on kernel vulnerabilities, as the UnrealIRC exploit illustrates.
The arguments here are:
Linux is *not* inherently more secure (at least not anymore, and not by any significant margin) - than Windows, or any other OS kernel.
Even if it is - it is really a moot point, because stand alone apps with backdoors or other malware payloads that use social engineering are the most common vector for attack - and something like that isn't really dependent on kernel vulnerabilities, as the UnrealIRC exploit illustrates.
In many cases it not logical to blame MS for the users' infections. That's fair attitude and I agree with you.
But Windows IS sold as a complete OS. You can't really take the Windows kernel alone and add to it so the argument is somewhat irrelevant.
I'm speaking as a technology pro here. A fellow who provides customized solutions and linux may be part of one solution. It may not the next. I'm not speaking as your user working in the hr department.
Historically Windows has been much more susceptible to certain malware than unix systems simply because of it's privilege model. That seems to be improving, but memories die hard.
But Windows IS sold as a complete OS. You can't really take the Windows kernel alone and add to it so the argument is somewhat irrelevant.
I'm speaking as a technology pro here. A fellow who provides customized solutions and linux may be part of one solution. It may not the next. I'm not speaking as your user working in the hr department.
Historically Windows has been much more susceptible to certain malware than unix systems simply because of it's privilege model. That seems to be improving, but memories die hard.
"But Windows IS sold as a complete OS. You can't really take the Windows kernel alone and add to it so the argument is somewhat irrelevant."
Then if you can't compare apples to apples, it isn't fair (or accurate) to compare.
You can compare a jet to an automobile and decide that an automobile *sucks* because it goes so much slower - but when you try to fly down to the corner grocery store, you'll see that even though both have engines and wheels, it isn't really accurate to compare the two.
Either two things are similar enough to compare, and you've going to have to throw away some of the differences for the sake of a valid argument, or they're too different to compare, and it is just futile to do so.
That is the case here. If we're going to compare, then the kernel versus full OS argument is a distraction and needs to be thrown out to assess things like, "does it matter if it is a kernel exploit or simply malware, if the end result is a compromised platform".
If we can't reasonably throw that out, then there shouldn't be any comparisson made.
I don't think the "full OS versus kernel" argument is that important - being that the basic design delivers the same goal in both cases, and the same result ends up from any of the vulnerabilities, exploits, instability issues, or whatever else you might encounter.
But I don't see how you can take it one way where it serves Linux, and have it another way when it doesn't serve Windows, and claim that it is impartial observation.
Not saying that this is what you are doing at this point, either. I'm arguing rhetorically, at this point.
Then if you can't compare apples to apples, it isn't fair (or accurate) to compare.
You can compare a jet to an automobile and decide that an automobile *sucks* because it goes so much slower - but when you try to fly down to the corner grocery store, you'll see that even though both have engines and wheels, it isn't really accurate to compare the two.
Either two things are similar enough to compare, and you've going to have to throw away some of the differences for the sake of a valid argument, or they're too different to compare, and it is just futile to do so.
That is the case here. If we're going to compare, then the kernel versus full OS argument is a distraction and needs to be thrown out to assess things like, "does it matter if it is a kernel exploit or simply malware, if the end result is a compromised platform".
If we can't reasonably throw that out, then there shouldn't be any comparisson made.
I don't think the "full OS versus kernel" argument is that important - being that the basic design delivers the same goal in both cases, and the same result ends up from any of the vulnerabilities, exploits, instability issues, or whatever else you might encounter.
But I don't see how you can take it one way where it serves Linux, and have it another way when it doesn't serve Windows, and claim that it is impartial observation.
Not saying that this is what you are doing at this point, either. I'm arguing rhetorically, at this point.
UnrealIRCd had an issue with the source tarball which can be compiled on Linux based systems, BSD, Windows and osX. It affects any platoform for which someone compiled the source. It's not a failure of the network repository system or Linux based platforms. This is a failure of UnrealIRCd's developer team and Gentoo only. Thus far, no other distribution has been affected due to being based on Linux or being a network repository based distribution.
so yes.. this does affect Windows and osX.
so yes.. this does affect Windows and osX.
"But I have never tried to compel people to switch to Linux desktops."
You're outnumbered by many other Linux users on this and other forums. There are few Windows discussions here that don't receive an unsolicited "You should switch to Linux!" post, with no distro specified or acknowledgment that "Linux is a kernel, not an OS".
You're outnumbered by many other Linux users on this and other forums. There are few Windows discussions here that don't receive an unsolicited "You should switch to Linux!" post, with no distro specified or acknowledgment that "Linux is a kernel, not an OS".
....depends on both the initial goals and the end goal.
Linus and the core kernel developers are not necessarily part of the ubuntu team. Kernel source can be downloaded at www.linux.org
Ubuntu can be downloaded at www.ubuntu.com.
I doubt Linus cares two whits about the Ubuntu imperfections.
You get my point.
If you want to perfectly replace an MS-Windows desktop, neither Linux nor Ubuntu is going to do it for you.
If you want to set up a secure Samba or NFS server, or iscsi target, or mail server, or whatever, neither Linux nor Ubuntu is going to do it for you. But Linux can be an excellent starting point.
Linus and the core kernel developers are not necessarily part of the ubuntu team. Kernel source can be downloaded at www.linux.org
Ubuntu can be downloaded at www.ubuntu.com.
I doubt Linus cares two whits about the Ubuntu imperfections.
You get my point.
If you want to perfectly replace an MS-Windows desktop, neither Linux nor Ubuntu is going to do it for you.
If you want to set up a secure Samba or NFS server, or iscsi target, or mail server, or whatever, neither Linux nor Ubuntu is going to do it for you. But Linux can be an excellent starting point.
I realize that. They've made software a religion, which is odd to me. Use what you want.
Ed's article states that the UnrealIRC backdoor was only in the Linux distributable source, not in other platforms (I am assuming Windows 32/64, MacOS X, Unix, most likely).
That was an important point in his article. The other distributions of UnrealIRC at the official package maintainer's site were malware free - only the Linux source was compromised.
That was an important point in his article. The other distributions of UnrealIRC at the official package maintainer's site were malware free - only the Linux source was compromised.
"
Re: Some versions of Unreal3.2.8.1.tar.gz contain a backdoor
Postby satmd on Sun Jun 13, 2010 5:42 pm
Please note: Windows users are at risk if they have compiled their copy by themselves from the trojaned .tar.gz. The only thing not affected is the pre-made installers.
The backdoor itself is working on *all* platforms!
"
http://forums.unrealircd.com/viewtopic.php?f=1&t=6562&start=15
Re: Some versions of Unreal3.2.8.1.tar.gz contain a backdoor
Postby satmd on Sun Jun 13, 2010 5:42 pm
Please note: Windows users are at risk if they have compiled their copy by themselves from the trojaned .tar.gz. The only thing not affected is the pre-made installers.
The backdoor itself is working on *all* platforms!
"
http://forums.unrealircd.com/viewtopic.php?f=1&t=6562&start=15
Not even surprising. Like the fellow from Tiger Team says; you don't just do one attack and hope it works. You include every avenue of attack you can an maximize your chances of success. I'd expect no less from criminal intent; stuff it full so you got something in place when the other thing is blocked.
Now, I gotta go check the official sites for details. Least they're paying attention and doing a code audit now.
(edit): Jaqui, have you links handy? My ten second internet search didn't turn up anything yet but I'm still looking also.
Now, I gotta go check the official sites for details. Least they're paying attention and doing a code audit now.
(edit): Jaqui, have you links handy? My ten second internet search didn't turn up anything yet but I'm still looking also.
...I couldn't care less about irc servers. If this existed in apache, bind, postfix, or vsftpd, I'd be concerned.
Obviously for users of this software it's significant. But it's not a "linux" issue.
Obviously for users of this software it's significant. But it's not a "linux" issue.
Neon...
Ok. So, then my next question would be...
Was there an .exe or .cab or other pre-compiled installer for Windows admins wanting to run UnrealIRC server?
Because if there was, you can almost *count* on the fact that the Windows admins were *not* compiling their own from source if there was a pre-compiled "package" for Win32/64.
On the other hand, my guess is that with Linux the package was ONLY source and required you to makefile.
Am I right? This is all assumption - based on my knowledge of the two platforms.
But if I *am* right, the end result is, the source with the backdoor was *far* more likely to be compiled for a Linux distro than on a Win platform machine.
(The problem with arguing Linux versus Windows with me is that I'm one of those Windows guys who took the time to get pretty familiar with Linux. Makes it a lot more difficult to fool me with Linux "smoke and mirrors". It isn't impossible, just more difficult.)
Right?
Ok. So, then my next question would be...
Was there an .exe or .cab or other pre-compiled installer for Windows admins wanting to run UnrealIRC server?
Because if there was, you can almost *count* on the fact that the Windows admins were *not* compiling their own from source if there was a pre-compiled "package" for Win32/64.
On the other hand, my guess is that with Linux the package was ONLY source and required you to makefile.
Am I right? This is all assumption - based on my knowledge of the two platforms.
But if I *am* right, the end result is, the source with the backdoor was *far* more likely to be compiled for a Linux distro than on a Win platform machine.
(The problem with arguing Linux versus Windows with me is that I'm one of those Windows guys who took the time to get pretty familiar with Linux. Makes it a lot more difficult to fool me with Linux "smoke and mirrors". It isn't impossible, just more difficult.)
Right?
So, can I do that with the Linux crowd when they're all over a Windows exploit, in the future?
"Sure, there is a Win32/64 exploit, and if I surfed porn, I'd be afraid of picking up the CoolWeb exploit, but I don't, so it doesn't concern ME"...
Or, "I don't run Flash, or I don't use Adobe Reader or..."
Come on...
This is what I'm saying. You apply one set of standards to Win32 (YOU is the "Linux community"), and then you apply a second set of standards when it affects Linux. And then you say, "You can't compare this - because Windows is an OS and Linux is a KERNEL. How many exploits are because of inscure APPS, on Windows, not an "inherently insecure" kernel? Yet the Linux community crucifies Windows as insecure, not Flash or Adobe Reader or whatever else...
Just sayin'...
"Sure, there is a Win32/64 exploit, and if I surfed porn, I'd be afraid of picking up the CoolWeb exploit, but I don't, so it doesn't concern ME"...
Or, "I don't run Flash, or I don't use Adobe Reader or..."
Come on...
This is what I'm saying. You apply one set of standards to Win32 (YOU is the "Linux community"), and then you apply a second set of standards when it affects Linux. And then you say, "You can't compare this - because Windows is an OS and Linux is a KERNEL. How many exploits are because of inscure APPS, on Windows, not an "inherently insecure" kernel? Yet the Linux community crucifies Windows as insecure, not Flash or Adobe Reader or whatever else...
Just sayin'...
Either you did the reading and your putting on a theater act or you didn't bother to do the reading and it's more important to support your theory by ignoring relevant facts. Ed sure ignores inconvenient facts in his one page troll bait but then, his job is to drive page hits now isn't it.
If you did the reading, you'd have seen that the Windows binary and CSV sources where clean. If we're going to assume that no Windows administrators used the source distribution, can we also assume that no administrators of other platforms used the CSV distribution? I know I sure have a preference towards the SVN/CSV distribution versus the tarball source; maybe I'm the one in a million though.
Sorry, still not a "linux" issue but a clear issue with a small program's mirror management. You'll notice I've already recognized the various ways this issue is a proof of concept though.
(and don't seriously suggest that this is a Linux based platforms smoke and mirrors conspiracy against Windows or similar. If tables where turned, I'd argue equally hard that a bug in a driver or third party application was not a Windows issue but an issue with that original developer)
Let's not lessen either of our arguments with the smoke and mirrors tripe shall we?
If you did the reading, you'd have seen that the Windows binary and CSV sources where clean. If we're going to assume that no Windows administrators used the source distribution, can we also assume that no administrators of other platforms used the CSV distribution? I know I sure have a preference towards the SVN/CSV distribution versus the tarball source; maybe I'm the one in a million though.
Sorry, still not a "linux" issue but a clear issue with a small program's mirror management. You'll notice I've already recognized the various ways this issue is a proof of concept though.
(and don't seriously suggest that this is a Linux based platforms smoke and mirrors conspiracy against Windows or similar. If tables where turned, I'd argue equally hard that a bug in a driver or third party application was not a Windows issue but an issue with that original developer)
Let's not lessen either of our arguments with the smoke and mirrors tripe shall we?
Two safe packagings out of three does not negate risk to all platforms that vulnerable packaging can be installed on. Forgoing the fact that UnrealIRCD does affect all platforms, your saying that an issue in a third party program and a single distribution is evidence than all distributions are high risk options regardless of clear differences between how assembly and distribution is managed.
If it's a third party program vulnerability which opens Windows up to exploitation without leveraging faults in the userland or kernel; that's clearly not a Microsoft responsability.
If it's a third party program vulnerability which opens Windows up to exploitation because of a fault in the default userland or kernel; that is a Micorosft responsability.
If it's a third party program vulnerability that becomes exploitable because of non-default Windows settings; that is clearly an administrator responsability in addition to the third party developers.
If it's a third party program vulnerability that becomes exploitable because of default Windows settings; that is a Microsoft responsability in additoin to the third party developers.
If it's a third party program that causes a vulnerability that affects a non-Microsoft distribution of Windows (ligitimate or no, they exist) but does not affect Microsoft's official distribution or other non-Microsoft distributions; that's clearly not a Microsoft responsability or fault in the other unaffected non-Microsoft Windows distributions.
If a vulnerability exists in one of Microsoft's products but no one reports it to microsoft and, being unaware of it, they do not fix it; that's clearly not a Microsoft issue.
If a vulnerability is enabled because of overall Windows system architecture; that is clearly a Windows issue.
If a vulnerability exists for several months but is only recently reported with an update available from Micorsoft; that demonstrates an issue with Microsoft's quality control but the patched promptly when discovered so good on them. (ideally becaues they also improve future quality controls)
If a vulnerability exists for several months and Microsoft is aware of it but decides that it's not public enough or within budget or within developer time or otherwise neglects it; that is clearly a Microsoft quality control and management issue.
Did I miss any scanario combinations? Are any of these placing blame on the wrong party? If not, then why is a vuln in a third party program and single distribution suddenly an issue to be blamed on any distribution that happens to be assembled on top of Linux. Why is one distributions package mantainer's failure a valid basis to claim that all distributions are poorly maintained?
The comment above is from a someone pointing out that the vulnerability was found in a program not widely deployed across platforms and without a large developer base to draw on peer review. It suggests that this is a non issue for that person because they don't run an IRC service let alone the specific one with the vulnerability. It also suggests that if this was a backdoor in major distributions or major programs widely deployed across distributions and/or widely used across installed systems; it would be deserving of the kind of media attention one anomaly is getting. Hence; "for me, this is a non-issue". Wouldn't it be the same if it was a Windows vulnerability in a third party or bundled service not enabled by default or widely used across Windows installations especially your own; wouldn't it be a non-issue for you?
In the above scenario's where Microsoft is not responsible; I'll be right beside you looking back at the blindly faithfull pointing out that the vulnerability was not caused, and can't be fixed, by Microsoft. In the scenarios where the issue was enabled by Microsoft's architecture, default config or product code, you'll have to excuse people for wanting Microsoft's feet to the fire.
If it's a third party program vulnerability which opens Windows up to exploitation without leveraging faults in the userland or kernel; that's clearly not a Microsoft responsability.
If it's a third party program vulnerability which opens Windows up to exploitation because of a fault in the default userland or kernel; that is a Micorosft responsability.
If it's a third party program vulnerability that becomes exploitable because of non-default Windows settings; that is clearly an administrator responsability in addition to the third party developers.
If it's a third party program vulnerability that becomes exploitable because of default Windows settings; that is a Microsoft responsability in additoin to the third party developers.
If it's a third party program that causes a vulnerability that affects a non-Microsoft distribution of Windows (ligitimate or no, they exist) but does not affect Microsoft's official distribution or other non-Microsoft distributions; that's clearly not a Microsoft responsability or fault in the other unaffected non-Microsoft Windows distributions.
If a vulnerability exists in one of Microsoft's products but no one reports it to microsoft and, being unaware of it, they do not fix it; that's clearly not a Microsoft issue.
If a vulnerability is enabled because of overall Windows system architecture; that is clearly a Windows issue.
If a vulnerability exists for several months but is only recently reported with an update available from Micorsoft; that demonstrates an issue with Microsoft's quality control but the patched promptly when discovered so good on them. (ideally becaues they also improve future quality controls)
If a vulnerability exists for several months and Microsoft is aware of it but decides that it's not public enough or within budget or within developer time or otherwise neglects it; that is clearly a Microsoft quality control and management issue.
Did I miss any scanario combinations? Are any of these placing blame on the wrong party? If not, then why is a vuln in a third party program and single distribution suddenly an issue to be blamed on any distribution that happens to be assembled on top of Linux. Why is one distributions package mantainer's failure a valid basis to claim that all distributions are poorly maintained?
The comment above is from a someone pointing out that the vulnerability was found in a program not widely deployed across platforms and without a large developer base to draw on peer review. It suggests that this is a non issue for that person because they don't run an IRC service let alone the specific one with the vulnerability. It also suggests that if this was a backdoor in major distributions or major programs widely deployed across distributions and/or widely used across installed systems; it would be deserving of the kind of media attention one anomaly is getting. Hence; "for me, this is a non-issue". Wouldn't it be the same if it was a Windows vulnerability in a third party or bundled service not enabled by default or widely used across Windows installations especially your own; wouldn't it be a non-issue for you?
In the above scenario's where Microsoft is not responsible; I'll be right beside you looking back at the blindly faithfull pointing out that the vulnerability was not caused, and can't be fixed, by Microsoft. In the scenarios where the issue was enabled by Microsoft's architecture, default config or product code, you'll have to excuse people for wanting Microsoft's feet to the fire.
Ok... so, I'm going to address both of your last posts, or try to, in a single response here.
You're stepping off into the deep end of developer and Linux administration topics here with compiled bins, CSV source, and source tarballs. So I'm just not really qualified to continue that discussion. I don't honestly know and I'm not going to try to argue something where your depth of knowledge is deeper than mine. (Although I would still like to see someone with your depth of knowledge who disagreed with you, so I could compare both different perspectives. There are things about what you are describing that just don't make sense to me.)
I'm not sure I completely understand all of the differences - I just know, in personal experience, I've never downloaded something in source code for a Windows machine and compiled it, outside of learning a particular language or writing my own code. On the other hand, I've frequently compiled raw source for Linux out of necessity. Therefore, to *my* mind, when I'm told the Windows branch was uninfected, but that the Linux source was infected, it seems likely to me that this infection is far more likely to be compiled in the Linux world. Understanding how Linux source works, it also seems to me that if the Linux source is infected, it could potentially affect *any* Linux distribution where the Linux admin decided to compile this code. I think this might be a simplified approach, but it seems logically sound to me. Therefore, I can't get my head around where it is wrong to say that this exploit had the potential to affect any Linux distro. It was Linux source, and that was the only code that had the backdoor.
Otherwise, I see all of the rest of your points, including your claim that it probably was a negligible risk to Linux platforms - and that it wasn't a problem with Linux, but with the third party code that ran ON Linux. Still, broadly speaking, wasn't this an exploit that targeted *only* Linux platforms? I don't think this is about smoke and mirrors - I think we've got a fundamental difference in opinion in our concept of how we're using language to describe the issue here.
As for your Windows scenarios, I can agree there, too - again, broadly. The problem is that while you may be reasonable, I don't think the "non-windows" Community (and I say non-windows instead of Linux because it isn't just Linux propeller heads who are guilty, here) holds themselves to the same strict, granular, detailed definition of where responsibility lies as you do. In particular, I think the non-Windows tech press has been very hard on Windows, with the same kind of sensationalist, broad, and shallow analysis you're claiming Ed Botts is guilty of here, for years. It reminds me of people screaming about how Fox News is biased while ignoring that the larger press media is also biased, in the other direction. Which is fine with me, I'm ok with society or culture settling on a certain simplification ("Windows exploits, regardless of where they come from... are bad and the responsibility of Microsoft") - as long as that is applied consistently ("Linux exploits, regardless of where they come from... are bad and the responsibility of the Linux community").
You may rise above this and look at each individual issue isolated from the others, but I do not think the broader computing public, professional and casual, do the same.
So in the end, I'm OK with the analysis "This Linux exploit illustrates that Linux certainly is not IMMUNE from Malware, and as the Linux userbase grows, we're likely to see more attempts to exploiot that lack of immunity".
You're stepping off into the deep end of developer and Linux administration topics here with compiled bins, CSV source, and source tarballs. So I'm just not really qualified to continue that discussion. I don't honestly know and I'm not going to try to argue something where your depth of knowledge is deeper than mine. (Although I would still like to see someone with your depth of knowledge who disagreed with you, so I could compare both different perspectives. There are things about what you are describing that just don't make sense to me.)
I'm not sure I completely understand all of the differences - I just know, in personal experience, I've never downloaded something in source code for a Windows machine and compiled it, outside of learning a particular language or writing my own code. On the other hand, I've frequently compiled raw source for Linux out of necessity. Therefore, to *my* mind, when I'm told the Windows branch was uninfected, but that the Linux source was infected, it seems likely to me that this infection is far more likely to be compiled in the Linux world. Understanding how Linux source works, it also seems to me that if the Linux source is infected, it could potentially affect *any* Linux distribution where the Linux admin decided to compile this code. I think this might be a simplified approach, but it seems logically sound to me. Therefore, I can't get my head around where it is wrong to say that this exploit had the potential to affect any Linux distro. It was Linux source, and that was the only code that had the backdoor.
Otherwise, I see all of the rest of your points, including your claim that it probably was a negligible risk to Linux platforms - and that it wasn't a problem with Linux, but with the third party code that ran ON Linux. Still, broadly speaking, wasn't this an exploit that targeted *only* Linux platforms? I don't think this is about smoke and mirrors - I think we've got a fundamental difference in opinion in our concept of how we're using language to describe the issue here.
As for your Windows scenarios, I can agree there, too - again, broadly. The problem is that while you may be reasonable, I don't think the "non-windows" Community (and I say non-windows instead of Linux because it isn't just Linux propeller heads who are guilty, here) holds themselves to the same strict, granular, detailed definition of where responsibility lies as you do. In particular, I think the non-Windows tech press has been very hard on Windows, with the same kind of sensationalist, broad, and shallow analysis you're claiming Ed Botts is guilty of here, for years. It reminds me of people screaming about how Fox News is biased while ignoring that the larger press media is also biased, in the other direction. Which is fine with me, I'm ok with society or culture settling on a certain simplification ("Windows exploits, regardless of where they come from... are bad and the responsibility of Microsoft") - as long as that is applied consistently ("Linux exploits, regardless of where they come from... are bad and the responsibility of the Linux community").
You may rise above this and look at each individual issue isolated from the others, but I do not think the broader computing public, professional and casual, do the same.
So in the end, I'm OK with the analysis "This Linux exploit illustrates that Linux certainly is not IMMUNE from Malware, and as the Linux userbase grows, we're likely to see more attempts to exploiot that lack of immunity".
Very true, the general public view is to blame the easily recognized component. I feel the same when someone goes off about how Windows is broken and Microsoft should fix it because the individual keeps seeing blue screens due to crap drivers or faulty hardware. The best one can do is start with a polite response trying to point out the differences or confirm the cause. Click-n-run non-techs aren't going to care about what causes the problem in the end though. They are experts in other topics after all. It's really the tech community and fanboys that give me grief when blindly attributing faults because it is convenient to there argument (I don't suggest this as your motive as you tend to put a lot of support behind your opinions and that makes them valuable even if not agreeable.)
A bit of tech for fun; CSV and Subversion (SVN) are version control systems. Multiple people can work on the same source tree and keep in sync with the central copy. You can go back through updates to an earlier version and such. They are also handy for tracking changes in one's website and I've heard of people mirroring /etc into a version control system. I'm pretty sure Studio.NET has it's own and/or plugs into the mentioned two.
From the user side, it means having the latest version of the source and/or binaries. I use it where possible in the rare cases that I have to go outside the distribution repositories. Metasploit by SVN is a must for me. I can't tell you the number of times I've seen a "new version of MSF available with these great additions" only to run an svn update and find out I've had those new features for a month already.
In the case of UnrealIRCD, I think the mirror'd tarball was just easier to get at on the servers or it was indeed a targeted attack based on the assumption that UnrealIRCD/Windows is the less common combination. They got in, they dropped the payload and got out without hanging around to risk detection. I actually assumed that the source only affected Linux/BSD systems when I read the first reports until the OSNews article and my subsequent visit to the official media release in UnrealIRCD's forums. It would be interesting to know who did it and under what motivations but I suspect they are keeping there head down and praying at the moment.
A bit of tech for fun; CSV and Subversion (SVN) are version control systems. Multiple people can work on the same source tree and keep in sync with the central copy. You can go back through updates to an earlier version and such. They are also handy for tracking changes in one's website and I've heard of people mirroring /etc into a version control system. I'm pretty sure Studio.NET has it's own and/or plugs into the mentioned two.
From the user side, it means having the latest version of the source and/or binaries. I use it where possible in the rare cases that I have to go outside the distribution repositories. Metasploit by SVN is a must for me. I can't tell you the number of times I've seen a "new version of MSF available with these great additions" only to run an svn update and find out I've had those new features for a month already.
In the case of UnrealIRCD, I think the mirror'd tarball was just easier to get at on the servers or it was indeed a targeted attack based on the assumption that UnrealIRCD/Windows is the less common combination. They got in, they dropped the payload and got out without hanging around to risk detection. I actually assumed that the source only affected Linux/BSD systems when I read the first reports until the OSNews article and my subsequent visit to the official media release in UnrealIRCD's forums. It would be interesting to know who did it and under what motivations but I suspect they are keeping there head down and praying at the moment.
I think that Apple's OS platforms benefit the most from the open nature of both Linux and (with some irony) Windows. The very tight control that Apple maintains over their OS platforms is part of why users are so much more satisfied with their platforms, both mobile and "desktop" (we're all going to agree that "desktop" is now a generic for anything we would consider a traditional, full-horsepower PC - a notebook, a desktop, even an all-in-one that has a full featured destkop PC cpu in it).
This is why iOS satisfaction is so much higher than Android satisfaction, and why Mac user satisfaction is so much higher than PC or Linux user satisfaction. I *hate* ATI products because their drivers have traditionally been among the *worst* for Windows platforms, causing all kinds of problems, conflicts and unintended behavior, and leaving all kind of left-overs when uninstalling. ATI makes some of the best malware in the industry.
Interesting background on CSV and subversion. I had heard of Subversion before, but didn't realize that was what you were talking about.
This is why iOS satisfaction is so much higher than Android satisfaction, and why Mac user satisfaction is so much higher than PC or Linux user satisfaction. I *hate* ATI products because their drivers have traditionally been among the *worst* for Windows platforms, causing all kinds of problems, conflicts and unintended behavior, and leaving all kind of left-overs when uninstalling. ATI makes some of the best malware in the industry.
Interesting background on CSV and subversion. I had heard of Subversion before, but didn't realize that was what you were talking about.
I'm glad at least techs can recognize this. And I seriously question why the ATI driver manager requires .NET 2.
I was an ATI lifer.. the All In Wonder line specifically before growing up and having the default become a separate computer and TV. Driver "updates" that require uninstalling the driver and bundled software stack; that's not an update. Terrible stability from the event scheduler and TV application. Booo! They are/where another company that did a good job of the hardware and hosed it through crap software. I ended up with Nvidia because of cross platform support and better Windows drivers in general.
I do hope the ATI hardware continues to make it under AMD ownership and if the cross platform and Windows software stack improve beyond what I'm getting from Nvidia; I'll consider buying from that line in the future. We'll see how it goes.
In terms of osX, the nice thing is that Apple owns CUPS. If the printer works with Apple systems, it'll probably work with any other platform using CUPS. Outside of perifferals, they keep a pretty strong hold on hardware selection though so I'm not expecting to see a swath of driver code flowing from them for internal parts.
I also don't know the details of osX driver development; is it vendor supplied or do Apple developers do that code. There is something to be said for the driver developer team working directly with the core kernel developers.
I do hope the ATI hardware continues to make it under AMD ownership and if the cross platform and Windows software stack improve beyond what I'm getting from Nvidia; I'll consider buying from that line in the future. We'll see how it goes.
In terms of osX, the nice thing is that Apple owns CUPS. If the printer works with Apple systems, it'll probably work with any other platform using CUPS. Outside of perifferals, they keep a pretty strong hold on hardware selection though so I'm not expecting to see a swath of driver code flowing from them for internal parts.
I also don't know the details of osX driver development; is it vendor supplied or do Apple developers do that code. There is something to be said for the driver developer team working directly with the core kernel developers.
Have you read any of the Mac community's attitude toward Microsoft? and vice versa? The rivers run red!
Maybe - just maybe - Linux advocates are sick of being repeatedly mistreated and ignored by Apple and MS when their problems don't fall in to the categories listed. Although I still use Win7 most of the time, when I want software I can actually afford, I use Ubuntu Linux. Why do you?
Maybe - just maybe - Linux advocates are sick of being repeatedly mistreated and ignored by Apple and MS when their problems don't fall in to the categories listed. Although I still use Win7 most of the time, when I want software I can actually afford, I use Ubuntu Linux. Why do you?
- Keyboard Shortcuts:
- Prev
- Next
- Toggle









































