Who says they're closed source? Often they aren't really "licensed" in any particular way at all: some companies use Wine to run custom apps they've written themselves. They're proprietary insomuch as they aren't really useful to others and therefore not on SourceForge, but it's no loss to the open source community.
Anyway, even if people do run closed source software using Wine, so what? Linux also supports closed source software: deliberately so, that's why all the major platform libraries are not GPLd. Transitioning to a completely open sourced world will take a long time, there's no need to go "cold turkey". It's a long term goal not an absolute (unless you are RMS).
Yes, it was all partitioned correctly. I'm not the only one who has had this issue. It never happened with Windows 98, the first time I noticed it was with XP. And like I said, after I unplugged the second hard disk it installed just fine, no worries.
As we're throwing anecdotal evidence around, nearly everybody where I work uses GNOME these days. There has been a marked shift away from KDE and "lite" WMs in favour of it. In the desktops at WineConf, KDE seemed to be in the minority. That's developers, by the way.
Not that this tells us anything. It's just an anecdote, like this survey.
That's not entirely fair. I've found it easier to install Linux than Windows before, if only because Windows refuses to install if it sees any other OS on the system already.
I've been bitten by this before: note well, if you want to have a dual boot Windows/Linux system install Windows first. Even if like me you use separate hard disks for each OS, Windows will flat out refuse to install if it sees Linux on the system.
For me the solution was simple: just unplug the hard disk with Linux on it and then the setup program was happy. If it's all on the same disk you'd probably have to delete Linux, install Windows, reinstall Linux. So I'm not surprised the AC or his wife couldn't figure out how to do it.
That's only necessary because of the crack-tastic way they chose to implement appfolders.
DMGs and tarballs are just containers, the problem being that the Finder is constantly "seeking" new application bundles to integrate with the system. This is the way they avoid (hah) installing programs: basically the stuff that an installer would normally do explicitly is done automatically in the background by the Finder whenever the user wanders across an appfolder (or at startup for apps in the/Applications directory).
That's how the URL handler exploits worked: all you have to do is get an app bundle in one of the magic directories the Finder is watching and you can now modify system configuration without the user even running the app.
Right, but so what? It can "run".class bytecode files by compiling them to native code on the fly, this is how gcjwebplugin works AFAIK. The difference between a VM and compiler is mostly one of semantics, there's no compelling enough reason to reimplement the VM.
Does anybody else find it weird that a Mac news site is posting Linux news, and finishing off with a paragraph labelled "Freedom of choice" which talks about avoiding vendor lockin?
The real question that's on most peoples lips and conspicuously not answered in the FAQ is what is wrong with the GNU implementation. They mention that Classpath and GCJ already exist but fail to mention why these are not open source enough. Red Hat is putting a lot of effort into Free Java - why does Apache feel the need to compete with this?
Right. You could probably argue that it's impossible to be "locked in" to Linux except at the API level (and there's no way around that so it's hardly lockin). Usually the term means vendor lockin which is naturally impossible because - assuming Red Hat don't turn evil and start using MS style agreements - there are always multiple vendors to choose from.
Microsoft find and patch a lot of exploits as they do internal audits, these fixes are discovered by themselves so they aren't documented to extend the length of time it takes before black hats create exploits for them. The patches are sometimes intentionally obfusctated (or many combined together) to make it harder to reverse engineer them into documented exploits.
I don't know why the patch is contacting a web server but the lack of a DNS name is not all that suspicious: it makes it impervious to hacked/poisoned DNS servers.
What exactly are these reasons? It seems to me that Apple value their own hype machine more than KDE: and naturally they're not keen on helping the "competition" because they're fundamentally about lockin and proprietary software.
I don't think any of these reasons are fundamental to any other company: tons of organisations write patches to open source projects and work with the community very well. See how the various embedded chip vendors work with GNU binutils for instance.
Well, look at it this way. It's not hard at all to submit patches as they're written and work with the community to get them merged, even when a company dominates project development. This is exactly what my job is: I do a lot of commercial open source development and all my patches go back as-written in separate form. This isn't any more effort than just submitting a patch dump at the end assuming decent workflows.
So I'm afraid I don't buy that this is just "too hard" argument. It seems more likely that given a choice between letting Steve Jobs go "tada" at MacWorld to his adoring fans, or working with the community before the product is launched, they choose the former.
Sure, OK, so Apple and Red Hat are very different companies. That's fine. Comparing Apple to Sun doesn't work too well though, Suns contributions also smack Apples around.
But let's compare Apple and Sony (or whoever). I don't know if Sony do much with the open source community, probably not, so Apple would win that competition on the grounds that they do stuff. Great! It's great to see companies working with others instead of going off entirely on a tangent. I'd rather Apple use (and contribute) to GCC than developer their own compiler from scratch, after all, something is usually better than nothing.
That said, this does not make Apple saintly or good or kind as some people here seem to think. Apple have the domination of the Mac platform as their goal every bit as much as Microsoft have the domination of Windows as their goal. They'll both use hard-ball tactics to get there, this has been demonstrated time and time again. If and when Microsoft employees start posting patches to open source projects, this won't change the goals of their organisation and so it would be just as wrong to get misty-eyed about it.
I guess my point is not to trash Apple so much as to inject some reality into this discussion. Apple are not friends of the open source movement: they use what's there to help themselves and contribute back the minimum that they legally have to (and often in deliberately inconvenient forms). There's nothing technically wrong with that, but there's nothing particularly right about it either.
Sure, I read the thread (and some of the emails that weren't joined into that thread by the archiving software because of broken clients or whatever). Read the one that starts [quanta-devel] that I linked to in another thread here. Also read the April 2005 archives to see some discussion of the acid tests.
Well, not really. I've been paid to work on open source and paid to merge patch dumps into open source projects. Even when the dump comes in the form of a diff instead of a CVS server it's a major pain to work with because the people who understand the code aren't a part of the community anymore, and merging huge piles of code that nobody really understands is a recipe for disaster.
Not really, they talked about what changes had been made but the conclusion is the same as the initial email laid out. Why don't you read the archives for April 2005 - one of the KDE developers asks about the Acid2 patches and explicitly says "I was afraid you had stopped making incremental patches as we haven't seen any for a long time".
So there is a bit of co-operation there, or was a while ago, but it seems to be more a case of patches appearing when the Safari team feel sorry for the KDE team. Now go look at how Red Hat or SUSE have worked with the open source community to see how it should be done.
Yes, with Subversion you can write a little script that just dumps out each commit in turn and then merge them discretely. That's much harder with CVS because without magic scripts and tools (which often don't work too well with branches) you can't extract changeset information.
It's probably possible if you're determined enough.
Well, I'm not sure what their "stature" is, but I have asked for some patches they wrote for backwards compatibility before and was just told to scrub them out of their tree myself.
I don't really buy this "but at least they're doing something!" line of argument - it seems like the RDF at work again. Microsoft have also released open source software, they've even released software for Linux before. Should we congratulate them on their openness?
No, they won't. Why don't you read what the KDE developers themselves found before assuming that Apple, a publically traded corporation not exactly known for its humility and openness, is working hand in hand with the original authors?
They can (and do) release the changes as patch dumps which are hard/impossible to merge in without spending lots of time doing so.
IOW there's a big difference between "not breaking the license" and "working well with outside projects".
The GCC changes they make are the same. Some aren't rolled back in and whilst the tree is available, documentation on what the patches are and where you can get them are not (and it's a CVS branch so you can't just do a "svn log" and see the individual commits).
Mod this guy up, he is totally right. ActiveX has given code signing a bad name because people (apparently including Microsoft) misunderstood what it did. As the AC says, it just proves a connection between the online world and meatspace, not the trustworthyness of a program.
This should be obvious, really. How do you define what makes software trustworthy? How do you define "bad things"? What about software that falls into a gray area? Who gets to impose their moral and ethical values onto others? The best code signing can do is let you take the owners of the cert to court.
This stuff is discussed more in the autopackage FAQ because for some reason people tend to associate "easy to install software" with "will get spyware" even though there's no evidence of that.
Code signing can be useful, but it proves very specific things: for instance, that a mirror hasn't been cracked, or that a particular file was produced by somebody with a trackable real world identity (so they can be taken to court if they're really doing something wrong). It certainly isn't a magic cure-all to the problem of malware.
Somebody above said that you could use SELinux to sandbox programs so you can be sure they won't do bad things. This isn't really correct. While programs can certainly be sandboxed to some extent - after all, that's what root vs user does - you can't expect users to set individual permissions on a per app basis. After all, the GIMP may not look like it requires the ability to initiate network connections, but what if you use GNOME-VFS and type a URL into the open dialog box? What if you, the admin who sandboxes the app, never use that feature and don't consider it but one of your users does?
Sandboxing, like code signing, is a useful technique but it isn't a real "solution" to malware either. I'm not really sure what the solution actually is. Perhaps there isn't one, just as there's no single solution for real world disease either. I'm sure of one thing though - if there is a solution, TCPA certainly isn't it.
Slashdot Mirror
Anyway, even if people do run closed source software using Wine, so what? Linux also supports closed source software: deliberately so, that's why all the major platform libraries are not GPLd. Transitioning to a completely open sourced world will take a long time, there's no need to go "cold turkey". It's a long term goal not an absolute (unless you are RMS).
Yes, it was all partitioned correctly. I'm not the only one who has had this issue. It never happened with Windows 98, the first time I noticed it was with XP. And like I said, after I unplugged the second hard disk it installed just fine, no worries.
Not that this tells us anything. It's just an anecdote, like this survey.
I've been bitten by this before: note well, if you want to have a dual boot Windows/Linux system install Windows first. Even if like me you use separate hard disks for each OS, Windows will flat out refuse to install if it sees Linux on the system.
For me the solution was simple: just unplug the hard disk with Linux on it and then the setup program was happy. If it's all on the same disk you'd probably have to delete Linux, install Windows, reinstall Linux. So I'm not surprised the AC or his wife couldn't figure out how to do it.
DMGs and tarballs are just containers, the problem being that the Finder is constantly "seeking" new application bundles to integrate with the system. This is the way they avoid (hah) installing programs: basically the stuff that an installer would normally do explicitly is done automatically in the background by the Finder whenever the user wanders across an appfolder (or at startup for apps in the /Applications directory).
That's how the URL handler exploits worked: all you have to do is get an app bundle in one of the magic directories the Finder is watching and you can now modify system configuration without the user even running the app.
Right, but so what? It can "run" .class bytecode files by compiling them to native code on the fly, this is how gcjwebplugin works AFAIK. The difference between a VM and compiler is mostly one of semantics, there's no compelling enough reason to reimplement the VM.
Does anybody else find it weird that a Mac news site is posting Linux news, and finishing off with a paragraph labelled "Freedom of choice" which talks about avoiding vendor lockin?
The real question that's on most peoples lips and conspicuously not answered in the FAQ is what is wrong with the GNU implementation. They mention that Classpath and GCJ already exist but fail to mention why these are not open source enough. Red Hat is putting a lot of effort into Free Java - why does Apache feel the need to compete with this?
Right. You could probably argue that it's impossible to be "locked in" to Linux except at the API level (and there's no way around that so it's hardly lockin). Usually the term means vendor lockin which is naturally impossible because - assuming Red Hat don't turn evil and start using MS style agreements - there are always multiple vendors to choose from.
I don't know why the patch is contacting a web server but the lack of a DNS name is not all that suspicious: it makes it impervious to hacked/poisoned DNS servers.
It's worth noting that Microsoft does exactly the same thing. Presumably you find that worthy of note also?
If they did to your programs what they did to KHTML, they wouldn't be your programs anymore.
I don't think any of these reasons are fundamental to any other company: tons of organisations write patches to open source projects and work with the community very well. See how the various embedded chip vendors work with GNU binutils for instance.
So I'm afraid I don't buy that this is just "too hard" argument. It seems more likely that given a choice between letting Steve Jobs go "tada" at MacWorld to his adoring fans, or working with the community before the product is launched, they choose the former.
But let's compare Apple and Sony (or whoever). I don't know if Sony do much with the open source community, probably not, so Apple would win that competition on the grounds that they do stuff. Great! It's great to see companies working with others instead of going off entirely on a tangent. I'd rather Apple use (and contribute) to GCC than developer their own compiler from scratch, after all, something is usually better than nothing.
That said, this does not make Apple saintly or good or kind as some people here seem to think. Apple have the domination of the Mac platform as their goal every bit as much as Microsoft have the domination of Windows as their goal. They'll both use hard-ball tactics to get there, this has been demonstrated time and time again. If and when Microsoft employees start posting patches to open source projects, this won't change the goals of their organisation and so it would be just as wrong to get misty-eyed about it.
I guess my point is not to trash Apple so much as to inject some reality into this discussion. Apple are not friends of the open source movement: they use what's there to help themselves and contribute back the minimum that they legally have to (and often in deliberately inconvenient forms). There's nothing technically wrong with that, but there's nothing particularly right about it either.
Sure, I read the thread (and some of the emails that weren't joined into that thread by the archiving software because of broken clients or whatever). Read the one that starts [quanta-devel] that I linked to in another thread here. Also read the April 2005 archives to see some discussion of the acid tests.
Well, not really. I've been paid to work on open source and paid to merge patch dumps into open source projects. Even when the dump comes in the form of a diff instead of a CVS server it's a major pain to work with because the people who understand the code aren't a part of the community anymore, and merging huge piles of code that nobody really understands is a recipe for disaster.
So there is a bit of co-operation there, or was a while ago, but it seems to be more a case of patches appearing when the Safari team feel sorry for the KDE team. Now go look at how Red Hat or SUSE have worked with the open source community to see how it should be done.
Why not read the whole thread, or even the archives? This isn't a new problem reported by one guy (who is a core KDE developer, by the way).
I doubt you could argue that not documenting patches violates this but it's skirting around the spirit of the license if not the words.
It's probably possible if you're determined enough.
I don't really buy this "but at least they're doing something!" line of argument - it seems like the RDF at work again. Microsoft have also released open source software, they've even released software for Linux before. Should we congratulate them on their openness?
No, they won't. Why don't you read what the KDE developers themselves found before assuming that Apple, a publically traded corporation not exactly known for its humility and openness, is working hand in hand with the original authors?
IOW there's a big difference between "not breaking the license" and "working well with outside projects".
The GCC changes they make are the same. Some aren't rolled back in and whilst the tree is available, documentation on what the patches are and where you can get them are not (and it's a CVS branch so you can't just do a "svn log" and see the individual commits).
This should be obvious, really. How do you define what makes software trustworthy? How do you define "bad things"? What about software that falls into a gray area? Who gets to impose their moral and ethical values onto others? The best code signing can do is let you take the owners of the cert to court.
This stuff is discussed more in the autopackage FAQ because for some reason people tend to associate "easy to install software" with "will get spyware" even though there's no evidence of that.
Code signing can be useful, but it proves very specific things: for instance, that a mirror hasn't been cracked, or that a particular file was produced by somebody with a trackable real world identity (so they can be taken to court if they're really doing something wrong). It certainly isn't a magic cure-all to the problem of malware.
Somebody above said that you could use SELinux to sandbox programs so you can be sure they won't do bad things. This isn't really correct. While programs can certainly be sandboxed to some extent - after all, that's what root vs user does - you can't expect users to set individual permissions on a per app basis. After all, the GIMP may not look like it requires the ability to initiate network connections, but what if you use GNOME-VFS and type a URL into the open dialog box? What if you, the admin who sandboxes the app, never use that feature and don't consider it but one of your users does?
Sandboxing, like code signing, is a useful technique but it isn't a real "solution" to malware either. I'm not really sure what the solution actually is. Perhaps there isn't one, just as there's no single solution for real world disease either. I'm sure of one thing though - if there is a solution, TCPA certainly isn't it.