Not quite, but before I could finish the Far Cry download it stopped and they disabled downloads of it. Admittedly, I'm in Canada, not the US, but here's what they said:
All downloaded files which have not been activated are going to be made inactive through the ubi.com login. Previously, the ubi.com login would require a US country in order to install the game. Ubisoft will make the ubi.com login reject all entries into country. They hope to relaunch the program once we can add IP-blocking into our login process.
fglrx currently has Xv acceleration using the GPU on R500 series cards, and it works well enough that I can watch 1080p H.264 content with no dropped frames. It's the one (and only) thing it currently beats the Nvidia drivers on.
I saw that too, except I just clicked on the "continue to public download server" or whatever the link was called. Downloads are going as I type this...
Well I just read about a different survey that concluded that over 50% of people on slashdot are women. I don't know about you, but I found that number rather surprising.
It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.
Currently I can't say: function x, it gets executed by Acrobat Reader 2.1, Firefox, fuzzycalc and Darly's Printshop. So the person who implements it can test it with these applications that make use of it.
Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.
I understand that a function does not need to be 100% implemented. But think about a sponsor who says: I want to sponsor dll x. Or: My program WAccounting uses these 5 API calls, I want this program to run perfect under Wine, what does it cost me?
What also motivates people is to see a kind of progress bar. I mean a automated script that indicates how much stubs and so on are in there.
I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the.spec file for each DLL, but this isn't always accurate. For example, the.spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.
I also would like to get informed how to debug an application with Wine. The documentation is heavily outdated and imcomplete here. WINEDEBUG=+relay is intresting, I tried it out. But the documentation is not very informative here.
My perception is that we will get
- almost perfect DirectX games support
- very good installer and crypto support.
because here it really does scale but wine development did not scale that much over the past years.
Have used a Nipple. Outgrew the nipple (no matter how intuitive the use of it might seem). Can't do two finger scrolling with a nipple, a feature which makes a number of operations on a laptop even easier than a desktop. No thanks.
That's why you have both the nipple and the touchpad. I turn my entire touchpad into a scrolling (both horizontal and vertical) device. This way I can use the nipple for mousing around (with 3 actual buttons), and can use my thumb on the touchpad for scrolling, all without taking my hands away from the home row.
I'm aware of the suboptimal workarounds for the missing actual buttons, all modern touchpads do that (but most include at least 2 actual buttons as well). Still, said workarounds are suboptimal at best, and a minimum of 3 buttons are required.
How much does it cost to make a DLL that is currently 75% --> 100% ?
That's a question that probably only the original implementor(s) of the API could answer, however, it's normally not the question you need answered. The vast majority of apps don't need 100% of a DLL, they only use small subsets of it. The commonly used parts of most DLLs are already implemented, the real roadblock is finding the undocumented corner cases (and the expected behaviour), and ironing out any existing bugs.
what Wine is really missing is a tool that documents all calls by programs, so you say: aha, this stub is needed by these applications, so let's implement it.
Really, that tool already exists. Use WINEDEBUG=+relay and you'll see every function call made by the program as it makes it. Furthermore, stubs and functions that are known to be incomplete will print their own output (STUB or FIXME) if they're called.
Ultimately though, missing or stub functions aren't that big of a problem, it's usually fairly obvious if an app needs them, but they're missing. The real problem is the incomplete/missing/wrong Win32 API documentation on MSDN and everywhere else. The Win32 API documentation is sufficiently poor, that you really need to a) closely examine what an existing app expects of the API, and b) actually test the API yourself on all versions of Windows (they tend to differ on details). Often times, the best/only Win32 API documentation is the Wine source.
At this point, Wine's D3D implementation is more mature than Cedega's. Wine introduced SM2/3 support months before Cedega, for example. On top of that, Wine has also completed a number of (painful) steps required to get a slew of copy protection methods working.
Besides that, Cedega contributes essentially no code back to Wine, although they do use a number of DLLs from Wine now. I don't really see the incentive on either side for a merge to happen now.
You're comparing apples to oranges there, Debian (and many other distros) split single packages into multiple packages where possible to somewhat emulate the modularity of USE flags and causes the number of packages to be larger than the number of pieces of software available/installed.
Fedora for example (used to) package Wine into something like a dozen separate packages, one for each sound driver (Alsa, OSS, NAS, ESD, and JACK, at least), along with a couple other package splits that I don't recall the details of. In comparison, Gentoo has exactly one package for Wine with a slew of USE flags and versions. You can see the same pattern repeat for lots of other software.
What this does bring up, though, is the unfilled need currently of having an auto-upgrader software package where new kernel packages can be auto-upgraded and then migrated too on the fly without requiring a reboot.
Your numbers are way off. The number of packages that take more than a minute at most to compile and install on modern hardware is, at most, about 20-30% of the ~600 packages I have installed (and 600 is a lot of packages, most people have less). Furthermore, the entire process is automated and you're free to use your computer exactly as if you weren't updating, so it really doesn't matter how long the compile takes. Thus, you can sync and update at your leisure. I usually do so once or twice a week, and it takes well under a minute of my time (per week!), which I think is quite reasonable given that that's all that's needed to maintain a completely up to date system tailored exactly to my needs.
For me, any distro other than Gentoo would be a lot more work, because I like to stay on the bleeding edge of software, and in my experience, Portage has always had the largest and most up to date selection of software that works with the least amount of fuss. Even if only one or two packages are missing or too old from a given distribution's repository, that's already going to cause me substantially more work than a minute a week to maintain it manually, and I ran into that situation frequently with other distributions. I've yet to find any software that I wanted that wasn't already available in Portage in several years I've been using it.
Another point to consider is that Gentoo is always current and up to date, you never need to upgrade to Gentoo n+1 as you do with basically every other distribution. Big upgrades are nearly impossible to get done perfectly (and software breaking is something that is statistically infeasible to avoid), so with a non-Gentoo distro, when something breaks, you have no idea what caused the problem, because everything was changed at the same time. With Gentoo, if something breaks after an update, (I or someone else) have a handful of packages to blame at most, making the problem exponentially easier to find and fix.
I won't say that Gentoo isn't daunting at first, because it is. I spent several hours doing my first Gentoo install (which is still running, over 3 years later), but now a new install of Gentoo takes me under half an hour, and a very trivial amount of time to maintain. The package management in Gentoo is second to none, and when it really comes down to it, that's the only part of a distro that actually matters. The choice is obvious to me.
It'd be nice to see some progress on:nth-child() support and positioning for generated content support. Konqueror supports both of these already, and it'd be nice to have feature parity there. Don't bother mentioning IE, because I don't care about IE.
...and many Linux distros are also considering [ZFS].
Consider is the most they'll do. ZFS's license is incompatible with the GPL, and thus will not be integrated into Linux. Some would say that Sun deliberately choose a GPL incompatible license for ZFS, but that's a topic for another flamewar.
If you use fake RAID, then you basically have no guarantee that the on disk format will be the same from one motherboard to the next, even within a particular vendor.
I would suggest not using fake RAID if you have any intentions of moving the disks to a new system (or really, at all... the only potential plus is Windows compatibility). Fake RAID uses a vendor-specific proprietary on disk format, and is typically slower than both software RAID, and hardware RAID.
RAID in any form has minimal impact on disk seeks, so if you're reading lots of tiny files, you'll notice minimal (if any) performance gain. Where RAID really shines is reading or writing large sequential files, where your performance increases more or less linearly with the number disks in the array (although this depends on what RAID level you use).
RAID 0 drastically increases your chance of data loss. For example, with 8 100G disks in RAID 0, if you lose any single disk, you lose all 800G of data stored in that RAID 0 partition. I wouldn't suggest RAID 0 for anything you can't completely recreate painlessly, unless you don't care about losing the data (and if you don't, then why do you have it in the first place?).
Slashdot Mirror
That's not true.
Not quite, but before I could finish the Far Cry download it stopped and they disabled downloads of it. Admittedly, I'm in Canada, not the US, but here's what they said:
fglrx currently has Xv acceleration using the GPU on R500 series cards, and it works well enough that I can watch 1080p H.264 content with no dropped frames. It's the one (and only) thing it currently beats the Nvidia drivers on.
I saw that too, except I just clicked on the "continue to public download server" or whatever the link was called. Downloads are going as I type this...
I'd believe it if the sample size was 2.
It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.
Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.
In general, people don't seem to care about how much of a DLL is implemented, they care about if their programs foo, baz and bar work. Most of the major investments into Wine have been to make a particular program (or set of programs) work, such as Google with Picasa (list of patches), or Corel with Wordperfect and CorelDRAW (until Microsoft threw a large chunk of money at them).
In a similar vein, Codeweavers offers porting services for Wine, ie, they'll make a particular application work, and they can give you an estimate of how much it'll cost, on a case by case basis.
I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the .spec file for each DLL, but this isn't always accurate. For example, the .spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.
Here's the complete list of WINEDEBUG channels, as well as some useful registry keys, and a debugging tutorial. Generally when you're debugging something, WINEDEBUG can be very useful with the right channels selected.
Actually, as I menti
That's why you have both the nipple and the touchpad. I turn my entire touchpad into a scrolling (both horizontal and vertical) device. This way I can use the nipple for mousing around (with 3 actual buttons), and can use my thumb on the touchpad for scrolling, all without taking my hands away from the home row.
I'm aware of the suboptimal workarounds for the missing actual buttons, all modern touchpads do that (but most include at least 2 actual buttons as well). Still, said workarounds are suboptimal at best, and a minimum of 3 buttons are required.
Similarly, I also got a Thinkpad (T40) when I started University. After 4 years of heavy use, it's still like new, and has never needed any repairs.
In comparison, any Mac laptop would be useless to me as they a) don't have a nipple, and b) only have 1 mouse button.
Doubtful.
No.
Probably not.
Probably not, but I'm not familiar with FlexLM.
No.
That's a question that probably only the original implementor(s) of the API could answer, however, it's normally not the question you need answered. The vast majority of apps don't need 100% of a DLL, they only use small subsets of it. The commonly used parts of most DLLs are already implemented, the real roadblock is finding the undocumented corner cases (and the expected behaviour), and ironing out any existing bugs.
Really, that tool already exists. Use WINEDEBUG=+relay and you'll see every function call made by the program as it makes it. Furthermore, stubs and functions that are known to be incomplete will print their own output (STUB or FIXME) if they're called.
Ultimately though, missing or stub functions aren't that big of a problem, it's usually fairly obvious if an app needs them, but they're missing. The real problem is the incomplete/missing/wrong Win32 API documentation on MSDN and everywhere else. The Win32 API documentation is sufficiently poor, that you really need to a) closely examine what an existing app expects of the API, and b) actually test the API yourself on all versions of Windows (they tend to differ on details). Often times, the best/only Win32 API documentation is the Wine source.
A 64-bit Wine would only run 64-bit Windows applications (ie, nothing). You don't want a 64-bit Wine.
You can of course run 32-bit Wine on a 64-bit Linux install, I do exactly this without issue.
At this point, Wine's D3D implementation is more mature than Cedega's. Wine introduced SM2/3 support months before Cedega, for example. On top of that, Wine has also completed a number of (painful) steps required to get a slew of copy protection methods working.
Besides that, Cedega contributes essentially no code back to Wine, although they do use a number of DLLs from Wine now. I don't really see the incentive on either side for a merge to happen now.
If even a realldoll won't accept you... well... maybe you should just stay inside like the rest of us.
You're comparing apples to oranges there, Debian (and many other distros) split single packages into multiple packages where possible to somewhat emulate the modularity of USE flags and causes the number of packages to be larger than the number of pieces of software available/installed.
Fedora for example (used to) package Wine into something like a dozen separate packages, one for each sound driver (Alsa, OSS, NAS, ESD, and JACK, at least), along with a couple other package splits that I don't recall the details of. In comparison, Gentoo has exactly one package for Wine with a slew of USE flags and versions. You can see the same pattern repeat for lots of other software.
You mean something like Kexec?
Your numbers are way off. The number of packages that take more than a minute at most to compile and install on modern hardware is, at most, about 20-30% of the ~600 packages I have installed (and 600 is a lot of packages, most people have less). Furthermore, the entire process is automated and you're free to use your computer exactly as if you weren't updating, so it really doesn't matter how long the compile takes. Thus, you can sync and update at your leisure. I usually do so once or twice a week, and it takes well under a minute of my time (per week!), which I think is quite reasonable given that that's all that's needed to maintain a completely up to date system tailored exactly to my needs.
For me, any distro other than Gentoo would be a lot more work, because I like to stay on the bleeding edge of software, and in my experience, Portage has always had the largest and most up to date selection of software that works with the least amount of fuss. Even if only one or two packages are missing or too old from a given distribution's repository, that's already going to cause me substantially more work than a minute a week to maintain it manually, and I ran into that situation frequently with other distributions. I've yet to find any software that I wanted that wasn't already available in Portage in several years I've been using it.
Another point to consider is that Gentoo is always current and up to date, you never need to upgrade to Gentoo n+1 as you do with basically every other distribution. Big upgrades are nearly impossible to get done perfectly (and software breaking is something that is statistically infeasible to avoid), so with a non-Gentoo distro, when something breaks, you have no idea what caused the problem, because everything was changed at the same time. With Gentoo, if something breaks after an update, (I or someone else) have a handful of packages to blame at most, making the problem exponentially easier to find and fix.
I won't say that Gentoo isn't daunting at first, because it is. I spent several hours doing my first Gentoo install (which is still running, over 3 years later), but now a new install of Gentoo takes me under half an hour, and a very trivial amount of time to maintain. The package management in Gentoo is second to none, and when it really comes down to it, that's the only part of a distro that actually matters. The choice is obvious to me.
s/upgrading/changing/;
Honestly though, this pile of dung is by far the best pile of dung that I've seen.
Your experiences with ATI are rather atypical. I have a Radeon X1400 that's half the speed of a Geforce 6600 in 3D apps, 114x times slower than a Geforce 6600 in 2D apps and 15x times slower than a Radeon 7500 with the open source drivers in 2D apps.
They might, but then again, they might not. Wait until they actually do something other than say they might do something before you make a decision.
It'd be nice to see some progress on :nth-child() support and positioning for generated content support. Konqueror supports both of these already, and it'd be nice to have feature parity there. Don't bother mentioning IE, because I don't care about IE.
ReactOS isn't a Linux variant by any means. It's an attempt to reimplement Windows completely from the ground up, without using any Linux components.
Consider is the most they'll do. ZFS's license is incompatible with the GPL, and thus will not be integrated into Linux. Some would say that Sun deliberately choose a GPL incompatible license for ZFS, but that's a topic for another flamewar.
If you use fake RAID, then you basically have no guarantee that the on disk format will be the same from one motherboard to the next, even within a particular vendor.
I would suggest not using fake RAID if you have any intentions of moving the disks to a new system (or really, at all... the only potential plus is Windows compatibility). Fake RAID uses a vendor-specific proprietary on disk format, and is typically slower than both software RAID, and hardware RAID.
RAID in any form has minimal impact on disk seeks, so if you're reading lots of tiny files, you'll notice minimal (if any) performance gain. Where RAID really shines is reading or writing large sequential files, where your performance increases more or less linearly with the number disks in the array (although this depends on what RAID level you use).
RAID 0 drastically increases your chance of data loss. For example, with 8 100G disks in RAID 0, if you lose any single disk, you lose all 800G of data stored in that RAID 0 partition. I wouldn't suggest RAID 0 for anything you can't completely recreate painlessly, unless you don't care about losing the data (and if you don't, then why do you have it in the first place?).