I like the way Metaboli does it and I wish they would grow internationally. In their model you choose between "Essential" and "Ultimate" collection. Flat monthly fee, download all the games you want (wherever you want) from the collection you are paying for.
Initially I had a slight problem with my ATI card not being able to run with hardware accelerated 3D. But after searching the Ubuntu Forums, I got it working.
I have never had to do a clean install on my machine ever. I have been running Ubuntu since the first release and I have been doing a dist-upgrade to keep up with every major release. The upgrade from Dapper to Edgy was even better as I did it through the Update Manager GUI for the first time and it worked like a charm.
What are the odds that you installed the drivers from ATI and not used the Ubuntu.deb packages for your ATI drivers? I would also guess that you have a wireless card and you did some fiddling around with it to get it to work?
From what I have been reading at the forums, a lot of the upgrade problems seem to come from people who have a very funky setup (e.g., unsupported wireless card, ATI drivers installed from packages downloaded from ATI, "alien" packages). As with any system with a package manager, if you deviate from the standard way of installing and maintaining packages for your system, then expect that you will have problems when upgrading.
Very few people point this out, but the best thing about using apt-src is that after you are done building from source, you can remove the -dev packages from your system and leave only the runtime dependencies.
Compare this with Gentoo which also pull in and build all the packages required to build a package from source. But after it's done building, your system is littered with header files and libtool link libraries that will never be used until you build the package from source again. This is one of my major gripes with Gentoo and is one of the reasons why I stopped using it. It got to the point where about 40% of my/usr filesystem was used by header files and compile time libtool libraries. You might argue that one could simply get a bigger hard disk. But using 40% of that disk for things that you need only once in a while is ridiculous.
Really. It amazes me that anybody believes anything anyone says at all. Unless you have good reason to think someone is telling the truth, you should probably just assume thier lying. This goes for everyone: journalists, marketers, employers, employees, politicians, salesmen, contractors, etcetera, etcetera, etcetera.
Based on your reasoning above, we should all assume everyone is lying about everything. So in effect what you said above is a lie. Because you say that I should not believe what you say, unless I have a good reason to think what you say is true. I don't have a good reason to think that you say the truth. Which means that we should all assume that everyone is not lying. Which will mean that you're not lying about what you said above. But then...
GAH! Forget it! My brain hurts.
With the bazillion GUI toolkits out there..
on
Why Use GTK+?
·
· Score: 1
...none of them seem to offer an easy, consistent, and cross-platform solution to reports printing. I think this area of GUI toolkits is a bit lacking. There are third-party solutions like GNOME-Print, JasperReports (Java), ReportLab (Python), one other toolkit which QT-based, plus two other wxWidgets-specific solutions and yes, there's the expensive and Windows-only Crystal Reports. But they offer either a steep learning curve to use (Jasper) or tend to be a lot more fundamental in the features offered.
It's pretty easy to create a nice GUI program with all of these toolkits. But when it comes to implementing report generation and printing, it's a total nightmare. I know GUI toolkits should stick to GUI-specific objects and functions, but printing (and report generation) should be taken into consideration too.
So far, the only workable solution I have come across is using ReportLab as the report generation backend, with either PyGTK+, PyQT, or wxPython at the GUI frontend.
This is more a new concept than a new technology, and the real version may still be a year or two away.
It would track the mobile phone signals of loved ones, then cross-reference which mobile cell they were in with pre-programmed locations, like the home, school, or workplace.
Additionally, when I was working as systems development lead for an SMS applications company, I developed a program that uses two cell sites to triangulate a phone's position based on relative signal strength. It was dropped out of development because ANTS beat us to it.
If this is Microsoft's vision of the future, I guess it would be safe to say "The future is NOW!".
This is a collision attack. The attacker will be able to find two messages that will produce the same hash, but the attacker cannot choose what the hash will be. So this rules out attacks on hashed passwords.
Since a collision attack can find to messages that will produce the same hash, it is possible to use this to break message signing, such as DSA and RSA. where a hash of the message is generated first and then signed cryptographically.
Collision attacks cannot be used to tamper with existing SSL certificates. It can be used to craft a CSR which will allow you to receive a server certificate with a collision to one containing a wildcard for the domain name and an expiration date far in the future. This by far is one of the most dangerous exploits because most CA's will issue certificates without completely verifying the identity of the requester.
Because of the way MD5 is used in SSL 3.0/TLS, these attacks do not affect it.
Collision attacks do not affect MD5 and SHA-1 when they are used in an HMAC. So even though a hash function can be broken by either by collision attacks, they can still be used safely in HMAC.
Tampering a signed binary is only possible using a preimage attack.
All will have naturally collisions. How exploitable they are depends on how easy it is to find those collisions.
In conclusion, the value of this attack/exploit is only relative to how the hash function is used in an application. Just because this exploit and source code for it exists, that does not that these hashing algorithms are completely useless.
Gaming is fairly big in SK also, somehow I think 'it runs on WINE' isn't going to fly.
A large number of SK (professional) gamers still play old multiplayer games like WarCraft and StarCraft which already run well under Wine or Cedega, so that won't be the problem. Their problem will be with newer MMORPG games like Ragnarok, R.O.S.E. Online and Mu Online. These games have quite a following not only in SK but in other South-east Asian countries as well. This is the reason I still have Windows on on partition. I have been waiting for a native Linux port of these games for a long time but it seems that the developers have neither the resources or the motivation to make the port. AFAIK, these games use SDK's that are Windows-only and their servers depend on MSSQL to run.
However, with MS pulling their off their shit from SK shelves, this should force these game developers to go cross-platform eventually. So, here's to hoping that MS get's the slap-in-the-face ruling and that they do indeed remove their entire product line from SK.
I've used FreeBSD, NetBSD, OS X, Debian and Redhat for servers and/or desktops.
In my opinion, FreeBSD Ports > NetBSD pkgsrc > DarwinPorts > APT > RPM.
And in your opinion, you completely seem to disregard package building. To be fair I don't know if you have ever used those packaging systems to build your own packages. If you have no experience rolling your own packages, then I urge you to try it on all the packaging systems you mentioned.
Package Building
On FreeBSD Ports and Gentoo Portage, you have to figure out and specify runtime dependencies yourself.
??? I don't understand this sentence. Portupgrade handles everything for me just fine.
That's because you took it out of context of building packages. I am refering to the problem of having to specify all of the dependencies in the build script when building packages. And when I say "building packages" I mean to say taking a source tarball and constructing a package from said tarball. This includes the runtime dependencies. Using APT, when you build a package, normally you would only have to worry about build-time dependencies. Upon completion of a build and prior to packaging to a deb file, ${shlibs:Depends} on the Depends line of your debian/control file will automatically figure it out for you. Though you may not see this as a problem under Ports or Portage because in that system, build-time dependencies are most probably also run-time dependencies. But this leads to the "dusty deck" problem I described in my previous post.
The "Dusty Deck" Problem
On my home FreeBSD server, with around 330 ports currently installed, used space in the/usr partition is 3.4 GB. Given how cheaps hard disk space is, I couldn't care less to save a few couple of megabytes just to remove build dependencies.
Well, that is your case. What about those that run the OS on very limited disk space on very old hardware or in an virtualized environment? And I am not talking "a couple of megabytes" here. Case in point: there are some packages that will require LaTeX or Docbook to build documentation. Those packages are huge and they take a long time to compile. After building your package and installing it, you won't need LaTeX or Docbook to run your package. So what do you do? You remove the uneeded packages. But what happens when you upgrade the dependent packages?
Package Uninstallation
I understand this may be true for people playing with their system learning Linux, constantly installing/uninstalling packages (and constantly switching Linux distros), but after a certain while, you get to know which packages you need/want on a server and the question of uninstallation becomes unimportant alotgether. I don't see why I would want to uninstall Apache, Python or Subversion. Upgrade, yes but remove, no.
Providing a clean way of removing your package from the system is an absolute must. Even if you do not care about uninstalling packages. It is important to be able to revert the system back to the original state before a package was installed. Which is why Debian packaging policy has very strict rules regarding packaging, especially with package removal. This is probably why some packages are done badly. Most packagers are in the same mental frame as you and say to themselves "Nah, nobody will want to uninstall this.". Plus, there are some (badly made) packages that will not even upgrade cleanly and still require you to remove cruft from the previous version.
As a Zope webesite developer, I've usually been unable to find the versions I need for a given task (Zope is very picky about versions, and usually "old" versions just won't do) whereas FreeBSD is always up-to-date.
This is the main reason to roll your own packages. If your distro is behind, you sh
Wow! Is that all it takes to get a +5 Insightful now? So I guess this will be modded Troll or Flamebait.
I can never really understand why FreeBSD ports is better than Debian's APT. Perhaps it's only because they look at "package installation" as the only use for these tools, whereas I use these tools for "package management". Everything comes down to the packagers who make and maintain the packages and the quality of the tools used to make and maintain the packages. I've used FreeBSD, Gentoo, and finally Debian for servers and desktops. Based on my experience APT is a more elegant solution to package management compared to FreeBSD Ports and Gentoo Portage for the following reasons:
Package Building
Although building Debian packages can be a bit overwhelming especially for newcomers, it really shines especially if you have installed debhelper, dh-make, dbs, dpatch, and lintian. What's really great about APT is the automatic runtime dependency resolution prior to packaging the final debs. After building the package and before it gets packed into a deb, a dependency checker is run through it and it will automatically figure out the runtime dependencies for you. On FreeBSD Ports and Gentoo Portage, you have to figure out and specify runtime dependencies yourself.
The "Dusty Deck" Problem
When I install a package using ports or emerge, it will also install the dependencies. But most of the time you will essentially be installing from source (and yes I am aware that Ports and Portage also have pre-built packages). When you do that, Ports and Portage will install and build the build-time dependencies of the package you are installing. Now, that's fine if those build-time dependencies are also needed at run-time. But some dependencies are only used at build-time and will never be used again until you upgrade the packages that depend on them. You can decide to remove them after build time, but then when you update the package they will be downloaded, rebuilt, and installed again. You eventually grow tired of this cycle that you just leave these build-time only packages and then they continue to accumulate on your disk mostly wasting space.
This is probably the reason why there are "developer" packages for libraries that contain only the header files and the link libraries. Once you're done with building, you can uninstall the developer package. Try doing that under Ports or Portage. Oh, wait! You can't. The runtime and build-time dependencies are all in one package.
Package Uninstallation
Now this is where Ports and Portage, IMHO, really suck. When I uninstall a package from my system I want it gone. apt-get remove --purgeand a properly packaged deb will do that for you. Ports and Portage will leave "package cruft" on your system. "Package cruft" can be anything from stale config files to build-time dependecy packages. You will have to track and remove those things manually.
I know these three points can be resolved on both Ports and Portage if the packages are done correctly. This is where APT has an advantage over Ports and Portage: being able to make a proper package. On Debian, with the tools I mentioned above installed, a package maintainer's life is greatly simplified.
Ports (and Portage) does Rock, but only if all you ever care about is package installation and not package management (package building, installation and uninstallation).
Oops! Urm... Yeah, Wine. It turns out our developers lied to us and took
shortcuts. But we are using only parts of Wine and "optimizing" those parts to
be able to run Windows apps.
Uhm... Yeah. We're still working on Project "David". Talk to you later...
Err... (shifts gaze left and right) We're stuck with this teeny-tiny problem that Pagemaker still has a few glitches in it. But honest and truly, we have the best programmers in the Philippines working on "David" right now.
Uh... Our programmers left. We'd pay Random J. Hacker $10,000 to develop XP compatible "modules" for Wine. But you only have 15 days to do it.
The VC's who put their money into SpecOpS Labs are probably itching to get
their ROI by now. They probably burned through their capital funding and now
the VC's want some returns, or at least a product that can be marketed. These
guys are desperate now. $10,000 is probably the only money they have left
and the VC's won't give them anything more unless they come up with something.
I always thought these people were just VC fishers.
See also their previous page with buzz-word laden spiels, and outlandish claims.
I live in the Philippines and I got my 10 CDs of Hoary last June 25, which is about one month after they were shipped out from The Netherlands. I ordered them about a week after the official release.
If you login to your shipit account, you can check the status of your order there. If it says your order has been shipped out, then it has. If it didn't make it to you, then it probably got lost en route to your place. It's rare these days, but it still happens.
Yogurt: Merchandising, merchandising, where the real money from the movie is made. Spaceballs-the T-shirt, Spaceballs-the Coloring Book, Spaceballs-the Lunch box, Spaceballs-the Breakfast Cereal, Spaceballs-the Flame Thrower.
[turns it on]
The Dinks: Ooooh!
Yogurt: (reacts to dinks) The kids love this one. (A dink hands him a doll that looks likes Yogurt) And last but not least, Spaceballs the doll, me.
[Pulls string]
When Red Hat started Fedora and then switched its major focus to the enterprise, how many of you stayed loyal to Red Hat, and how many of you went to another distro?
I went to other distros when RHL became FC. For servers, I went to SuSE. For workstations I tried Mandrake, then Conectiva, and finally staying with Ubuntu.
And, of those that left, how many of you are willing to embrace the return of the prodigal son?
I don't see myself returing to FC, just for the sake of using the latest whizbangerry that comes with it (if I wanted that, I would be using Gentoo). I use Linux on production systems and FC is a beta testing project that Redhat has shoved down their users' collective throats. Plus a recent install attempt with FC3 got me burned badly with its broken SELinux configuration that I had to fix it manually by editing the policy files (yah, I know that they later released updates that fixed that, and those updates kept on erasing my policy file fixes).
...the stupid and shameless kind?:) It *is* wine. Look at the screen shots. The wine directory on the filesystem tree, the references to wine files on the lst icons... You'd think they would be smart enough to hide evidence of a rip-off since they were smart enough to change the titles on the wine windows.
These specops guys seem to be just VC phishing. The things they say on their buzzword-laden website reads investment scam all the way.
Only a problem when, as you, you come from 1.x days. Programs written for 2.0 work the same in 2.2, 2.4 and 2.6.
Yup. Matter of fact I am still stuck in 1.x:) But learning how to port my apps to 2.0 is taking me a while because of the API changes and some of the new features that were introduced.
If you want to take advantage of new features, that's another issue.
One thing that seems to have really improved in 2.0 is printing support and my apps require a lot of printing code. But lots of things have changed between 1.x and 2.x when it comes to printing. Add to that the API changes in GTK. You got a ton of docs to wade through just to figure out what will work and what will break between the two versions. Oh well...
...does it still work like in the old one? That's the one feature I really like about the old file selector. Sure the old one may look ugly but it serves its purpose.
Slashdot Mirror
That is easy to deal with, just hand off the spec to a developer outside the USA. The DMCA does not matter anywhere else.
Try telling that to Dmitry Skylarov.
It depends on the license of the software. Always.
It also depends on where you live. In Soviet Russia, software owns you.
Replace him with someone who can create just as much hype for what would be an otherwise mundane party. Someone like David Tuttera.
I like the way Metaboli does it and I wish they would grow internationally. In their model you choose between "Essential" and "Ultimate" collection. Flat monthly fee, download all the games you want (wherever you want) from the collection you are paying for.
Initially I had a slight problem with my ATI card not being able to run with hardware accelerated 3D. But after searching the Ubuntu Forums, I got it working.
I have never had to do a clean install on my machine ever. I have been running Ubuntu since the first release and I have been doing a dist-upgrade to keep up with every major release. The upgrade from Dapper to Edgy was even better as I did it through the Update Manager GUI for the first time and it worked like a charm.
What are the odds that you installed the drivers from ATI and not used the Ubuntu .deb packages for your ATI drivers? I would also guess that you have a wireless card and you did some fiddling around with it to get it to work?
From what I have been reading at the forums, a lot of the upgrade problems seem to come from people who have a very funky setup (e.g., unsupported wireless card, ATI drivers installed from packages downloaded from ATI, "alien" packages). As with any system with a package manager, if you deviate from the standard way of installing and maintaining packages for your system, then expect that you will have problems when upgrading.
Mod points? Since when did Anonymous Cowards get mod points?
Very few people point this out, but the best thing about using apt-src is that after you are done building from source, you can remove the -dev packages from your system and leave only the runtime dependencies.
Compare this with Gentoo which also pull in and build all the packages required to build a package from source. But after it's done building, your system is littered with header files and libtool link libraries that will never be used until you build the package from source again. This is one of my major gripes with Gentoo and is one of the reasons why I stopped using it. It got to the point where about 40% of my /usr filesystem was used by header files and compile time libtool libraries. You might argue that one could simply get a bigger hard disk. But using 40% of that disk for things that you need only once in a while is ridiculous.
Based on your reasoning above, we should all assume everyone is lying about everything. So in effect what you said above is a lie. Because you say that I should not believe what you say, unless I have a good reason to think what you say is true. I don't have a good reason to think that you say the truth. Which means that we should all assume that everyone is not lying. Which will mean that you're not lying about what you said above. But then...
GAH! Forget it! My brain hurts.
...none of them seem to offer an easy, consistent, and cross-platform solution to reports printing. I think this area of GUI toolkits is a bit lacking. There are third-party solutions like GNOME-Print, JasperReports (Java), ReportLab (Python), one other toolkit which QT-based, plus two other wxWidgets-specific solutions and yes, there's the expensive and Windows-only Crystal Reports. But they offer either a steep learning curve to use (Jasper) or tend to be a lot more fundamental in the features offered.
It's pretty easy to create a nice GUI program with all of these toolkits. But when it comes to implementing report generation and printing, it's a total nightmare. I know GUI toolkits should stick to GUI-specific objects and functions, but printing (and report generation) should be taken into consideration too.
So far, the only workable solution I have come across is using ReportLab as the report generation backend, with either PyGTK+, PyQT, or wxPython at the GUI frontend.
Sorry Microsoft, but my carrier has already been doing that for a while now: http://www.personfinder.ph/.
Additionally, when I was working as systems development lead for an SMS applications company, I developed a program that uses two cell sites to triangulate a phone's position based on relative signal strength. It was dropped out of development because ANTS beat us to it.
If this is Microsoft's vision of the future, I guess it would be safe to say "The future is NOW!".
Because that would require the hashed password and a preimage attack.
See here.
Summary for those who are lazy:
In conclusion, the value of this attack/exploit is only relative to how the hash function is used in an application. Just because this exploit and source code for it exists, that does not that these hashing algorithms are completely useless.
A large number of SK (professional) gamers still play old multiplayer games like WarCraft and StarCraft which already run well under Wine or Cedega, so that won't be the problem. Their problem will be with newer MMORPG games like Ragnarok, R.O.S.E. Online and Mu Online. These games have quite a following not only in SK but in other South-east Asian countries as well. This is the reason I still have Windows on on partition. I have been waiting for a native Linux port of these games for a long time but it seems that the developers have neither the resources or the motivation to make the port. AFAIK, these games use SDK's that are Windows-only and their servers depend on MSSQL to run.
However, with MS pulling their off their shit from SK shelves, this should force these game developers to go cross-platform eventually. So, here's to hoping that MS get's the slap-in-the-face ruling and that they do indeed remove their entire product line from SK.
And in your opinion, you completely seem to disregard package building. To be fair I don't know if you have ever used those packaging systems to build your own packages. If you have no experience rolling your own packages, then I urge you to try it on all the packaging systems you mentioned.
That's because you took it out of context of building packages. I am refering to the problem of having to specify all of the dependencies in the build script when building packages. And when I say "building packages" I mean to say taking a source tarball and constructing a package from said tarball. This includes the runtime dependencies. Using APT, when you build a package, normally you would only have to worry about build-time dependencies. Upon completion of a build and prior to packaging to a deb file, ${shlibs:Depends} on the Depends line of your debian/control file will automatically figure it out for you. Though you may not see this as a problem under Ports or Portage because in that system, build-time dependencies are most probably also run-time dependencies. But this leads to the "dusty deck" problem I described in my previous post.
Well, that is your case. What about those that run the OS on very limited disk space on very old hardware or in an virtualized environment? And I am not talking "a couple of megabytes" here. Case in point: there are some packages that will require LaTeX or Docbook to build documentation. Those packages are huge and they take a long time to compile. After building your package and installing it, you won't need LaTeX or Docbook to run your package. So what do you do? You remove the uneeded packages. But what happens when you upgrade the dependent packages?
Providing a clean way of removing your package from the system is an absolute must. Even if you do not care about uninstalling packages. It is important to be able to revert the system back to the original state before a package was installed. Which is why Debian packaging policy has very strict rules regarding packaging, especially with package removal. This is probably why some packages are done badly. Most packagers are in the same mental frame as you and say to themselves "Nah, nobody will want to uninstall this.". Plus, there are some (badly made) packages that will not even upgrade cleanly and still require you to remove cruft from the previous version.
This is the main reason to roll your own packages. If your distro is behind, you sh
Wow! Is that all it takes to get a +5 Insightful now? So I guess this will be modded Troll or Flamebait.
I can never really understand why FreeBSD ports is better than Debian's APT. Perhaps it's only because they look at "package installation" as the only use for these tools, whereas I use these tools for "package management". Everything comes down to the packagers who make and maintain the packages and the quality of the tools used to make and maintain the packages. I've used FreeBSD, Gentoo, and finally Debian for servers and desktops. Based on my experience APT is a more elegant solution to package management compared to FreeBSD Ports and Gentoo Portage for the following reasons:
Package Building
Although building Debian packages can be a bit overwhelming especially for newcomers, it really shines especially if you have installed debhelper, dh-make, dbs, dpatch, and lintian. What's really great about APT is the automatic runtime dependency resolution prior to packaging the final debs. After building the package and before it gets packed into a deb, a dependency checker is run through it and it will automatically figure out the runtime dependencies for you. On FreeBSD Ports and Gentoo Portage, you have to figure out and specify runtime dependencies yourself.
The "Dusty Deck" Problem
When I install a package using ports or emerge, it will also install the dependencies. But most of the time you will essentially be installing from source (and yes I am aware that Ports and Portage also have pre-built packages). When you do that, Ports and Portage will install and build the build-time dependencies of the package you are installing. Now, that's fine if those build-time dependencies are also needed at run-time. But some dependencies are only used at build-time and will never be used again until you upgrade the packages that depend on them. You can decide to remove them after build time, but then when you update the package they will be downloaded, rebuilt, and installed again. You eventually grow tired of this cycle that you just leave these build-time only packages and then they continue to accumulate on your disk mostly wasting space.
This is probably the reason why there are "developer" packages for libraries that contain only the header files and the link libraries. Once you're done with building, you can uninstall the developer package. Try doing that under Ports or Portage. Oh, wait! You can't. The runtime and build-time dependencies are all in one package.
Package Uninstallation
Now this is where Ports and Portage, IMHO, really suck. When I uninstall a package from my system I want it gone. apt-get remove --purge and a properly packaged deb will do that for you. Ports and Portage will leave "package cruft" on your system. "Package cruft" can be anything from stale config files to build-time dependecy packages. You will have to track and remove those things manually.
I know these three points can be resolved on both Ports and Portage if the packages are done correctly. This is where APT has an advantage over Ports and Portage: being able to make a proper package. On Debian, with the tools I mentioned above installed, a package maintainer's life is greatly simplified.
Ports (and Portage) does Rock, but only if all you ever care about is package installation and not package management (package building, installation and uninstallation).
How long before the Japanese start capturing them for "scientific" purposes? You know, like they do with whales?
Ok, you can mod me flaimbait now...
Check out these deviants...
SpecOpS Labs slaims in 1 year time-lapse...
The VC's who put their money into SpecOpS Labs are probably itching to get their ROI by now. They probably burned through their capital funding and now the VC's want some returns, or at least a product that can be marketed. These guys are desperate now. $10,000 is probably the only money they have left and the VC's won't give them anything more unless they come up with something.
I always thought these people were just VC fishers.
See also their previous page with buzz-word laden spiels, and outlandish claims.
I live in the Philippines and I got my 10 CDs of Hoary last June 25, which is about one month after they were shipped out from The Netherlands. I ordered them about a week after the official release.
If you login to your shipit account, you can check the status of your order there. If it says your order has been shipped out, then it has. If it didn't make it to you, then it probably got lost en route to your place. It's rare these days, but it still happens.
Don't you mean: Is Linux For Loosers?
Engrish. It is teh cofusing.
Yogurt: Merchandising, merchandising, where the real money from the movie is made. Spaceballs-the T-shirt, Spaceballs-the Coloring Book, Spaceballs-the Lunch box, Spaceballs-the Breakfast Cereal, Spaceballs-the Flame Thrower.
[turns it on]
The Dinks: Ooooh!
Yogurt: (reacts to dinks) The kids love this one. (A dink hands him a doll that looks likes Yogurt) And last but not least, Spaceballs the doll, me.
[Pulls string]
Doll: May the schwartz be with you!
...
Philosophy my ass...
Loosers.
I went to other distros when RHL became FC. For servers, I went to SuSE. For workstations I tried Mandrake, then Conectiva, and finally staying with Ubuntu.
I don't see myself returing to FC, just for the sake of using the latest whizbangerry that comes with it (if I wanted that, I would be using Gentoo). I use Linux on production systems and FC is a beta testing project that Redhat has shoved down their users' collective throats. Plus a recent install attempt with FC3 got me burned badly with its broken SELinux configuration that I had to fix it manually by editing the policy files (yah, I know that they later released updates that fixed that, and those updates kept on erasing my policy file fixes).
...the stupid and shameless kind? :) It *is* wine. Look at the screen shots. The wine directory on the filesystem tree, the references to wine files on the lst icons... You'd think they would be smart enough to hide evidence of a rip-off since they were smart enough to change the titles on the wine windows.
These specops guys seem to be just VC phishing. The things they say on their buzzword-laden website reads investment scam all the way.
Only a problem when, as you, you come from 1.x days. Programs written for 2.0 work the same in 2.2, 2.4 and 2.6.
:) But learning how to port my apps to 2.0 is taking me a while because of the API changes and some of the new features that were introduced.
Yup. Matter of fact I am still stuck in 1.x
If you want to take advantage of new features, that's another issue.
One thing that seems to have really improved in 2.0 is printing support and my apps require a lot of printing code. But lots of things have changed between 1.x and 2.x when it comes to printing. Add to that the API changes in GTK. You got a ton of docs to wade through just to figure out what will work and what will break between the two versions. Oh well...
...does it still work like in the old one? That's the one feature I really like about the old file selector. Sure the old one may look ugly but it serves its purpose.