CIS does a lot of programming, too. I think the difference is, with CIS I can use a compiler and OS. With CIS I can build a compiler and OS, and probably have already done so for a term project. However, most companies will hire either, because there are _many_ CIS programs that are called CS programs
Also, so much of it has been backported to the "stable" series, that we could call 2.2.18/19 2.4, and simply say that the current version will be 2.6. It's just a matter of what you want to call it. In fact, we could just leave 2.4 in perpetual test mode, and allow things to be backported to 2.2 whenever they get stable. It would have the same net result.
The fact of the matter is that if you blow a date, then something went wrong somewhere.
While this is true, I have yet to see any project in any area (art/cs/marketting/whatever) where something didn't go wrong somewhere. THINGS ALWAYS GO WRONG. There's nothing wrong with blowing dates. Especially when doing development. Implementation is a little different. For example, it should take a known quantity of time to install Linux on a computer. It takes an unkown quantity of time to create Linux. The reason - one is development, the other is implementation. Implementation deals with many more known quantities than development, and is thus subject to delays. This is why MS was so late at delivering NT5. In development, you don't know what the obstacles are. In implementation, you know a lot more of them. Therefore, developers should never be criticized solely for not achieving time frames.
I thought DOM/XML only applies to client-renderin, not server rendering. I'm sure it doesn't handle _anything_ like database queries and the like (you could have a template that included DB queries).
Re:great program, but it isn't keeping up
on
Gimp 1.2.0 Released
·
· Score: 3
A few things:
1) Doing things automatically, like image-type conversions for saving, is _not_ user-friendly. That's a terrible interface, because the user just thinks he's saving, when in fact, he is both saving and converting. That is very, very bad. File formats are more than just internal representation differences. The differences show up on the outside, too.
2) In GIMP 1.2, for most conversions, it will actually notify you of the problem, and pop up a new window to show you what the preview of the saved version will look like. That is a _great_ design. You are both notified of the problem, and started into the process of fixing it. It works wonderfully.
3) I actually prefer GIMP's user interface to most others I've seen. It doesn't take a lot of screen space, everything is easy to get to, and it just works really well. For newbies, having to right-click on the image sometimes takes getting used to, but once you tell them about it, within a day they love it!
Re:Why would anyone bother with PhotoShop now ???
on
Gimp 1.2.0 Released
·
· Score: 1
I don't see how having it as an "optional" feature differs much from it being a "primary" feature. GIMP is structured so that everything in it is a plugin.
Re:Why would anyone bother with PhotoShop now ???
on
Gimp 1.2.0 Released
·
· Score: 2
Hmmm... does it do CMYK, duotones, or Pantone colors yet?
No.
How about editable type?
Yes!
With kerning and leading controls?
Don't know enough about these
Support any color management systems, or is it just for low-end web only graphics?
Don't know enough about it
How many levels of undo?
Not sure exactly, but I've never hit it before
Recordable history?
Like macros? No, but it does have _very_ good scripting support. Check out http://www.cooltext.com/ to see what can be done with a little scripting.
Actually, they can only use their own contributions for that. They cannot use the contributions of other Linux people for their own projects, even if they do that before a "release"
by "supporting linux", we're not talking about porting proprietary programs, we're talking about extending linux itself - which they have done quite well.
Postfix - the greatest mailer ever - checkout postfix.org
Port to S390 - again a great accomplishment
Jikes compiler - great stuff
JFS - this will be killer when its done
Releasing open hardware boards for LinuxPPC
Modifying the kernel so it can run heavily multithreaded apps better
There's probably a million things I haven't thought of, too.
These things are great for _every_ distribution. Everyone has benefitted from IBM's help, even if their proprietary stuff only runs on RPM-based distros.
FreeBSD is great. However, there are several problems with it.
For example, if you're IBM, you're thinking "if we put all our stuff under the BSD License, MS can just hijack it" which is definitely not what they want. With the GPL, they have a layer of protection against that.
Another thing is that speed isn't everything. FreeBSD is great for things that must be fast, but that's not everything. There's system management, functionality (like proxies/firewalls/etc), and the rest. Linux actually has better support for advanced features (process migration, checkpointing, a few extra networking protocols). For the basics, FreeBSD does it faster. However, Linux has more functionality. In addition, there is the number of support channels available.
Another thing to remember, is that all of the BSDs are distributions. Therefore, if IBM wants to expand it, they have to do so along the road of the full distribution. That limits what they can do. With Linux, they can still call themselves "Linux" and have their own distribution, or allow people to choose from several.
There are good reasons to go with the BSDs, but also remember there are good reasons to go with Linux. Apple chose FreeBSD, IBM chose Linux. I think in the end Linux will win out, though, because the license gives a better amount of protection to corporations. People say that RMS isn't corporate-friendly, but his license actually caters better to corporations than others in many respects. Why would a corporation give code under a BSD license, when their competitor can take it and "embrace/extend" it?
I think one of the best things that RMS can do is to make sure that the GPL and the IBM public license work together. I don't think RMS should give as far as ideals go, but they should probably meet and work out the license differences, so that IBM Public License contributions are fully integrateable with everything else.
It can _easily_ be configured to provide a serial console. It requires changing about 3 lines in config files and running lilo. Most Sparc distributions allow you to install and run direct from a serial console by simply typing
You don't want it working exactly like Word, that would destroy the whole idea. Having a nice GUI is fine, great in fact. However, it should work semantically. And, no, the people typing don't have to worry about DTD restrictions and XSL - that's handled by the application. Look on freshmeat for Morphon to see a good XML application for end-users.
It actually has nothing to do with mentioning preference. There is quite a bit of difference between saying "I like KDE better than GNOME because..." and "Those GNOME people really suck at this". In addition, if you had read the other responses, you would know that, actually, GNOME did this first, so its a moot point anyway. KDE and GNOME are both great. I generally like the way GNOME works better, but I think the KDE people have done a wonderful job. I also appreciate TrollTech doing the right thing and putting QT under a free license. That was absolutely wonderful. Great things have come out of both camps - each of the office systems have their strengths and weaknesses. However, trashing one or the other does no good whatsoever.
An in-process component is one that is implemented simply by loading a library. An out-of-process component is one that runs in its own process. With in-process components, everything shares the same address space, and method calls are made directly. With out-of-process components, the components are in a different address space/process than their containers, and thus must communicate using pipes/sockets/something other than a direct method call. They have some added benefits, like not having to use the same toolkit as the parent component. As was mentioned in the article, glib and KDE both have their own event loops, which vary quite drastically. Trying to fit them in together in the same process space is quite difficult. However, if they can each run on their own, you have fewer problems with that. However, it adds complexity to the communication between parent and components.
I was actually replying to a previous post, which essentially said that the GNOME people were losers for not doing this first. I was just bringing up the point that they did do it first. I'm sorry if my tone sounded negative, it was only meant to be negative to the person who made the first post, not to either team.
Just so you'll know, after looking over the white paper a little bit, it ends up that this is actually KDE playing catch-up to GNOME. X-Parts does not allow embedding of arbitrary GNOME component into KDE. It only allows embedding of out-of-process components into KDE, which GNOME has had for a long time. GNOME's embedding also does not require any specific toolkit (see OpenOffice as an example). No, Konquerer did not have to be modified to do this, but Mozilla _did_. This support has been in GNOME for some time.
Remember, this does not allow the arbitrary embedding of any GNOME component. It requires a wrapper for each GNOME component before being embedded. This is currently available for GNOME.
I'm not trying to discount what they've done - its very, very great! But I don't want people misunderstanding it either. I'm looking forward to the day when arbitrary components from either can be embedded. Whoever does it first will simply give the other person something to build from. Let's stop fighting, calling names, whatever. It's a great day, and let's be happy.
This is great news for Linux desktops. The KDE people did a wonderful job here. However, I don't see how you can possibly say "KDE is cooperating and GNOME is doing nothing". That's just being a troll. The wars are over. Put your guns down. Now there's just friendly competition. They worked together to make a Window Manager spec, and I'm sure eventually someone will make a bonobo interface for embedding KDE components. But please, don't tarnish this great moment by turning it into a flamefest.
Use processes instead of threads in as many places as make sense. This makes many of your problems simply vanish. It makes you rethink your design in a much more thorough and thoughtful fashion, choosing distinct parts with obvious interfaces.
The argument is about what he _should_ be allowed to do, not what the law currently allows him to do. You haven't responded to that part, only to the question of legality of the maneuvers.
The idea is "Don't bite the hand that feeds you". Because Apple is gaining so much from OSS, it seems strange that they would sue over a few icons. It's like me giving you a house but you taking me to court for stealing $100 from you. It's your legal right, but it sure is stupid.
Actually, the whole point of the HURD is so that the application developers _can_ do gee whiz stuff. Like implementing filesystems. The HURD allows code NOT PREVIOUSLY POSSIBLE WITH OTHER KERNELS.
Actually, this is probably more due to the priority you are giving your X server. I reniced my X server, window manager, and panel to -20 and got _really_ nice results.
Slashdot Mirror
CIS does a lot of programming, too. I think the difference is, with CIS I can use a compiler and OS. With CIS I can build a compiler and OS, and probably have already done so for a term project. However, most companies will hire either, because there are _many_ CIS programs that are called CS programs
Also, so much of it has been backported to the "stable" series, that we could call 2.2.18/19 2.4, and simply say that the current version will be 2.6. It's just a matter of what you want to call it. In fact, we could just leave 2.4 in perpetual test mode, and allow things to be backported to 2.2 whenever they get stable. It would have the same net result.
While this is true, I have yet to see any project in any area (art/cs/marketting/whatever) where something didn't go wrong somewhere. THINGS ALWAYS GO WRONG. There's nothing wrong with blowing dates. Especially when doing development. Implementation is a little different. For example, it should take a known quantity of time to install Linux on a computer. It takes an unkown quantity of time to create Linux. The reason - one is development, the other is implementation. Implementation deals with many more known quantities than development, and is thus subject to delays. This is why MS was so late at delivering NT5. In development, you don't know what the obstacles are. In implementation, you know a lot more of them. Therefore, developers should never be criticized solely for not achieving time frames.
I thought DOM/XML only applies to client-renderin, not server rendering. I'm sure it doesn't handle _anything_ like database queries and the like (you could have a template that included DB queries).
A few things:
1) Doing things automatically, like image-type conversions for saving, is _not_ user-friendly. That's a terrible interface, because the user just thinks he's saving, when in fact, he is both saving and converting. That is very, very bad. File formats are more than just internal representation differences. The differences show up on the outside, too.
2) In GIMP 1.2, for most conversions, it will actually notify you of the problem, and pop up a new window to show you what the preview of the saved version will look like. That is a _great_ design. You are both notified of the problem, and started into the process of fixing it. It works wonderfully.
3) I actually prefer GIMP's user interface to most others I've seen. It doesn't take a lot of screen space, everything is easy to get to, and it just works really well. For newbies, having to right-click on the image sometimes takes getting used to, but once you tell them about it, within a day they love it!
I don't see how having it as an "optional" feature differs much from it being a "primary" feature. GIMP is structured so that everything in it is a plugin.
No.
How about editable type?
Yes!
With kerning and leading controls?
Don't know enough about these
Support any color management systems, or is it just for low-end web only graphics?
Don't know enough about it
How many levels of undo?
Not sure exactly, but I've never hit it before
Recordable history?
Like macros? No, but it does have _very_ good scripting support. Check out http://www.cooltext.com/ to see what can be done with a little scripting.
http://manual.gimp.org/
Actually, they can only use their own contributions for that. They cannot use the contributions of other Linux people for their own projects, even if they do that before a "release"
by "supporting linux", we're not talking about porting proprietary programs, we're talking about extending linux itself - which they have done quite well.
Postfix - the greatest mailer ever - checkout postfix.org
Port to S390 - again a great accomplishment
Jikes compiler - great stuff
JFS - this will be killer when its done
Releasing open hardware boards for LinuxPPC
Modifying the kernel so it can run heavily multithreaded apps better
There's probably a million things I haven't thought of, too.
These things are great for _every_ distribution. Everyone has benefitted from IBM's help, even if their proprietary stuff only runs on RPM-based distros.
FreeBSD is great. However, there are several problems with it.
For example, if you're IBM, you're thinking "if we put all our stuff under the BSD License, MS can just hijack it" which is definitely not what they want. With the GPL, they have a layer of protection against that.
Another thing is that speed isn't everything. FreeBSD is great for things that must be fast, but that's not everything. There's system management, functionality (like proxies/firewalls/etc), and the rest. Linux actually has better support for advanced features (process migration, checkpointing, a few extra networking protocols). For the basics, FreeBSD does it faster. However, Linux has more functionality. In addition, there is the number of support channels available.
Another thing to remember, is that all of the BSDs are distributions. Therefore, if IBM wants to expand it, they have to do so along the road of the full distribution. That limits what they can do. With Linux, they can still call themselves "Linux" and have their own distribution, or allow people to choose from several.
There are good reasons to go with the BSDs, but also remember there are good reasons to go with Linux. Apple chose FreeBSD, IBM chose Linux. I think in the end Linux will win out, though, because the license gives a better amount of protection to corporations. People say that RMS isn't corporate-friendly, but his license actually caters better to corporations than others in many respects. Why would a corporation give code under a BSD license, when their competitor can take it and "embrace/extend" it?
I think one of the best things that RMS can do is to make sure that the GPL and the IBM public license work together. I don't think RMS should give as far as ideals go, but they should probably meet and work out the license differences, so that IBM Public License contributions are fully integrateable with everything else.
It can _easily_ be configured to provide a serial console. It requires changing about 3 lines in config files and running lilo. Most Sparc distributions allow you to install and run direct from a serial console by simply typing
boot fd(0,0,0) linux serial
at the firmware prompt.
You don't want it working exactly like Word, that would destroy the whole idea. Having a nice GUI is fine, great in fact. However, it should work semantically. And, no, the people typing don't have to worry about DTD restrictions and XSL - that's handled by the application. Look on freshmeat for Morphon to see a good XML application for end-users.
It actually has nothing to do with mentioning preference. There is quite a bit of difference between saying "I like KDE better than GNOME because..." and "Those GNOME people really suck at this". In addition, if you had read the other responses, you would know that, actually, GNOME did this first, so its a moot point anyway. KDE and GNOME are both great. I generally like the way GNOME works better, but I think the KDE people have done a wonderful job. I also appreciate TrollTech doing the right thing and putting QT under a free license. That was absolutely wonderful. Great things have come out of both camps - each of the office systems have their strengths and weaknesses. However, trashing one or the other does no good whatsoever.
An in-process component is one that is implemented simply by loading a library. An out-of-process component is one that runs in its own process. With in-process components, everything shares the same address space, and method calls are made directly. With out-of-process components, the components are in a different address space/process than their containers, and thus must communicate using pipes/sockets/something other than a direct method call. They have some added benefits, like not having to use the same toolkit as the parent component. As was mentioned in the article, glib and KDE both have their own event loops, which vary quite drastically. Trying to fit them in together in the same process space is quite difficult. However, if they can each run on their own, you have fewer problems with that. However, it adds complexity to the communication between parent and components.
I was actually replying to a previous post, which essentially said that the GNOME people were losers for not doing this first. I was just bringing up the point that they did do it first. I'm sorry if my tone sounded negative, it was only meant to be negative to the person who made the first post, not to either team.
Just so you'll know, after looking over the white paper a little bit, it ends up that this is actually KDE playing catch-up to GNOME. X-Parts does not allow embedding of arbitrary GNOME component into KDE. It only allows embedding of out-of-process components into KDE, which GNOME has had for a long time. GNOME's embedding also does not require any specific toolkit (see OpenOffice as an example). No, Konquerer did not have to be modified to do this, but Mozilla _did_. This support has been in GNOME for some time.
Remember, this does not allow the arbitrary embedding of any GNOME component. It requires a wrapper for each GNOME component before being embedded. This is currently available for GNOME.
I'm not trying to discount what they've done - its very, very great! But I don't want people misunderstanding it either. I'm looking forward to the day when arbitrary components from either can be embedded. Whoever does it first will simply give the other person something to build from. Let's stop fighting, calling names, whatever. It's a great day, and let's be happy.
This is great news for Linux desktops. The KDE people did a wonderful job here. However, I don't see how you can possibly say "KDE is cooperating and GNOME is doing nothing". That's just being a troll. The wars are over. Put your guns down. Now there's just friendly competition. They worked together to make a Window Manager spec, and I'm sure eventually someone will make a bonobo interface for embedding KDE components. But please, don't tarnish this great moment by turning it into a flamefest.
Use processes instead of threads in as many places as make sense. This makes many of your problems simply vanish. It makes you rethink your design in a much more thorough and thoughtful fashion, choosing distinct parts with obvious interfaces.
The argument is about what he _should_ be allowed to do, not what the law currently allows him to do. You haven't responded to that part, only to the question of legality of the maneuvers.
The idea is "Don't bite the hand that feeds you". Because Apple is gaining so much from OSS, it seems strange that they would sue over a few icons. It's like me giving you a house but you taking me to court for stealing $100 from you. It's your legal right, but it sure is stupid.
after starting X, do
ps eafx
look for PIDs with the names "panel", "X", and "sawfish"
then, su to root, and for each PID, do
renice -20 PID
replacing PID with the process's actual PID.
Actually, the whole point of the HURD is so that the application developers _can_ do gee whiz stuff. Like implementing filesystems. The HURD allows code NOT PREVIOUSLY POSSIBLE WITH OTHER KERNELS.
Actually, this is probably more due to the priority you are giving your X server. I reniced my X server, window manager, and panel to -20 and got _really_ nice results.