"Earlier this week Everex launched the gPC TC2502, which is a sub-USD 200 PC sold at a major US retailer, but what makes this unique is that it runs the gOS. The gOS (GreenOS) is designed to be a conceptual Google Operating System that is based upon Ubuntu 7.10 Gutsy Gibbon. Though this is not the conventional GNOME desktop environment but an Enlightenment E17 desktop is used that is heavily modified and reflects a green Google theme. The gOS provides easy access to Google services such as YouTube, Google Product Search, Google Calendar, and Google Maps. Also a click away are other web services such as Wikipedia and Facebook. This isn't a pure Internet desktop but Xine, Skype, OpenOffice.org, and other applications are available for this Linux LiveCD. We've been trying the gOS out for a while and it's a rather nice slim desktop Linux distribution that would be perfect for Internet cafes and other public places." More screenshots.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
I do understand what he's talking about. It's bunk. It's the typical user perspective of programming I always get.
If you don't have an architecture that makes it straightforward enough to add new features, you simply aren't going anywhere sweetheart.
In fact if you go crazy creating too many layers, you wind up with a problem worse than if you had too few.
Errr, yer, and? That's not the point being made here. Coupling and cohesion. Go and look it up.
...writing a new frontend will _not_ be trivial.
So what? If you haven't separated the back-end from the front-end, enough then dealing with the front-end will be that much more difficult because the back-end is in there somewhere.
In fact, the GUI code tends to be the most bloated and complex.
It might be for you, but it isn't for other people. The reason why is because all the hard work goes into the logic which makes developing your front-end that much easier. It makes it that much easier to change as well.
The reason the GIMP doesn't have the high color space options is that the image processing code wasn't written with that in mind.
Errr, yer. They didn't think of this and didn't plan ahead.
The code still has to be rewritten regardless of where the layer boundaries are.
Errr, no. Given some thought into your architecture most things don't have to be completely rewritten. That's always a bad idea.
Key assumptions made early on are the problem. Modularity isn't going to save you from this.
Key assumptions made early on in one monolithic piece of software will cause you problems. Everyone else will merely replace the individual components in their system or modify them slightly in a sane manner.
Apple's Logic isn't even a relevant example. You're talking about image processing in GIMP (which would be your precious backend) and then comparing it to replacing the UI which is an entirely orthogonal issue.
You missed the last twenty years of computing and the lessons learned by people like Netscape - reuse code as much as possible and rewriting things will make you bankrupt.
If Logic's backend could only sample audio with 4bit resolution at 10Hz, you'd have to rewrite that too.
That's why you don't hard-code stuff ;-).
Frankly all this is moot because all the crap people keep complaining about is supported in the GEGL libraries...
So they are going trying to modularise the whole thing then? Hint: Modularity is important, but what's important in making it work is the thought that has gone into what you separate. The proper place for much of GEGL is in a underlying programming toolkit used by other people ;-).
The hard part was writing GEGL. Integrating into the GIMP will be the easy part.
Errr, yer?
Any other application can use GEGL.
Not quite, no, because it's one monolithic library with base functionality that is replicate elsewhere.
That is what we're talking about right? The mythical average Joe user? Average Joe doesn't need Photoshop.
The 'Average Joe' comment is the sort of bunk I always get, especially when it comes to Photoshop and the GIMP. Krita has had CMYK support for ages, and it has had it and other features precisely because the developers have paid attention to their development tools and architecture. Most things have been reused from a base toolkit and layers within the system - which can be used by a multitude of other applications and the desktop itself so they don't have to rewrite it ;-).
I recommend a good systems and analysis book, as well as a programming one, before you get another interview - if indeed you ever do.
Edited 2007-11-05 23:41
Member since:2005-07-06
First, I'm not your sweetheart mister.
You seem to be mistaking my refutation that the GIMP isn't poorly designed and is indeed modular as some some admission that I think modular design is bad. Reading comprehension 101 please.
You've obviously never looked at GEGL because it's not a single monolithic library. Just a quick scan of the Makefile.am will tell you that. Even if it was, it would make absolutely no difference. Whether I call f() from liba or libb is immaterial and has nothing to do with modularity. All that affects is memory overhead and the number of flags you have to pass to the linker.
Really, this all has f--k to do with why GIMP doesn't have these features? The real reason is that nobody that wants them is willing to implement them. They just show up on the mailing-lists can IRC channels whining/demanding them. This is a volunteer project people. If you want it, get busy or pay someone else to.
Stop proclaiming yourself an expert on a code base to which you've _never_ even taken a passing glance. Of course, being an VB "programmer", C might be a little over your head.
Member since:
2005-07-06
I do understand what he's talking about. It's bunk. It's the typical user perspective of programming I always get. The idea that just by being modular (which doesn't really mean anything specifically) it will magically solve all programming problems. It doesn't. In fact if you go crazy creating too many layers, you wind up with a problem worse than if you had too few.
I don't care how well you separate the backend from frontend (even if the backend is a bunch of servers that communicate with the the frontend with IPC mechanisms) writing a new frontend will _not_ be trivial. At best it will be easier. In fact, the GUI code tends to be the most bloated and complex.
The reason the GIMP doesn't have the high color space options is that the image processing code wasn't written with that in mind. The code still has to be rewritten regardless of where the layer boundaries are. It doesn't happen by magic. Key assumptions made early on are the problem. Modularity isn't going to save you from this. Corollary: plan on throwing out the first prototype, because you will.
Apple's Logic isn't even a relevant example. You're talking about image processing in GIMP (which would be your precious backend) and then comparing it to replacing the UI which is an entirely orthogonal issue. The UI in the GIMP isn't what prevents those features from being added. If Logic's backend could only sample audio with 4bit resolution at 10Hz, you'd have to rewrite that too. No amount of modularity is going to save you there.
Frankly all this is moot because all the crap people keep complaining about is supported in the GEGL libraries that will replace the composting and processing layers in GIMP for the 2.6 release. The hard part was writing GEGL. Integrating into the GIMP will be the easy part. Any other application can use GEGL. In fact, GEGL has it's own cli interface to it which is more or less a development tool at this point. Of course, there was nothing stopping anyone from using the GIMP as a backend for a different application in the first place.
In almost any common usage scenario (web publishing and other non-print use cases) the GIMP is better than good enough as is. That is what we're talking about right? The mythical average Joe user? Average Joe doesn't need Photoshop.