It's only a major threat if you haven't updated your machine. If you are behind in updates, then you should be infected. Period, end of story.
Not really. I know someone on another discussion board who in the last week had the necessity for what I am pretty sure were unrelated reasons of reinstalling Windows. Within the *ten minute* window between Windows successfully being installed off the CD and the new patches being downloaded off Windows Update and installed, his machine got worm infected and became unusable. So he's having the problem of being unable to do anything with his computer since he can't get to a position after reinstalling where he makes his computer impervious to worms without having to briefly expose himself to the worm. I think the advice he was given was to disconnect the computer from the internet, reintall, and do some stuff with the WinXP firewall before connecting to the internet. I haven't seen him online since then so I don't know if it worked.
It's a little harder to patch an install CD, unless you have powerful laser beams that you can shoot out of your eyes or something.
Is that between the two companies you are making reference to:
One is simply very quiet about security period.
The other one makes a huge deal constantly about how they are improving their security, how they've changed their ways this time really and they're sending all their programmers to a 4-week course on how to not write buffer overflows, and windows is the most secure OS more than any of the competitors, etc.... while simultaneously trying to keep things as hushhush as they practically can about vulnerabilities and publically and loudly blaiming public informedness about security vulnerabilities for the fact the security holes they wrote are being exploited.
One of these two companies is being silly. The other one is being actively hypocritical and duplicitous.
Because the thing is that Novell is selling linux, and in fact owns SUSE and Ximian, and as a result are bound by the terms of the GPL.
The neat thing about the GPL is its seemingly foolproof method of making sure everyone plays fair: they make it in everyone's interests to play fair, by making everyone not just borrow from everyone else, but depend on everyone else.
For example, let's say a company releases a piece of software under the GPL, then the next day decides to recant and announces that no, we changed our mind, it wasn't GPLed after all. If the company never sold anyone a copy, just put it up for download on a website, well then, who's to disagree with them? If someone had given them money for it that could be construed as having some sort of contractual validity, and the license that they included when they originally distributed the license irrevocable. But if it was just a free download, and the license included with the download as a written offer... well that's kind of fuzzier, isn't it? It would seem the company couldn't "go back" on their license offer, but the company could claim all kinds of things. They could claim the release was "unauthorized", or not intended for public release outside the company, or there were mitigating copyright and contractual cirucmstances the company was not aware of at the time doctrine of mutual mistake blah blah blah. And if this were the BSD license, that's where things would end.
But the GPL, among doing other things, adds an interesting wrinkle to things by legally intertwining to a certain extent everyone who cooperates using it. If someone releases some code they own under the GPL, they still own it and can do whatever they like with that code outside the context of the GPLed product However if someone is distributing or redistributing a product containing someone else's GPL code-- anyone's-- then they suddenly find themselves with a small and reasonable, but important, set of obligations.
So, here's another hypothetical example. Let's say Novell announces they own lines 5000-5435 of the linux kernel; that those lines were stolen from NetWare by a disgruntled employee who then submitted them to Linux as his own work at some point; that they have indisputable proof of this; and they further announce that anyone who wants to sell linux owes them $699 a copy for Novell's 435 lines of code there.
The problem here is that they can't do that; the instant Novell points out those 435 lines of code are unlicensed, distributing Linux becomes illegal, period. The reason for this is that the GPL says that in order to distribute under the GPL, you must be able to offer to anyone who you distribute it to an unlimited GPL license themselves, which includes the right to freely redistribute and modify. If you don't have the rights to distribute Linux under the GPL, you certainly don't have the right to distribute Linux by any other mechanism. And if you have to pay $699 to distribute the Linux kernel, then you don't have the right to distribute it under the GPL. The rest of Linux, everything except those 435 lines, is still GPLed and freely distributable; but the whole package, or any package that contains those 435 non-Free lines linked against GPL code, is something nobody-- including Novell-- has the right to distribute at all until those lines are removed or replaced.
So, Novell currently lacks the ability to attack Linux in this fashion without losing the right to sell Linux in the process-- which would be a major problem for them since they currently have a decent amount riding on their Linux-based products. And the really fun thing is, if Novell does as SCO did after raising their apparently fraudulent claims against Linux, and continues to distribute Linux even after they make the public claim that they own code in Linux that they never gave Linux a license to, then one of
Yes, I followed the links. They give me a pretty clear idea of how the NRF wishes to portray themselves, and seems to indicate that this is something of a largish public relations coup for the anti-SCO side of all this (I.E. everybody) which will serverely hamper SCO's efforts to convince small businesses they should let SCO extort money from them.
However, it says very little about whether they hold any sort of capitalizable political power, or whether there's anything I missed giving the NRF direct relevance to SCO's legal cases, and I wondered if anyone here had had direct dealings with them and could give some sort of anecdotal demonstration of their actual importance. I was trying to, how you say, "provoke discussion".:)
I was *just* recently sitting here and wondering if there was anything Microsoft could have done to squander the product, userbase and public goodwill MS inherited when they bought Hotmail that they haven't done already.
I couldn't think of anything
I guess I'm just not as imaginative as MS.
I'll bet the GMail team is doing a little dance of joy at reading this/. article right now..
How exactly is the JDS "tailored to" Java? I thought I'd I heard the Java in the title was just a brandname and the GUI was GNOME. Or do you just mean that it comes with a high-quality JVM as opposed to the crud Windows or most web browsers ship with?
JUST RELEASED, AND ALREADY HACKED!!!! Ok, not yet. But, as with anything DRM, give it a couple months after getting out of this concept phase.
Here's a better way of looking at this. This hasn't been fully released yet, and it has already been "hacked", in the sense that the NSA already has gotten their plants and bugs inside Microsoft* to steal and relay to them all of the plans for how this system will be used and implemented as well as all the keys that make it work.
(Clarification: That's the neat thing about "trusted computing" from their perspective-- it would mean every system in the world would be "trustable", but that trust would have a single point of failure: Microsoft's guarded private cryptographic keys for Janus/Palladium. So all you have to get a copy of those keys and you can do anything you want...)
* Further clarification: I base my belief in the existence on said plants on the simple observation that if the NSA doesn't have plants inside Microsoft, then they're completely incompetent.
How do the stem cells know when to *stop* growing the tooth? I mean, clearly there's something telling them when they're done but what happens if something goes wrong? What happens if you drop these things in someone's gum, and it starts growing a tooth, but the shutoff mechanism for the stem cells never activates.. so it just keeps growing.. and growing.. and growing...
LONDON, ENGLAND... A HUGE, WHITE MASS LOOMS OVER THE BUILDINGS ON THE HORIZON
WOMAN, FRIGHTENED AND DRAWING BACK: My God... what is it??
MAN, STANDING BACK DRAMATICALLY: It is... The Tooth.
The problem is not that API it's the dev tool. This guy likes xcode. Xcode is great if you want to code in objective-c but it sucks if you want to code in java. It also does not support any other language. Apple is actively trying to bring the Java support up to the same level of quality as the Objective C support and it's getting better with every release.
As far as "other languages" go, well, XCode has builtin support for C, C++, Objective C and Java. That's not exactly bad. And while these are the only language it comes in with builtin compile support for, it does contain highlighting semantics for a decent number of other languages. I use it to write Perl all the time (and really, what do you need out of a Perl dev tool besides syntax highlighting?).
XCode also happens to be very modular, so adding additional "support" to XCode for additional languages should be something third parties are perfectly capable of. I'm not sure if they could hook into CodeSense or a few of the more advanced features of the debugger, but if you're trying to add support for a language I'm just about certain you could easily define just about whatever syntax highlighting and build process rules that you would like. (Of course, good luck trying to find the documentation that describes how to do all this...)
Instead of wasting time and money on xcode apple should join the eclipse group and make sure there is a decent plug in for webobjects (yes I know about wolips) and objective c.
I'm really kind of going to have to assume from this statement that you are not a Cocoa developer. (Of course, if what you're telling us here is that you're a WebObjects developer, then that neatly explains your animosity toward XCode, since youall have kind of gotten the shaft lately).
For Cocoa developers, Apple's Developer tools are EXCELLENT and all fit together with each other and with XCode in a very pleasant manner. And they're getting better and more elaborate with every release. I would say that the developer tools are almost as much a reason to use Cocoa as the API itself. I routinely give XCode as one of the main things I like about OS X development. I'm not sure what Apple would stand to gain by throwing it all out and starting over with a different set of tools which, while nice, aren't exactly targetted for Apple's needs. XCode meanwhile is finely tuned to Cocoa development and is getting moreso all the time...
Finally they should give serious thought to abanding objective C. Yes it's a great language but let's admit that people don't want to spend time learning it. Switch to python or ruby or something and be done with it.
First, there are python bindings for Cocoa already; I don't know if anyone's managed to integrate them into XCode yet. Second, I totally fail to see how-- if people won't bother to learn Objective C because they can't be bothered to get used to square brackets for method calls-- Apple is going to have any better luck at all with convincing people to learn Python, which is totally unlike anything the vast majority of people are used to. (Yes, it's a quick learn, but the problem with ObjC isn't getting people to learn it, the problem is getting people to WANT to learn it.)
That is patently ridiculous. Apple supports QT on Windows. They have free downloads for Windows. It wouldn't cost any more to have free downloads for a couple *nixes.
Wha?
You are saying that developing from the ground up a port of a very complicated and optimized set of libraries and GUI applications onto a platform which not only does Apple have zero infrastructure for in terms of personell which know how to develop for it, not only is this platform the single most diverse in terms of hardware and software configurations in the world, but also you can't assume the presence of a usable GUI widget toolkit and there isn't even really a single totally universally accepted method of sound playback... would be something that would be zero cost to Apple?
I'm sorry... it would be lovely to have QuickTime on Linux. And there is no really justified reason why Apple doesn't just let the MPlayer people go under NDA and add support for the unsupported quicktime codecs, or provide those Xine people you mentioned with a limited license to use the relevant patents on UNIX. But the fact is that porting quicktime itself to UNIX in any form would be an absolutely huge undertaking. Did you notice how many *months* it took them just to port iTunes to Windows? And look at all the problems they've had with getting QT/iTunes to act like a "normal" Windows application (file associations, minimize to taskbar, etc). Just think of how much trouble they'd have trying to get Quicktime, a closed-source app, to be a good userland "citizen" on UNIX, which is not merely slightly different from MacOS as Windows is, but relatively totally alien?
Yeah, Real managed UNIX ports, but RealPlayer is at least an order of magnitude less complexity than the complicated multimedia management API that is QuickTime, and Real doesn't have to drag around a significant portion of their operating system API with them every time they port. QuickTime is much more complicated than just "open up a movie and play it".
You are misinterpreting things entirely. No one in this thread is complaining that GIMP does not act like a Cocoa app. The complaint is that the GIMP does something (palette windows) very poorly, that Cocoa has a functionality to do this same thing (palette windows) very well, and X11 and the GIMP fail to provide an equivilent functionality to perform the same set of things. (The fact some window managers have a "keep on top" option is nowhere near an equivilent functionality.) The comparison to Cocoa isn't "it should be like Cocoa to fit in with other OS X apps!", it's "it should be like Cocoa because that is an inherently better approach". Cocoa is only brought in as a demonstration of one option of how things might be done differently. One other option might be to abandon floating palettes.
You keep hiding behind "you haven't used gimp2!" but you have also done nothing to try to explain what gimp2 does that gimp1 doesn't to remedy this problem, and that isn't really the point anyway since if you will look at the context of things, my original post was in response to someone asking "People complain about the Gimp's many-windows approach but Photoshop for OSX uses the same many-windows approach. What's the difference?" and I was attempting to attack not so much the GIMP itself as the approach, epitomized in Gimp1, of doing palettes in X11 as many scattered windows.
They did, but it's the task of the Window Manager to do what you describe not GTK or X11. For example, I'm using WindowMaker right now and I just tried it and all I have to do is select "Keep on Top" from the window menu. No disrespect dude but it seems to me that your complaints, while perfectly valid, are the result of "not what I'm used to" syndrome and an unfamiliarity with the way things are done on UNIX.
**right clicks the window he's typing into right now**
**sees nothing along the lines of "keep on top" **
Well, apparently there is no such option in BlackBox.
While I understand the point you are trying to make, the thing is that what you are saying here is that because the complaints I bring up can be partially remedied by applying external software, my complaints can be boiled down to me "not being used to" UNIX. No, I do not think so. The thing is that except for the "docked tabs" feature, none of the things I described were endimic to photoshop. Floaters are in OS X the responsibility of the OS X window server, similar to how palette management in X11 is the repsonsibility fo the window manager. My point here is that the OS X GUI system contains functional support for a basic but elegant interface concept of windows designated as floating palettes, and X11 just offers some window managers some of which include hacks for trying to herd large numbers of windows.
Therefore it is not necessary for Photoshop to be responsible for coming up with a clean palette system. because Photoshop can just create a bunch of windows and OSX handles making this useable. It is necessary though for the Gimp to be repsonsible for this sort of thing, because the ICCCM or whatever is not expressive and the X server and window manager cannot provide this functionality on the GIMP's behalf either to my satisfaction or, it would appear, to the satisfaction of quite a number of other people in this thread. I would be disinclined to chalk this up to not being used to "the UNIX way of doing things" since I do not have these problems with other UNIX applications and the GIMP does not hehave like any other UNIX application I have ever seen.
So are you saying the palettes-float-poorly problem has been solved since version 1?
Gimp 2 has only been out a handful of *weeks*. I'm actually typing this from a gentoo linux machine right now. At some point I'll probably get around to emerging and trying out Gimp2 when I have time but honestly there's nothing compelling me to do so quickly.
However, since this entire story thread is-- in fact-- discussing a review of *the mac version* of Gimp2, and all indications are from the review that the issues I was discussing have not been solved in the Gimp2 for mac, I believe my experience with Gimp1 for mac are perfectly adequate to take part in this discussion.
But what about Photoshop on Mac OSX? It has multiple windows open at the same time, and is not an MDI interface like the Windows version? But people some how compare Gimp and Photoshop, and point to those multiple windows as a problem, but act like it doesn't exist on the Mac side? I just don't get it.
Because the toolbars on the mac are all "floaters". They use the Mac OS's nice, working support for the concept of windows which cannot accept the focus but which remain always accessible and "on top" and which are associated with an application rather than a file. As a result, the class of problems that make the many-windows approach of GIMP happen just aren't there.
You don't have to feel like you're managing all these windows because you aren't, just floaters. You can move them around or windowshade them without taking focus away from the file you're working on. You can close them,forget about them, and a minute later go back to the "windows" menu and resurrect it, and it will appear in the same position it was in before. (This is how floating palettes work in virtually every mac app.) You can go to another app, and come back, and they'll all come to the front at once along with the application, so you don't have the potential problem in linux where you have a gimp window with all these palettes but then you accidentally open four xterms and the palettes are kind of scattered all between them. You don't have to keep track of what file each palette belongs to, since the palettes just send their events to whichever file window has the focus. And since managing layered windows isn't such a chore, you can just open a bunch of stuff and not think about it as opposed to having to elaborately arrange all your windows and palettes in some convenient arrangement within your various virtual desktops. Also-- though this isn't just a Photoshop thing, this was a fad in graphics apps for awhile-- photoshop has this neat "docking" feature where you can pile multiple palettes into one tabbed megapalette and then tear them back out at will... It's just that in the photoshop implementation the many-windows approach is natural and in the gimp implementation it interferes with you.
Note, the above is based on experience using Gimp 1 on the OS X X11 some time ago. If GTK has managed to get some kind of intelligent floating palette support in since then, I wouldn't know about it. However, it is my understanding that the floater interface concept is still more or less still lacking good support in UNIX, and even if they did add it to recent GTKs or something, it would seem that it could only correctly operate on certain "blessed" window manager / OS combinations, or else the WM wouldn't know how to deal with all these quasianonyous windows. And the lack of decent "layering" in X (bring a window frontmost, all its palettes come frontmost) would still be a problem, it would seem to me. But the point is, X11 floaters didn't exist in any form on my primary OS when I used GIMP last, and they probably didn't either for the vast majority of the people complaining about the GIMP the last time they used it.
The problem with GIMP isn't with GIMP, but rather that people expect GIMP to work just like Photoshop.
If that's the case, then why don't we have these sort of interface complaints popping up about Corel Draw, or Painter, or.. well.. anything? There's a lot of graphics programs that aren't photoshop. but the sorts of complaints you hear from quite a lot of people about the Gimp just don't show up for other programs to anywhere near the same degree. "Well, it didn't have all the features photoshop did.", yeah, I hear that one sometimes, but generally not the constant Gimp complaint of "the interface was clunky and I couldn't figure out how to do what I wanted". You think there's a reason for that, maybe?
(1) "Configuring" was meant to refer to things like "tweaking the Preferences dialog". If I remember right from when I last used it, the Gimp did have a fairly configurable GUI. If I rememeber right, the defaults weren't terribly desirable and taking advantage of this was fairly necessary.
(3) Unless you use Fink, like I did. I read the article but mistakenly thought the $30-50 charge for the specific port in question was optional. Oh well.
The Gimp is free in terms of money. It is most certainly not free in terms of things like time spent configuring and downloading it, or wasted time spent trying to get used to its interface before realizing it just can't be done. The article we are responding to notes the Gimp to be monetarily free and then gives it a "value for money" score of 10%. I would be inclined to agree.
I made a concerted effort to start using the Gimp, beginning with the assumption that anything about the interface that didn't feel right to me was merely becuase I wasn't used to it and that once I got used to its idiom I would be as efficient with it as I would be with Photoshop. This turned out not to be the case.
What I would consider an acceptably designed tool is that once you are familiar with it, it just melts away into a comfortable sort of overlay where what you find yourself thinking of is what you're doing, not thinking about how to make the tool do what you want. It turns out that the Gimp interface, with its tools which do not work in logical or naturally synergistic ways and its interface consisting entirely of totally unrelated features scattered over a huge mess of heirarchal menus that seem to have the features sorted into them in random order, was just something I cannot get into a comfortable state with, no matter how much time I spent fighting with it. In fact, it was bad enough I couldn't actually manage to complete a single attempt at an image, no matter how small, to my satisfaction. The interface just got in the way too much. I would posit that this is the Gimp's fault, not mine.
Now, given, this was Gimp 1. The new Gimp that came out a couple weeks ago, I haven't used. But to be firmly honest I see no reason why I should. These people have given me no reason to believe they can design a useable interface. Installing this software would be a mere matter of typing "sudo emerge gimp" into my Gentoo box at home before I go to bed and letting it grind for the next day and a half. However, it would require a large investment of time in terms of learning, testing and playing with the Gimp2 interface, and I simply lack any reason to believe that there will be any sort of worthwhile payoff for this cost of time. I would prefer to continue with my current situation of using imagemagick to convert formats and only being able to edit images while in a computer lab on campus. To be honest, while I am somewhat embarrased to be saying this, if I DO eventually try out Gimp2, it will be for the sole reason that once I do so I will be able to respond to Slashdot discussions about it like this one in an informed manner. The software program itself simply does not offer anything I am interested in using.
If they would be honest A LOT of home users SHOULD use the GIMP instead of using an illegal version of Photoshop.
I disagree. There are other free and inexpensive alternatives to the Gimp that perform their jobs far better. One that comes to mind is GraphicConverter, a very cheap shareware graphics app for OS X that I used for years (though I haven't used it much since the OS X switch) that while by no means professional is totally acceptable for a large variety of applications. It doesn't have as many OH SUPER LEET TEXT EFFECTS as the Gimp does but I or anyone else could sit down, immediately understand how to do what they want, and perform tasks of relative complexity without being stymied by the interface. The same is not true of the GIMP. I am not familiar with windows freeware but I would imagine a similar situation exists there.
As far as my understanding goes, the reason Java has this problem is becuase it uses a mark-and-sweep garbage collector. What this means is that every time the garbage collector runs, it has to "touch" every single object in the system-- that is, the way it works is, it basically looks at every single object accessable in the system and marks it as "YEP, STILL ALIVE!". And essentially, any objects that don't have an "alive" marking afterward can be considered inaccessable and therefore reclaimable space. That's just how it works, and this necessarily requires it to access the memory of every object in the Java system, hence entirely reordering whatever your virtual memory/processor cache thought it was doing just previously. There isn't a lot that can be done about this.
The generational garbage collector used in newer Java virtual machines will probably help with this problem greatly. Generational garbage collectors assume that anything that survives for a couple of collections is probably going to be around for a very long time, so if something survives a collection or two, further collections (unless space REALLY starts getting low) just ignore it and assume it to be still-live without actually checking to see if it is. This can significantly reduce the amount of memory that has to be touched, and so it would probably decrease the number of memory pages the virtual machine needs swapped in on each GC run.
My girlfriend switched from normal to diet soda at the beginning of this semester. Very shortly afterward, she began to have debilitating headaches. Unfortunately, we failed to make any connection. These headaches continued until two weeks ago when she learned about the concept of "aspartame sensitivity" and stopped drinking aspartame products. Her health dramatically reversed the next day.
Would you like to call her a "kook", or imply I am somehow an astroturfer in the pay of Diet Rite?
GrokLaw is PJ's blog, sometimes she does bloggy things. That's her perogative. She also happens to provide an awful lot of truly useful information and analysis on certain subjects, though, so Groklaw is still worth reading.
No, this shouldn't be newsworthy, but these days on Slashdot it would appear the editors consider anything that bashes Sun to be newsworthy. Even if it's a blog post.
Besides, it's interesting. This Java Desktop System is a huge deal. First off, Sun, one of the last few Big UNIX general vendors, is not only making movements toward Linux but actually selling Linux as a new product. This hints at a decent number of things about what the UNIX vs Linux battles of the next ten years are going to look like. Second off, this is an attempt to make a desktop distribution of Linux by a company with the funding and concentration to actually pull it off.. either of these two things makes JDS a crucially important development whether it succeeds or fails, but it's getting very little attention in either the "real world" or the open-source news. I think the whole JDS thing is underreported, honestly. This article might not be the best analysis of JDS out there, but it's something.
PJ does really seem to hate Sun though. I'm not sure why. I think it's probably because they gave a big donation to SCO's legal funds (pretty reasonable reason to hate them, actually).
Slashdot Mirror
Ummmm... maybe line 5286 was whitespace?
Okay, so one line of whitespace for several hundred of code isn't a lot. But it was very sloppy hypothetical code!
Oh, all right, I admit it, I made an off-by-one error. I'll go sit in the corner now wearing the big dunce hat with "PASCAL" written on it.
It's only a major threat if you haven't updated your machine. If you are behind in updates, then you should be infected. Period, end of story.
Not really. I know someone on another discussion board who in the last week had the necessity for what I am pretty sure were unrelated reasons of reinstalling Windows. Within the *ten minute* window between Windows successfully being installed off the CD and the new patches being downloaded off Windows Update and installed, his machine got worm infected and became unusable. So he's having the problem of being unable to do anything with his computer since he can't get to a position after reinstalling where he makes his computer impervious to worms without having to briefly expose himself to the worm. I think the advice he was given was to disconnect the computer from the internet, reintall, and do some stuff with the WinXP firewall before connecting to the internet. I haven't seen him online since then so I don't know if it worked.
It's a little harder to patch an install CD, unless you have powerful laser beams that you can shoot out of your eyes or something.
- One is simply very quiet about security period.
- The other one makes a huge deal constantly about how they are improving their security, how they've changed their ways this time really and they're sending all their programmers to a 4-week course on how to not write buffer overflows, and windows is the most secure OS more than any of the competitors, etc.... while simultaneously trying to keep things as hushhush as they practically can about vulnerabilities and publically and loudly blaiming public informedness about security vulnerabilities for the fact the security holes they wrote are being exploited.
One of these two companies is being silly. The other one is being actively hypocritical and duplicitous.Because the thing is that Novell is selling linux, and in fact owns SUSE and Ximian, and as a result are bound by the terms of the GPL.
The neat thing about the GPL is its seemingly foolproof method of making sure everyone plays fair: they make it in everyone's interests to play fair, by making everyone not just borrow from everyone else, but depend on everyone else.
For example, let's say a company releases a piece of software under the GPL, then the next day decides to recant and announces that no, we changed our mind, it wasn't GPLed after all. If the company never sold anyone a copy, just put it up for download on a website, well then, who's to disagree with them? If someone had given them money for it that could be construed as having some sort of contractual validity, and the license that they included when they originally distributed the license irrevocable. But if it was just a free download, and the license included with the download as a written offer... well that's kind of fuzzier, isn't it? It would seem the company couldn't "go back" on their license offer, but the company could claim all kinds of things. They could claim the release was "unauthorized", or not intended for public release outside the company, or there were mitigating copyright and contractual cirucmstances the company was not aware of at the time doctrine of mutual mistake blah blah blah. And if this were the BSD license, that's where things would end.
But the GPL, among doing other things, adds an interesting wrinkle to things by legally intertwining to a certain extent everyone who cooperates using it. If someone releases some code they own under the GPL, they still own it and can do whatever they like with that code outside the context of the GPLed product However if someone is distributing or redistributing a product containing someone else's GPL code-- anyone's-- then they suddenly find themselves with a small and reasonable, but important, set of obligations.
So, here's another hypothetical example. Let's say Novell announces they own lines 5000-5435 of the linux kernel; that those lines were stolen from NetWare by a disgruntled employee who then submitted them to Linux as his own work at some point; that they have indisputable proof of this; and they further announce that anyone who wants to sell linux owes them $699 a copy for Novell's 435 lines of code there.
The problem here is that they can't do that; the instant Novell points out those 435 lines of code are unlicensed, distributing Linux becomes illegal, period. The reason for this is that the GPL says that in order to distribute under the GPL, you must be able to offer to anyone who you distribute it to an unlimited GPL license themselves, which includes the right to freely redistribute and modify. If you don't have the rights to distribute Linux under the GPL, you certainly don't have the right to distribute Linux by any other mechanism. And if you have to pay $699 to distribute the Linux kernel, then you don't have the right to distribute it under the GPL. The rest of Linux, everything except those 435 lines, is still GPLed and freely distributable; but the whole package, or any package that contains those 435 non-Free lines linked against GPL code, is something nobody-- including Novell-- has the right to distribute at all until those lines are removed or replaced.
So, Novell currently lacks the ability to attack Linux in this fashion without losing the right to sell Linux in the process-- which would be a major problem for them since they currently have a decent amount riding on their Linux-based products. And the really fun thing is, if Novell does as SCO did after raising their apparently fraudulent claims against Linux, and continues to distribute Linux even after they make the public claim that they own code in Linux that they never gave Linux a license to, then one of
Yes, I followed the links. They give me a pretty clear idea of how the NRF wishes to portray themselves, and seems to indicate that this is something of a largish public relations coup for the anti-SCO side of all this (I.E. everybody) which will serverely hamper SCO's efforts to convince small businesses they should let SCO extort money from them.
:)
However, it says very little about whether they hold any sort of capitalizable political power, or whether there's anything I missed giving the NRF direct relevance to SCO's legal cases, and I wondered if anyone here had had direct dealings with them and could give some sort of anecdotal demonstration of their actual importance. I was trying to, how you say, "provoke discussion".
So, who's the National Retail Foundation and why does their opinion matter?
Just curious.
n/t
I was *just* recently sitting here and wondering if there was anything Microsoft could have done to squander the product, userbase and public goodwill MS inherited when they bought Hotmail that they haven't done already.
/. article right now..
I couldn't think of anything
I guess I'm just not as imaginative as MS.
I'll bet the GMail team is doing a little dance of joy at reading this
Its quite unlikely to be as big as Paris or any other bigger city
:)
What about Paris, Texas?
How exactly is the JDS "tailored to" Java? I thought I'd I heard the Java in the title was just a brandname and the GUI was GNOME. Or do you just mean that it comes with a high-quality JVM as opposed to the crud Windows or most web browsers ship with?
I know very little about the JDS but I'm curious.
JUST RELEASED, AND ALREADY HACKED!!!! Ok, not yet. But, as with anything DRM, give it a couple months after getting out of this concept phase.
Here's a better way of looking at this. This hasn't been fully released yet, and it has already been "hacked", in the sense that the NSA already has gotten their plants and bugs inside Microsoft* to steal and relay to them all of the plans for how this system will be used and implemented as well as all the keys that make it work.
(Clarification: That's the neat thing about "trusted computing" from their perspective-- it would mean every system in the world would be "trustable", but that trust would have a single point of failure: Microsoft's guarded private cryptographic keys for Janus/Palladium. So all you have to get a copy of those keys and you can do anything you want...)
* Further clarification: I base my belief in the existence on said plants on the simple observation that if the NSA doesn't have plants inside Microsoft, then they're completely incompetent.
Oh, and human tissue that grows out of control doesn't become huge and monstrous. It becomes cancer, and kills its own flesh & blood.
Well, that certainly makes for boring science fiction, doesn't it?
How do the stem cells know when to *stop* growing the tooth? I mean, clearly there's something telling them when they're done but what happens if something goes wrong? What happens if you drop these things in someone's gum, and it starts growing a tooth, but the shutoff mechanism for the stem cells never activates.. so it just keeps growing.. and growing.. and growing...
LONDON, ENGLAND... A HUGE, WHITE MASS LOOMS OVER THE BUILDINGS ON THE HORIZON
WOMAN, FRIGHTENED AND DRAWING BACK: My God... what is it??
MAN, STANDING BACK DRAMATICALLY: It is... The Tooth.
The problem is not that API it's the dev tool. This guy likes xcode. Xcode is great if you want to code in objective-c but it sucks if you want to code in java. It also does not support any other language.
Apple is actively trying to bring the Java support up to the same level of quality as the Objective C support and it's getting better with every release.
As far as "other languages" go, well, XCode has builtin support for C, C++, Objective C and Java. That's not exactly bad. And while these are the only language it comes in with builtin compile support for, it does contain highlighting semantics for a decent number of other languages. I use it to write Perl all the time (and really, what do you need out of a Perl dev tool besides syntax highlighting?).
XCode also happens to be very modular, so adding additional "support" to XCode for additional languages should be something third parties are perfectly capable of. I'm not sure if they could hook into CodeSense or a few of the more advanced features of the debugger, but if you're trying to add support for a language I'm just about certain you could easily define just about whatever syntax highlighting and build process rules that you would like. (Of course, good luck trying to find the documentation that describes how to do all this...)
Instead of wasting time and money on xcode apple should join the eclipse group and make sure there is a decent plug in for webobjects (yes I know about wolips) and objective c.
I'm really kind of going to have to assume from this statement that you are not a Cocoa developer. (Of course, if what you're telling us here is that you're a WebObjects developer, then that neatly explains your animosity toward XCode, since youall have kind of gotten the shaft lately).
For Cocoa developers, Apple's Developer tools are EXCELLENT and all fit together with each other and with XCode in a very pleasant manner. And they're getting better and more elaborate with every release. I would say that the developer tools are almost as much a reason to use Cocoa as the API itself. I routinely give XCode as one of the main things I like about OS X development. I'm not sure what Apple would stand to gain by throwing it all out and starting over with a different set of tools which, while nice, aren't exactly targetted for Apple's needs. XCode meanwhile is finely tuned to Cocoa development and is getting moreso all the time...
Finally they should give serious thought to abanding objective C. Yes it's a great language but let's admit that people don't want to spend time learning it. Switch to python or ruby or something and be done with it.
First, there are python bindings for Cocoa already; I don't know if anyone's managed to integrate them into XCode yet. Second, I totally fail to see how-- if people won't bother to learn Objective C because they can't be bothered to get used to square brackets for method calls-- Apple is going to have any better luck at all with convincing people to learn Python, which is totally unlike anything the vast majority of people are used to. (Yes, it's a quick learn, but the problem with ObjC isn't getting people to learn it, the problem is getting people to WANT to learn it.)
That is patently ridiculous. Apple supports QT on Windows. They have free downloads for Windows. It wouldn't cost any more to have free downloads for a couple *nixes.
Wha?
You are saying that developing from the ground up a port of a very complicated and optimized set of libraries and GUI applications onto a platform which not only does Apple have zero infrastructure for in terms of personell which know how to develop for it, not only is this platform the single most diverse in terms of hardware and software configurations in the world, but also you can't assume the presence of a usable GUI widget toolkit and there isn't even really a single totally universally accepted method of sound playback... would be something that would be zero cost to Apple?
I'm sorry... it would be lovely to have QuickTime on Linux. And there is no really justified reason why Apple doesn't just let the MPlayer people go under NDA and add support for the unsupported quicktime codecs, or provide those Xine people you mentioned with a limited license to use the relevant patents on UNIX. But the fact is that porting quicktime itself to UNIX in any form would be an absolutely huge undertaking. Did you notice how many *months* it took them just to port iTunes to Windows? And look at all the problems they've had with getting QT/iTunes to act like a "normal" Windows application (file associations, minimize to taskbar, etc). Just think of how much trouble they'd have trying to get Quicktime, a closed-source app, to be a good userland "citizen" on UNIX, which is not merely slightly different from MacOS as Windows is, but relatively totally alien?
Yeah, Real managed UNIX ports, but RealPlayer is at least an order of magnitude less complexity than the complicated multimedia management API that is QuickTime, and Real doesn't have to drag around a significant portion of their operating system API with them every time they port. QuickTime is much more complicated than just "open up a movie and play it".
You are misinterpreting things entirely. No one in this thread is complaining that GIMP does not act like a Cocoa app. The complaint is that the GIMP does something (palette windows) very poorly, that Cocoa has a functionality to do this same thing (palette windows) very well, and X11 and the GIMP fail to provide an equivilent functionality to perform the same set of things. (The fact some window managers have a "keep on top" option is nowhere near an equivilent functionality.) The comparison to Cocoa isn't "it should be like Cocoa to fit in with other OS X apps!", it's "it should be like Cocoa because that is an inherently better approach". Cocoa is only brought in as a demonstration of one option of how things might be done differently. One other option might be to abandon floating palettes.
You keep hiding behind "you haven't used gimp2!" but you have also done nothing to try to explain what gimp2 does that gimp1 doesn't to remedy this problem, and that isn't really the point anyway since if you will look at the context of things, my original post was in response to someone asking "People complain about the Gimp's many-windows approach but Photoshop for OSX uses the same many-windows approach. What's the difference?" and I was attempting to attack not so much the GIMP itself as the approach, epitomized in Gimp1, of doing palettes in X11 as many scattered windows.
They did, but it's the task of the Window Manager to do what you describe not GTK or X11. For example, I'm using WindowMaker right now and I just tried it and all I have to do is select "Keep on Top" from the window menu. No disrespect dude but it seems to me that your complaints, while perfectly valid, are the result of "not what I'm used to" syndrome and an unfamiliarity with the way things are done on UNIX.
**right clicks the window he's typing into right now**
**sees nothing along the lines of "keep on top" **
Well, apparently there is no such option in BlackBox.
While I understand the point you are trying to make, the thing is that what you are saying here is that because the complaints I bring up can be partially remedied by applying external software, my complaints can be boiled down to me "not being used to" UNIX. No, I do not think so. The thing is that except for the "docked tabs" feature, none of the things I described were endimic to photoshop. Floaters are in OS X the responsibility of the OS X window server, similar to how palette management in X11 is the repsonsibility fo the window manager. My point here is that the OS X GUI system contains functional support for a basic but elegant interface concept of windows designated as floating palettes, and X11 just offers some window managers some of which include hacks for trying to herd large numbers of windows.
Therefore it is not necessary for Photoshop to be responsible for coming up with a clean palette system. because Photoshop can just create a bunch of windows and OSX handles making this useable. It is necessary though for the Gimp to be repsonsible for this sort of thing, because the ICCCM or whatever is not expressive and the X server and window manager cannot provide this functionality on the GIMP's behalf either to my satisfaction or, it would appear, to the satisfaction of quite a number of other people in this thread. I would be disinclined to chalk this up to not being used to "the UNIX way of doing things" since I do not have these problems with other UNIX applications and the GIMP does not hehave like any other UNIX application I have ever seen.
So are you saying the palettes-float-poorly problem has been solved since version 1?
Gimp 2 has only been out a handful of *weeks*. I'm actually typing this from a gentoo linux machine right now. At some point I'll probably get around to emerging and trying out Gimp2 when I have time but honestly there's nothing compelling me to do so quickly.
However, since this entire story thread is-- in fact-- discussing a review of *the mac version* of Gimp2, and all indications are from the review that the issues I was discussing have not been solved in the Gimp2 for mac, I believe my experience with Gimp1 for mac are perfectly adequate to take part in this discussion.
But what about Photoshop on Mac OSX? It has multiple windows open at the same time, and is not an MDI interface like the Windows version? But people some how compare Gimp and Photoshop, and point to those multiple windows as a problem, but act like it doesn't exist on the Mac side? I just don't get it.
Because the toolbars on the mac are all "floaters". They use the Mac OS's nice, working support for the concept of windows which cannot accept the focus but which remain always accessible and "on top" and which are associated with an application rather than a file. As a result, the class of problems that make the many-windows approach of GIMP happen just aren't there.
You don't have to feel like you're managing all these windows because you aren't, just floaters. You can move them around or windowshade them without taking focus away from the file you're working on. You can close them,forget about them, and a minute later go back to the "windows" menu and resurrect it, and it will appear in the same position it was in before. (This is how floating palettes work in virtually every mac app.) You can go to another app, and come back, and they'll all come to the front at once along with the application, so you don't have the potential problem in linux where you have a gimp window with all these palettes but then you accidentally open four xterms and the palettes are kind of scattered all between them. You don't have to keep track of what file each palette belongs to, since the palettes just send their events to whichever file window has the focus. And since managing layered windows isn't such a chore, you can just open a bunch of stuff and not think about it as opposed to having to elaborately arrange all your windows and palettes in some convenient arrangement within your various virtual desktops. Also-- though this isn't just a Photoshop thing, this was a fad in graphics apps for awhile-- photoshop has this neat "docking" feature where you can pile multiple palettes into one tabbed megapalette and then tear them back out at will... It's just that in the photoshop implementation the many-windows approach is natural and in the gimp implementation it interferes with you.
Note, the above is based on experience using Gimp 1 on the OS X X11 some time ago. If GTK has managed to get some kind of intelligent floating palette support in since then, I wouldn't know about it. However, it is my understanding that the floater interface concept is still more or less still lacking good support in UNIX, and even if they did add it to recent GTKs or something, it would seem that it could only correctly operate on certain "blessed" window manager / OS combinations, or else the WM wouldn't know how to deal with all these quasianonyous windows. And the lack of decent "layering" in X (bring a window frontmost, all its palettes come frontmost) would still be a problem, it would seem to me. But the point is, X11 floaters didn't exist in any form on my primary OS when I used GIMP last, and they probably didn't either for the vast majority of the people complaining about the GIMP the last time they used it.
The problem with GIMP isn't with GIMP, but rather that people expect GIMP to work just like Photoshop.
If that's the case, then why don't we have these sort of interface complaints popping up about Corel Draw, or Painter, or.. well.. anything? There's a lot of graphics programs that aren't photoshop. but the sorts of complaints you hear from quite a lot of people about the Gimp just don't show up for other programs to anywhere near the same degree. "Well, it didn't have all the features photoshop did.", yeah, I hear that one sometimes, but generally not the constant Gimp complaint of "the interface was clunky and I couldn't figure out how to do what I wanted". You think there's a reason for that, maybe?
(1) "Configuring" was meant to refer to things like "tweaking the Preferences dialog". If I remember right from when I last used it, the Gimp did have a fairly configurable GUI. If I rememeber right, the defaults weren't terribly desirable and taking advantage of this was fairly necessary.
(3) Unless you use Fink, like I did. I read the article but mistakenly thought the $30-50 charge for the specific port in question was optional. Oh well.
Well, here's a suggestion. DON'T USE IT!
I don't. Expressing that was the entire point of my post.
The Gimp is free in terms of money. It is most certainly not free in terms of things like time spent configuring and downloading it, or wasted time spent trying to get used to its interface before realizing it just can't be done. The article we are responding to notes the Gimp to be monetarily free and then gives it a "value for money" score of 10%. I would be inclined to agree.
I made a concerted effort to start using the Gimp, beginning with the assumption that anything about the interface that didn't feel right to me was merely becuase I wasn't used to it and that once I got used to its idiom I would be as efficient with it as I would be with Photoshop. This turned out not to be the case.
What I would consider an acceptably designed tool is that once you are familiar with it, it just melts away into a comfortable sort of overlay where what you find yourself thinking of is what you're doing, not thinking about how to make the tool do what you want. It turns out that the Gimp interface, with its tools which do not work in logical or naturally synergistic ways and its interface consisting entirely of totally unrelated features scattered over a huge mess of heirarchal menus that seem to have the features sorted into them in random order, was just something I cannot get into a comfortable state with, no matter how much time I spent fighting with it. In fact, it was bad enough I couldn't actually manage to complete a single attempt at an image, no matter how small, to my satisfaction. The interface just got in the way too much. I would posit that this is the Gimp's fault, not mine.
Now, given, this was Gimp 1. The new Gimp that came out a couple weeks ago, I haven't used. But to be firmly honest I see no reason why I should. These people have given me no reason to believe they can design a useable interface. Installing this software would be a mere matter of typing "sudo emerge gimp" into my Gentoo box at home before I go to bed and letting it grind for the next day and a half. However, it would require a large investment of time in terms of learning, testing and playing with the Gimp2 interface, and I simply lack any reason to believe that there will be any sort of worthwhile payoff for this cost of time. I would prefer to continue with my current situation of using imagemagick to convert formats and only being able to edit images while in a computer lab on campus. To be honest, while I am somewhat embarrased to be saying this, if I DO eventually try out Gimp2, it will be for the sole reason that once I do so I will be able to respond to Slashdot discussions about it like this one in an informed manner. The software program itself simply does not offer anything I am interested in using.
If they would be honest A LOT of home users SHOULD use the GIMP instead of using an illegal version of Photoshop.
I disagree. There are other free and inexpensive alternatives to the Gimp that perform their jobs far better. One that comes to mind is GraphicConverter, a very cheap shareware graphics app for OS X that I used for years (though I haven't used it much since the OS X switch) that while by no means professional is totally acceptable for a large variety of applications. It doesn't have as many OH SUPER LEET TEXT EFFECTS as the Gimp does but I or anyone else could sit down, immediately understand how to do what they want, and perform tasks of relative complexity without being stymied by the interface. The same is not true of the GIMP. I am not familiar with windows freeware but I would imagine a similar situation exists there.
As far as my understanding goes, the reason Java has this problem is becuase it uses a mark-and-sweep garbage collector. What this means is that every time the garbage collector runs, it has to "touch" every single object in the system-- that is, the way it works is, it basically looks at every single object accessable in the system and marks it as "YEP, STILL ALIVE!". And essentially, any objects that don't have an "alive" marking afterward can be considered inaccessable and therefore reclaimable space. That's just how it works, and this necessarily requires it to access the memory of every object in the Java system, hence entirely reordering whatever your virtual memory/processor cache thought it was doing just previously. There isn't a lot that can be done about this.
The generational garbage collector used in newer Java virtual machines will probably help with this problem greatly. Generational garbage collectors assume that anything that survives for a couple of collections is probably going to be around for a very long time, so if something survives a collection or two, further collections (unless space REALLY starts getting low) just ignore it and assume it to be still-live without actually checking to see if it is. This can significantly reduce the amount of memory that has to be touched, and so it would probably decrease the number of memory pages the virtual machine needs swapped in on each GC run.
My girlfriend switched from normal to diet soda at the beginning of this semester. Very shortly afterward, she began to have debilitating headaches. Unfortunately, we failed to make any connection. These headaches continued until two weeks ago when she learned about the concept of "aspartame sensitivity" and stopped drinking aspartame products. Her health dramatically reversed the next day.
Would you like to call her a "kook", or imply I am somehow an astroturfer in the pay of Diet Rite?
GrokLaw is PJ's blog, sometimes she does bloggy things. That's her perogative. She also happens to provide an awful lot of truly useful information and analysis on certain subjects, though, so Groklaw is still worth reading.
No, this shouldn't be newsworthy, but these days on Slashdot it would appear the editors consider anything that bashes Sun to be newsworthy. Even if it's a blog post.
Besides, it's interesting. This Java Desktop System is a huge deal. First off, Sun, one of the last few Big UNIX general vendors, is not only making movements toward Linux but actually selling Linux as a new product. This hints at a decent number of things about what the UNIX vs Linux battles of the next ten years are going to look like. Second off, this is an attempt to make a desktop distribution of Linux by a company with the funding and concentration to actually pull it off.. either of these two things makes JDS a crucially important development whether it succeeds or fails, but it's getting very little attention in either the "real world" or the open-source news. I think the whole JDS thing is underreported, honestly. This article might not be the best analysis of JDS out there, but it's something.
PJ does really seem to hate Sun though. I'm not sure why. I think it's probably because they gave a big donation to SCO's legal funds (pretty reasonable reason to hate them, actually).