I could do it. It's a tiny, tiny patch. But it's not worth the trouble. It creates more potential problems then it solves. Which is why they refuse to do it. Consider this situation: you are having the client save/enter your password for you, and then you forget it, and try to get it back from accounts.xml, only to find out it's XOR-encrypted with some stupid string. So you have to go download the source code and find it to crack your own stupid password, because you want to change it and stop having it get entered automatically, because it isn't secure stored on a memory key anyway! Unless you use TrueCrypt, but then it wouldn't matter if it was encrypted or not to begin with.
ATI cards are really hard to support properly with anything besides Windows in general. Unless you're talking about an R100 or R200, then you might be in good shape.
I'm going to post this because I think it's going to be helpful. Fedora is my favorite distro, even though it's frustrating.
The main reason why it's frustrating is because Fedora doesn't bother to update their release images once they hit "gold", which is when the distro gets into real testing, and then the bugs start showing up. They're already moving towards the next release.
But I love how many choices of repositories I get for prepackaged goodies for Fedora (Livna, RPMForge, FreshRPMS, PlanetCCRMA, etc.) so I stick with it.
Here's how I do installs, and it's always worked successfully for me:
1) Download the CD1 and CD2 isos for the release you're interested in. Don't bother with the latest and greatest, just the one that's the oldest yet has all the features you need (SELinux, Xorg, whatever)
2) Plan ahead and visit a few of the repositories you want to incorporate into your installation (Livna, RPMForge, Extras, etc.). Download any "setup" RPMs, GPG keys, or yum conf.d entries and put them onto a USB memory stick or something.
3) Do a rescue boot. Make sure your network card and disk drivers are being detected. Now go ahead and partition your disk, and maybe set up LVM or whatever. I find it easier to do this using the command line tools than with Disk Druid... I mean it's alright but the point and click interface is slow when I know what I want.
4) Reboot, and do an install. BUT! Don't bother selecting packages. Just go for a "Minimal" configuration.
5) Boot up from the new installation. You'll notice Firstboot doesn't run, etc. etc. Do a yum update kernel. Then do a yum upgrade. At this point you'll have all the latest packages for your base system, which (in my experience) is many times more stable than the gold image. You'll also jump a few kernel revisions, and get better hardware support right off the bat. This process shouldn't take too long, since you did a minimal install. Reboot!
6) Make sure you boot the new kernel at next boot. Remove the old kernel. Now stick in that memory stick and setup your new repositories.
7) yum install gdm redhat-artwork (you really want to do this first)
8) For gnome: yum install nautilus gedit gnome-panel gnome-session
For KDE: yum install kdebase kdeutils
9) yum install "my application 1" "my application 2" "my application 3"
Steps 7, 8 and 9 will take care of pulling in a lot of dependancies you would expect for an interactive desktop. 7 should get you your GUI (since gdm depends on Xorg and such). 8 gets you a desktop environment. And 9 gets you the applications you want.
If you want to make sure you can compile code, try this one:
10) yum install gcc-c++ gcc make binutils glibc-devel libstdc++-devel
That should get you everything you need to (configure, make, make-install), minus any -devel packages that something is expecting to find.
While some people may disagree with this method of doing installations, I find that it helps me keep the installed images lean, and so it takes less time to do a full system update by just issueing a "yum -y update" every month or so. It takes forever to do that if you do a full system install with the DVD ISO or whatever.
But it happens more often in a small shop when there isn't much formal change control, dev/testing/production servers in multiple roles, etc.
CTO: Hey Rei, what's the load average of that database server? Rei: (with caution) 50% CTO: That's a pretty powerful box compared to that test server we aren't using, right? Rei: Well yeah, that old box is two years -- CTO: Well I want you to put a few dozen ClearCase volumes on there because its really slow for our developers at site B. Rei: But, uh... a few dozen... I see. (sad face)
these big shops are using a SAN with volumes being forwarded into the instance so Oracle can use ASM on them? Otherwise you get that double-caching silliness (disk cache of host + Oracle's block cache).
Also, until recently, I haven't been aware of any decent N-way virtualization implementations... ESX has only recently gotten support for it, and Xen is just breaking onto the scene what with Pacifica and Vandermode.
Unless you go for a cluster configuration. But I understand that's expensive.
It's a good fit for small businesses, but it certainly doesn't help Oracle any in their effort. Because virtualization frees you from having to stick with any vendor.
... there might be lists of certain safe substitutions, and in certain cases, restricted combinations (kind of like the drug interaction stuff at your pharmacy that the computers work out for you).
And most of the time it'd be up to the recipe author to create alternatives for certain portions of the dish (or the whole dish itself). You might have a "mainline" path through the recipe, and a few choice-driven internal detours that give you some control over the end result.
In any case, it might be instead required to have metadata that relates recipes to each other, so a vegetarian substitute for some dish could be linked through the "vegetarian option" attribute if the recipe can't easily be modified (or contains no internal rules to that effect).
Unless you mean the trend for virtualization is one thing NOT in Oracle's favor in terms of marketing an appliance. Maybe if the Oracle appliance itself supported virtualized hosts sharing the remainder of its capacity. That might be interesting...
Atmosphere: Agreed. It's quite silly. Although what _would_ be cool is a service that lets you "subscribe" your desktop to a website where nice wallpapers are downloaded automatically and rotated through for you (changing ever so gradually, or while the screensaver is up). You could subscribe to different channels relevant to your interests. (Puppies, Women of the UN Security Council, Starscapes, Unobtrusive floral patterns, etc.) One of them could be: TA DA -- TORNADOS OF THE MIDWEST. Almost the same thing... you get the idea.
Blossom: No. Just, no.
Whistler: Interesting. But I challenge the idea that this is a stand alone app. It's more appropriate for a plugin to Cakewalk, Rosegarden, or GarageBand. In that instead of laying down a track via MIDI keyboard and/or dub, you use the "Whistler" inport which brings up the special software to interpret your dulcet eminations into one or more melody tracks and optionally a percussion track. Then, you can use the tool itself to do retakes, cut and paste, move stuff around, and you don't have to fuss with file formats. Whistler would be re-inventing the wheel on all those professional music making interfaces for doing multiple takes, queuing up, monitoring, etc. especially when you're going to flip into them anyway to slurp in the material.
Cookbook: Out of all of these, this one has potential. BUT, it needs the following features: * A standardized recipe format in XML with Schema so everyone can exchange recipes, freely. * Standardized ingredient encondings with substitutions and attributions (for diabetics, kosher preperation, increasing/decreasing spiciness, etc.). In this fashion, you could, say, do a search for all Hallal recipes in your index, or have it present a vegetarian alternative to a dish (substituting quantity WXY of XYZ for 3 eggs, let's say). * Tutorials for various cooking techniques (how to seperate an egg, for example). * Step by step playback mode for walking through a recipe, with timers you can set and monitor (for stuff like baking time). And if you're supposed to do something else while it's baking, it would guide you along through that too (and interrupt you when it thought baking was down).
Portal: Ho hum. A GUI on top of rsync. Forget it, not worth it.
What would be cool is a publish/subscribe-model global file system using BitTorrent to syncronize "volumes". A GUI would provide the interface to add volumes to the subscribe list, authorize users to make changes, etc, show sync percentages. And the volumes themselves would present as normal mounted volumes that you simply read and write to.
But no flash portals and shit. What the hell does that do for anybody?
We've been down this path before. Oracle tried to put together an appliance solution for running 8i, but it never got off the ground. At the time, it was rumored that they were looking at Linux, BSD, and Solaris for the underlying OS.
There was significant pushback from hardware vendors and users for this sort of integration. From users because it was felt that Oracle would abandon the idea of a database that ran on whatever platforms it could, reducing choice in IT departments. From hardware vendors because it meant that only one provider would benefit, and everyone else was afraid that they'd lose the ability to sell Oracle certified configurations.
And Oracle had a hard time finding an easy platform to deploy it on. At the time, Linux and BSD were not as capable for scaling as they are now. And working with Sun would make integrating Solaris expensive.
Now conditions have changed. Solaris is open and modular. BSD and Linux scale more easily, and on more mature N-way platforms. So it might be a good time to revisit the issue.
However, one has to question the value of an Oracle appliance. Because while large companies are happy to dedicate machines to single tasks, smaller firms are more likely to want to have machines serving multiple roles, which may not come easily to an Oracle appliance (or may cost more if it is required to use Oracle-stack implementations of whatever the need is for). Yet larger companies have budgets to test, configure, and roll out their own database servers anyway. And Oracle is looking at the small to medium sized IT market.
So I don't know if this is going to get much traction. They're going to, at least, have to create a generic server appliance that maybe comes tuned for Oracle, yet can be used for anything. That might be a winner.
Why are we talking about giving GIMP to an art department? GIMP wasn't designed to waltz in and make everyone stop using Corel or Photoshop, abandon all ye KPT filters and so forth.
It's a productivity tool for people who don't already have a set of favorite tools and expectations, or for power users and developers.
Besides, Photoshop users whine about everything. Have you seen a PS forum? (shudder) Even if GIMP did change the UI to be more consistent with every other piece of crap out there, they'd still bitch about it and development would stall under the weight of a thousands lamentations.
Adoption doesn't really _drive_ GIMP or anything. It needs to cater to its own users needs. Dropping the powerful MDI interface for an "intuitive" SDI interface is not a step in the right direction.
Calling SDI intuitive is subjective. However, I do know that the MDI model makes me more productive, mainly by reducing the amount of mouse movement I need to do, and increased flexibility in how I arrange my tools and windows in a multimonitor environment.
This is why I bitch about it. People say, "but but it's not like everything else and my mom got confused when she tried to use it" and I say: "well, then they can go buy PS Elements, leave my tool alone".
How can you call MDI a shortcoming? GTK lends itself easily to SDI applications. Most GTK apps are SDI, or tabbed. Yet GIMP (and inkscape) CHOOSE to be MDI. There are reasons. I listed them. Changing it would raise many a user's ire.
Fuck windows and it's shitty windowing system. Who needs them?
what's not scary is the monsters. It's the lighting and atmospherics. On a decent system with headphones, you can get very disoriented and twitchy.
You hear clanking and you don't know if it was a wrench you accidentally knocked off a ledge, a door closing, or a Commando kneeling down to chaingun you from a catwalk above.
And at first monster spawns were kinda scary, but once you got used to where you think they should be, it became routine. And I think that might have been intentional.
You'll notice later on they don't bother to teleport in most enemies anymore, they're either silent-spawned after a trigger, walking a beat, or just hiding somewhere before getting aggro'd. They save the spawn for locations where it's difficult to set up the "intended" firefight otherwise.
The flash "virtual machine" is a ecmascript implementation. And spidermonkey works just fine on 64-bit so I'm not sure what their problem is.
Oh, maybe the rest of their codebase isn't 64-bit clean, like the rendering code.
Well big fucking surprise. Welcome to 21st century, Adobe. Now why don't you update your compositing routines to use more modern instruction sets (this goes for Photoshop et al. as well). Thanks.
802.11b is _hard_. You need a platform to drive it. And what if you want to use encryption, how do you interface that into the device easily? So it needs an embedded OS with a web server.
Good job, genius. You saved -100$ of hardware for a $5 CCD.
UWB is a simple radio protocol that to the device looks like a USB UART (which means integrators could basically plug'n'play in their designs). Like bluetooth, you'll be able to get a chip with the majority of the implementation on it, minus an power/antenna stage.
No, it wouldn't. Because you're going to rate limit it.:-)
But the real way to do this effectively is through UDP multicast, but few people are comfortable enough with that to create cool hacks with it unless it involves streaming media, which is a shame for us sysadmins who are stuck with unicast methods.
Apple's products are made (and to some degree, designed) in China just like everybody else's. I wonder how many other memory products (that is, USB mass storage devices) have similar issues.
I remember playing that with a friend back when it came out. We were both self-proclaimed fast typers so we would go at it hardcore. I think we were partly motivated by the amount of coin we dropped in House of the Dead units... were we enacting some kind of revenge? The dreamcast keyboards were the clear losers, however.
It's going to be SDI or MDI. There's no point mixing the too (it gets confusing, look at Excel). I like it MDI. If you want SDI, use a different tool. Try Krita. It's not like making a change YOU WANT has no effect on other people.
The file dialog is stock. You want Gnome to fix the file dialog. Fine. A lot of people want that. MDI vs. SDI... deal with it. SDI can work if you make it work. Try playing with your palettes a little. I also recommend picking up a second monitor (you can get them for next to nothing on ebay). It makes it much easier to work with and you'll see why SDI can be better than MDI depending on the task.
Slashdot Mirror
I could do it. It's a tiny, tiny patch.
But it's not worth the trouble. It creates more potential problems then it solves. Which is why they refuse to do it.
Consider this situation: you are having the client save/enter your password for you, and then you forget it, and try to get it back from accounts.xml, only to find out it's XOR-encrypted with some stupid string. So you have to go download the source code and find it to crack your own stupid password, because you want to change it and stop having it get entered automatically, because it isn't secure stored on a memory key anyway!
Unless you use TrueCrypt, but then it wouldn't matter if it was encrypted or not to begin with.
ATI cards are really hard to support properly with anything besides Windows in general.
Unless you're talking about an R100 or R200, then you might be in good shape.
If you want a distro that just installs everything in one shot, without much prompting, then by all means, use Ubuntu. Or Mandriva.
Fedora is more for someone who already has an idea of what they want. Or at least an idea of the names of software that does what they want to do.
All:
I'm going to post this because I think it's going to be helpful.
Fedora is my favorite distro, even though it's frustrating.
The main reason why it's frustrating is because Fedora doesn't bother to update their release images once they hit "gold", which is when the distro gets into real testing, and then the bugs start showing up. They're already moving towards the next release.
But I love how many choices of repositories I get for prepackaged goodies for Fedora (Livna, RPMForge, FreshRPMS, PlanetCCRMA, etc.) so I stick with it.
Here's how I do installs, and it's always worked successfully for me:
1) Download the CD1 and CD2 isos for the release you're interested in. Don't bother with the latest and greatest, just the one that's the oldest yet has all the features you need (SELinux, Xorg, whatever)
2) Plan ahead and visit a few of the repositories you want to incorporate into your installation (Livna, RPMForge, Extras, etc.). Download any "setup" RPMs, GPG keys, or yum conf.d entries and put them onto a USB memory stick or something.
3) Do a rescue boot. Make sure your network card and disk drivers are being detected. Now go ahead and partition your disk, and maybe set up LVM or whatever. I find it easier to do this using the command line tools than with Disk Druid... I mean it's alright but the point and click interface is slow when I know what I want.
4) Reboot, and do an install. BUT! Don't bother selecting packages. Just go for a "Minimal" configuration.
5) Boot up from the new installation. You'll notice Firstboot doesn't run, etc. etc. Do a yum update kernel. Then do a yum upgrade. At this point you'll have all the latest packages for your base system, which (in my experience) is many times more stable than the gold image. You'll also jump a few kernel revisions, and get better hardware support right off the bat. This process shouldn't take too long, since you did a minimal install.
Reboot!
6) Make sure you boot the new kernel at next boot. Remove the old kernel. Now stick in that memory stick and setup your new repositories.
7) yum install gdm redhat-artwork (you really want to do this first)
8) For gnome: yum install nautilus gedit gnome-panel gnome-session
For KDE: yum install kdebase kdeutils
9) yum install "my application 1" "my application 2" "my application 3"
Steps 7, 8 and 9 will take care of pulling in a lot of dependancies you would expect for an interactive desktop. 7 should get you your GUI (since gdm depends on Xorg and such). 8 gets you a desktop environment. And 9 gets you the applications you want.
If you want to make sure you can compile code, try this one:
10) yum install gcc-c++ gcc make binutils glibc-devel libstdc++-devel
That should get you everything you need to (configure, make, make-install), minus any -devel packages that something is expecting to find.
While some people may disagree with this method of doing installations, I find that it helps me keep the installed images lean, and so it takes less time to do a full system update by just issueing a "yum -y update" every month or so. It takes forever to do that if you do a full system install with the DVD ISO or whatever.
But it happens more often in a small shop when there isn't much formal change control, dev/testing/production servers in multiple roles, etc.
CTO: Hey Rei, what's the load average of that database server?
Rei: (with caution) 50%
CTO: That's a pretty powerful box compared to that test server we aren't using, right?
Rei: Well yeah, that old box is two years --
CTO: Well I want you to put a few dozen ClearCase volumes on there because its really slow for our developers at site B.
Rei: But, uh... a few dozen... I see. (sad face)
these big shops are using a SAN with volumes being forwarded into the instance so Oracle can use ASM on them? Otherwise you get that double-caching silliness (disk cache of host + Oracle's block cache).
Also, until recently, I haven't been aware of any decent N-way virtualization implementations... ESX has only recently gotten support for it, and Xen is just breaking onto the scene what with Pacifica and Vandermode.
Unless you go for a cluster configuration. But I understand that's expensive.
It's a good fit for small businesses, but it certainly doesn't help Oracle any in their effort. Because virtualization frees you from having to stick with any vendor.
... there might be lists of certain safe substitutions, and in certain cases, restricted combinations (kind of like the drug interaction stuff at your pharmacy that the computers work out for you).
And most of the time it'd be up to the recipe author to create alternatives for certain portions of the dish (or the whole dish itself). You might have a "mainline" path through the recipe, and a few choice-driven internal detours that give you some control over the end result.
In any case, it might be instead required to have metadata that relates recipes to each other, so a vegetarian substitute for some dish could be linked through the "vegetarian option" attribute if the recipe can't easily be modified (or contains no internal rules to that effect).
Unless you mean the trend for virtualization is one thing NOT in Oracle's favor in terms of marketing an appliance.
Maybe if the Oracle appliance itself supported virtualized hosts sharing the remainder of its capacity. That might be interesting...
Atmosphere:
Agreed. It's quite silly. Although what _would_ be cool is a service that lets you "subscribe" your desktop to a website where nice wallpapers are downloaded automatically and rotated through for you (changing ever so gradually, or while the screensaver is up). You could subscribe to different channels relevant to your interests. (Puppies, Women of the UN Security Council, Starscapes, Unobtrusive floral patterns, etc.) One of them could be: TA DA -- TORNADOS OF THE MIDWEST. Almost the same thing... you get the idea.
Blossom: No. Just, no.
Whistler: Interesting. But I challenge the idea that this is a stand alone app. It's more appropriate for a plugin to Cakewalk, Rosegarden, or GarageBand. In that instead of laying down a track via MIDI keyboard and/or dub, you use the "Whistler" inport which brings up the special software to interpret your dulcet eminations into one or more melody tracks and optionally a percussion track.
Then, you can use the tool itself to do retakes, cut and paste, move stuff around, and you don't have to fuss with file formats.
Whistler would be re-inventing the wheel on all those professional music making interfaces for doing multiple takes, queuing up, monitoring, etc. especially when you're going to flip into them anyway to slurp in the material.
Cookbook: Out of all of these, this one has potential. BUT, it needs the following features:
* A standardized recipe format in XML with Schema so everyone can exchange recipes, freely.
* Standardized ingredient encondings with substitutions and attributions (for diabetics, kosher preperation, increasing/decreasing spiciness, etc.). In this fashion, you could, say, do a search for all Hallal recipes in your index, or have it present a vegetarian alternative to a dish (substituting quantity WXY of XYZ for 3 eggs, let's say).
* Tutorials for various cooking techniques (how to seperate an egg, for example).
* Step by step playback mode for walking through a recipe, with timers you can set and monitor (for stuff like baking time). And if you're supposed to do something else while it's baking, it would guide you along through that too (and interrupt you when it thought baking was down).
Portal: Ho hum. A GUI on top of rsync. Forget it, not worth it.
What would be cool is a publish/subscribe-model global file system using BitTorrent to syncronize "volumes". A GUI would provide the interface to add volumes to the subscribe list, authorize users to make changes, etc, show sync percentages. And the volumes themselves would present as normal mounted volumes that you simply read and write to.
But no flash portals and shit. What the hell does that do for anybody?
We've been down this path before. Oracle tried to put together an appliance solution for running 8i, but it never got off the ground. At the time, it was rumored that they were looking at Linux, BSD, and Solaris for the underlying OS.
There was significant pushback from hardware vendors and users for this sort of integration. From users because it was felt that Oracle would abandon the idea of a database that ran on whatever platforms it could, reducing choice in IT departments. From hardware vendors because it meant that only one provider would benefit, and everyone else was afraid that they'd lose the ability to sell Oracle certified configurations.
And Oracle had a hard time finding an easy platform to deploy it on. At the time, Linux and BSD were not as capable for scaling as they are now. And working with Sun would make integrating Solaris expensive.
Now conditions have changed. Solaris is open and modular. BSD and Linux scale more easily, and on more mature N-way platforms. So it might be a good time to revisit the issue.
However, one has to question the value of an Oracle appliance. Because while large companies are happy to dedicate machines to single tasks, smaller firms are more likely to want to have machines serving multiple roles, which may not come easily to an Oracle appliance (or may cost more if it is required to use Oracle-stack implementations of whatever the need is for).
Yet larger companies have budgets to test, configure, and roll out their own database servers anyway. And Oracle is looking at the small to medium sized IT market.
So I don't know if this is going to get much traction. They're going to, at least, have to create a generic server appliance that maybe comes tuned for Oracle, yet can be used for anything.
That might be a winner.
Why are we talking about giving GIMP to an art department?
GIMP wasn't designed to waltz in and make everyone stop using Corel or Photoshop, abandon all ye KPT filters and so forth.
It's a productivity tool for people who don't already have a set of favorite tools and expectations, or for power users and developers.
Besides, Photoshop users whine about everything. Have you seen a PS forum? (shudder) Even if GIMP did change the UI to be more consistent with every other piece of crap out there, they'd still bitch about it and development would stall under the weight of a thousands lamentations.
Adoption doesn't really _drive_ GIMP or anything. It needs to cater to its own users needs. Dropping the powerful MDI interface for an "intuitive" SDI interface is not a step in the right direction.
Calling SDI intuitive is subjective. However, I do know that the MDI model makes me more productive, mainly by reducing the amount of mouse movement I need to do, and increased flexibility in how I arrange my tools and windows in a multimonitor environment.
This is why I bitch about it. People say, "but but it's not like everything else and my mom got confused when she tried to use it" and I say: "well, then they can go buy PS Elements, leave my tool alone".
How can you call MDI a shortcoming? GTK lends itself easily to SDI applications. Most GTK apps are SDI, or tabbed. Yet GIMP (and inkscape) CHOOSE to be MDI. There are reasons. I listed them. Changing it would raise many a user's ire.
Fuck windows and it's shitty windowing system. Who needs them?
We still love you.
That just means it's only invisible from one direction/orientation (it's a shield, not a cloak).
what's not scary is the monsters. It's the lighting and atmospherics. On a decent system with headphones, you can get very disoriented and twitchy.
You hear clanking and you don't know if it was a wrench you accidentally knocked off a ledge, a door closing, or a Commando kneeling down to chaingun you from a catwalk above.
And at first monster spawns were kinda scary, but once you got used to where you think they should be, it became routine. And I think that might have been intentional.
You'll notice later on they don't bother to teleport in most enemies anymore, they're either silent-spawned after a trigger, walking a beat, or just hiding somewhere before getting aggro'd.
They save the spawn for locations where it's difficult to set up the "intended" firefight otherwise.
it's Sum(32 .. 63, 2^n).
The flash "virtual machine" is a ecmascript implementation. And spidermonkey works just fine on 64-bit so I'm not sure what their problem is.
Oh, maybe the rest of their codebase isn't 64-bit clean, like the rendering code.
Well big fucking surprise. Welcome to 21st century, Adobe. Now why don't you update your compositing routines to use more modern instruction sets (this goes for Photoshop et al. as well). Thanks.
nt
anonymous thinks too highly of himself.
802.11b is _hard_. You need a platform to drive it. And what if you want to use encryption, how do you interface that into the device easily? So it needs an embedded OS with a web server.
Good job, genius. You saved -100$ of hardware for a $5 CCD.
UWB is a simple radio protocol that to the device looks like a USB UART (which means integrators could basically plug'n'play in their designs). Like bluetooth, you'll be able to get a chip with the majority of the implementation on it, minus an power/antenna stage.
No, it wouldn't. Because you're going to rate limit it. :-)
But the real way to do this effectively is through UDP multicast, but few people are comfortable enough with that to create cool hacks with it unless it involves streaming media, which is a shame for us sysadmins who are stuck with unicast methods.
Apple's products are made (and to some degree, designed) in China just like everybody else's. I wonder how many other memory products (that is, USB mass storage devices) have similar issues.
I remember playing that with a friend back when it came out. We were both self-proclaimed fast typers so we would go at it hardcore. I think we were partly motivated by the amount of coin we dropped in House of the Dead units... were we enacting some kind of revenge? The dreamcast keyboards were the clear losers, however.
It's going to be SDI or MDI. There's no point mixing the too (it gets confusing, look at Excel).
I like it MDI. If you want SDI, use a different tool. Try Krita.
It's not like making a change YOU WANT has no effect on other people.
I wanted to make it seem like I had a more important criticism to make to seem more credible!
Now my reputation is in tatters. *tear*
The file dialog is stock. You want Gnome to fix the file dialog. Fine. A lot of people want that.
MDI vs. SDI... deal with it. SDI can work if you make it work. Try playing with your palettes a little.
I also recommend picking up a second monitor (you can get them for next to nothing on ebay). It makes it
much easier to work with and you'll see why SDI can be better than MDI depending on the task.