Please, leave your tin foil hats at home before you post.
Personally, I'm waiting for the "our government has tampered with tin foil production, now it all has rfid tags embedded in it, our hats are corrupting our minds" conspiracies.
Eminem isn't that bad of a guy, on a personal level. My father owned the vehicles and paid the drivers that transported his stage equipment between concerts (along with other figures such as Britney Spears and dozens of other "artists" I don't remember). Eminem was quite nice to the drivers, unlike Ms. Spears who was a complete bitch to them. (Or maybe the drivers were just mad about her not paying attention to them and "escalated" the stories a bit...)
We got a couple huge (and I mean *huge*) bags of M&Ms from him because he liked the drivers so much, and my sister has a signed N'Sync poster (or is it Backdoor Boys? One of the two.) that Eminem personally got for her.
Eminem is also the guy who tried to keep my father's business from going bankrupt after the company that held the contract with Eminem's producers/rhodeo/whatever and my father's company (who leased the trucks/drivers to the other company) decided to screw us over majorly (6 figure losses). Granted, my father's company still went bankrupt, but it lasted a bit longer thanks to Eminem.
Despite that, I still can't stand his music. ~,^
And that wraps up today's episode of Stuff Nobody Cares About.:)
"I'd rather have the "negative" (most safe option) button always in the same location in the dialog. Just to make sure I don't mess up with something by clicking "Yes" or "Save" instead of "Cancel"."
The 'Save' (action) button is always in the bottom right hand corner. Any additional/alternative action buttons are to the left of that, with Cancel being the left most button. Some dialog have a Help button, which then becomes the left most, being located in the lower-lefthand corner of the dialog. This is also good for consistency, as Cancel is always the left-most button in the action group (easy to find and consistent) and Help (if present) is always the left-hand corner. Thus, the three most used buttons are always located in the same place (relatively) in every app. I suppose my use of the phrase "positive" was erroneous, since we clearly don't attach the same meaning to it in this regard.;-)
The HIG states that the dialog's main action should be the most likely desired action. For a Save/Quit dialog, that would be Save, as an example.
Cancel must never have side effects. Cancel by meaning stops an action, so it can't very well perform one! Cancel in a Save/Quit dialog would mean don't save, but also don't quit. An example dialog thus might have buttons as so:
[Cancel] [Quit] [Save and Quit]
In most cases, you want "Save and Quit." In fact, a large number of users I know (including my boss) intentionally hit the close window button and just select Save from the dialog, versus going to File->Save before quitting.
This absolutely could have been done while maintaining the classic OK/Cancel ordering. I.e., the above dialog could be:
[Save and Quit] [Quit] [Cancel]
That doesn't have the human-friendly characteristics, however. As some people mention, it's better for consistency with legacy applications. I don't see the point in maintaining legacy compatibility with apps we'd like to get rid of (like all of Windows ~,^ ), but that's just a personal opinion (and not the reasoning behind the change). The GNOME style is definitely consistent with the Mac, which I use a lot more than I do Windows, so in that sense KDE and legacy X11 apps are more of a pain (consistency wise) than GNOME is.;-) [and these legacy apps also usually have a hell of a lot larger UI/consistency problems than something so minute as button order in dialogs!]
All in all, I and many others prefer GNOME's GUI, many others prefer KDE's GUI, and other prefer neither. Choose whichever you like. My only request is that you not misrepresent the choice you don't like.:)
The GNOME changes have nothing to do with assuming users are idiots. They have to do with cleanliness. I'm a developer, and I understand what just about any GUI option you throw at me does, or am quite capable of figuring it out. That doesn't mean I want to wade thru page after page after page of options which have no relation to what I want to do to find the one option I'm looking for.
The GNOME changes are not dumbed down, they're cleaner. Advanced users are still quite capable of changing a plethora of options, using advanced methods. Only the very commonly changed options are placed in the menues and config panels, which makes it dead easy for both novices *and* experienced users to tweak the common things.
So far as the gatuitious UI changes, there are clear advantages to the way GNOME has chosen to do things. The dialog button order is a favorite thing of people who wish to bash GNOME, and thus serve as an excellent example. The new button order is *easier* on people both physically and mentally. (location of button wrt mouse movements, location wrt eye movements, etc.)
Additionally, there are no "OK" buttons. If you find one, it's a bug. Which is great. If you see a dialog, what the hell does "OK" mean? You have to read the whole dialog. And deal with the fact that in some cases, "OK" is the safe option, while in others it's the dangerous option. Different apps would pop up dialogs with different OK/Cancel meanings for the same dialog action. (like quit without saving - does OK mean "OK, Save" or "OK, Quit" ?) GNOME solves the problem by mandating that you don't use OK, but put the actual action as the button label. "Save" or "Quit". Much, much harder to accidently click OK when you meant Cancel because the meanings for two apps are different.
Granted, the last bit can be done even with the Windows/KDE button order (i.e. [Save] [Cancel] vs [Cancel] [Save]), which is something I really wish both Windows/KDE would do. The GNOME/Mac ordering however makes for consistent button location, however, since the "positive" (most commonly used) button is always in the same location in the dialog, which (as mentioned above) is both easier and more efficient physically and mentally, for both novice and experienced users. KDE having the ability to change button orders (as I've been told it does) is definitely cool; it would be great if they defaulted to the more human-friendly GNOME/Mac order, and let users who refused to learn switch back to the classic order.
Lots of users and developers think the GNOME/Mac button order is "weird" because they're used to the Windows' way, but that kind of thinking doesn't ever foster improvements. Thankfully, GNOME, OS X, KDE, and most other modern desktops are willing to break the mold and do things differently, even at the risk of "confusing" users, for the sake of moving the GUI experience forward, and not keeping us all locked into Microsoft's (and others') design mistakes made a decade or more ago.
I don't claim that GNOME has things perfect. Far from it. Simply explaining the reasoning behind certain 'controversial' changes. Hopefully useful.:)
Mono is not compiled as a Windows app. It does use WineLib for providing certain APIs for Windows.Forms. Using WineLib is no different than using GTK+ - they're both just APIs/libraries. Mono *is* working on Windows.Forms, using several different backends - WineLib, Cairo and GTK+. I believe the Cairo one is what they plan on using "officially" when complete. DotGNU and Mono can and do share code/assemblies, btw, so if DotGNU does indeed have a WinForms assembly, Mono should (theoretically) be capable of just using that.
On a side note, I just love how posts (like the parent) which are half-guessed speculation and mostly false manage to get "+5 Informative"...
Honestly, just get some friends together on a LAN and play. It's more entertaining than playing with a mass of immature idiots online anyhow.;-)
It'll also give you the opportunity to build up those skills to get good enough to compete with the losers^wpros who spend all their time playing FPS games.
You're confusing Open Source with Free Software. Free Software licenses protects the code from being "stolen" and used in a non-Free product. Open Source licenses merely let users who have the source do what they will with it (with varying restrictions).
AweMUD (my main projects) for example is Open Source to the core, and I fully support anyone wishing to use it in a non-Open/non-Free project. If AweMUD were Free Software, then that wouldn't be possible. (Without getting the code under a second license from me and all the AweMUD contributors.)
Don't forget patents. NVidia can't release code for things like S3TC and other patented algorithms, but several games/apps require these to work properly.
Sure, one could blame the game developers for requiring patented code, but when you get to the people who want to just use their computers (like me), it all comes down to "does the damn thing work or not?"
On a completely different note, it's a bit sad how (some) kernel developers want to purposefully hard for binary only drivers. Even if drivers have source available, that's *still* a pain for users. What happens when the API changes? (Like it manages to do even in stable series.) Sure, the vendor GPL'd the driver, the driver is probably in some future kernel version the user doesn't have, and the driver on the disk/CD that came with the hardware doesn't work with the user's kernel. Upgrading kernels can be a nightmare (especially when you end up with an update that breaks something which previously worked; also a bit too common).
API and ABI compatibility has many more benefits than just allowing proprietary drivers. Too many developers don't seem to see them tho.:(
The ad's line "We're still going to download music for free" is in regards to the iTunes give-away. i.e., those who earn the points/prizes from Pepsi's promotion get to grab a limited number of songs off iTunes for free, with Pepsi footing the bill paying the artists/labels.
These systems don't look bad for business or casual use, and probably also good enough for development use, but the gamer in me likes the XPC systems a lot better.
Unfortunately, it doesn't work that way. You can't compile and get just the extra registers. You have to take it all, which includes changes to things size changes of certain data types. The software will likely need modifications for this if the developers never intended to run on non-32-bit systems.
"The men and women who play the stock market on a regular basis are no fools"
Right... explain to use the dot-com era then, eh?;-)
Stock market history is filled with investors who had absolutely no idea what they were doing, because the companies or technologies they invested in were either entirely made of lies or simply not what the investors hoped it would be. These are, after all, stock market investors, and not technologists or lawyers who actually understand what they're investing in - just the press releases and marketing geared towards them.
Granted, it's entirely possible SCO does have some secret trump card. I'm doubting it, but it does still seem a bit foolish to write them off entirely until they are completely gone.
Likely, vendors will only ship one version of their app, the 32-bit version, since AMD64 CPUs can run 32-bit and 64-bit. If the app doesn't need or greatly benefit from 64-bit, why bother with it? (The code will likely need porting to 64-bit anyway, especially by average Windows programmers who've never had to worry about different CPU architectures before.)
Apps that greatly benefit from 64-bit support may either be 64-bit only, or provide both versions. I recall reading that the UT developers plan on requiring 64-bit mode for their next-gen game content development tools, for example.
Generally, it'll have to do with the market. If an app can get away with a 32-bit version, it will have one, since most people will still have 32-bit CPUs in the forseeable future. Apps that can really get a boost from 64-bit will have the extra money put into developing a 64-bit version in hopes that it will sell more copies that way.
I quit cold turkey several months ago. Sure, I got slight headaches a bit for about a week after, but ever since, no problem. No blinding headaches, no severe grumpiness (well, technically I was grouchy ass even when I was drinking an eight pack of MD every day, and I'm no better now, but I didn't get any *worse* either). Was I just lucky that I could go from such an extreme amount of caffiene everyday to none with no major problems or side affects?
(For a note, I do drink caffiene again, but in very slight moderation, simply because even with caffiene I'm dead in the morning. I drink one bottle of either MD or Bawls in the morning when I first get into work, and nother but water the rest of the day. This is after about 4 months of no caffiene at all, tho.)
Switch my phone carriet just last weekend, actually. Much better, and much cheaper, service now, plus I have a nice new phone with features my old providor didn't support. And I still get to keep my very fun number. (Which I won't post here for obvious reasons. It is comprised of a rather interesting pattern of numbers, tho, very easy to remember, and I always get strange looks, like, "you're kidding," when I tell people my cell number.)
"Then there are problems with USB devices, and others that, being narrowed down, comes down to problems on the APIC interface [slashdot.org]. From what I've heard so far, it doesn't look stable, so why ship it on linux 2.6?"
Because a huge number of modern machines *require* ACPI in order to operate properly. my machine at work (Compaq Evo) requires it to reboot properly, my laptop can't be on for more than a few minutes without it, my home-built desktop machine needs it for a few things, etc.
Distributors or knowledgable users who know ACPI won't work for them and/or don't care about loss of features or inability to run on a wide-range of machines can just disable ACPI, so it shouldn't be that big of a deal.
Slashdot Mirror
Please, leave your tin foil hats at home before you post.
Personally, I'm waiting for the "our government has tampered with tin foil production, now it all has rfid tags embedded in it, our hats are corrupting our minds" conspiracies.
Eminem isn't that bad of a guy, on a personal level. My father owned the vehicles and paid the drivers that transported his stage equipment between concerts (along with other figures such as Britney Spears and dozens of other "artists" I don't remember). Eminem was quite nice to the drivers, unlike Ms. Spears who was a complete bitch to them. (Or maybe the drivers were just mad about her not paying attention to them and "escalated" the stories a bit...)
:)
We got a couple huge (and I mean *huge*) bags of M&Ms from him because he liked the drivers so much, and my sister has a signed N'Sync poster (or is it Backdoor Boys? One of the two.) that Eminem personally got for her.
Eminem is also the guy who tried to keep my father's business from going bankrupt after the company that held the contract with Eminem's producers/rhodeo/whatever and my father's company (who leased the trucks/drivers to the other company) decided to screw us over majorly (6 figure losses). Granted, my father's company still went bankrupt, but it lasted a bit longer thanks to Eminem.
Despite that, I still can't stand his music. ~,^
And that wraps up today's episode of Stuff Nobody Cares About.
"I'd rather have the "negative" (most safe option) button always in the same location in the dialog. Just to make sure I don't mess up with something by clicking "Yes" or "Save" instead of "Cancel"."
;-)
;-) [and these legacy apps also usually have a hell of a lot larger UI/consistency problems than something so minute as button order in dialogs!]
:)
The 'Save' (action) button is always in the bottom right hand corner. Any additional/alternative action buttons are to the left of that, with Cancel being the left most button. Some dialog have a Help button, which then becomes the left most, being located in the lower-lefthand corner of the dialog. This is also good for consistency, as Cancel is always the left-most button in the action group (easy to find and consistent) and Help (if present) is always the left-hand corner. Thus, the three most used buttons are always located in the same place (relatively) in every app. I suppose my use of the phrase "positive" was erroneous, since we clearly don't attach the same meaning to it in this regard.
The HIG states that the dialog's main action should be the most likely desired action. For a Save/Quit dialog, that would be Save, as an example.
Cancel must never have side effects. Cancel by meaning stops an action, so it can't very well perform one! Cancel in a Save/Quit dialog would mean don't save, but also don't quit. An example dialog thus might have buttons as so:
[Cancel] [Quit] [Save and Quit]
In most cases, you want "Save and Quit." In fact, a large number of users I know (including my boss) intentionally hit the close window button and just select Save from the dialog, versus going to File->Save before quitting.
This absolutely could have been done while maintaining the classic OK/Cancel ordering. I.e., the above dialog could be:
[Save and Quit] [Quit] [Cancel]
That doesn't have the human-friendly characteristics, however. As some people mention, it's better for consistency with legacy applications. I don't see the point in maintaining legacy compatibility with apps we'd like to get rid of (like all of Windows ~,^ ), but that's just a personal opinion (and not the reasoning behind the change). The GNOME style is definitely consistent with the Mac, which I use a lot more than I do Windows, so in that sense KDE and legacy X11 apps are more of a pain (consistency wise) than GNOME is.
All in all, I and many others prefer GNOME's GUI, many others prefer KDE's GUI, and other prefer neither. Choose whichever you like. My only request is that you not misrepresent the choice you don't like.
The GNOME changes have nothing to do with assuming users are idiots. They have to do with cleanliness. I'm a developer, and I understand what just about any GUI option you throw at me does, or am quite capable of figuring it out. That doesn't mean I want to wade thru page after page after page of options which have no relation to what I want to do to find the one option I'm looking for.
:)
The GNOME changes are not dumbed down, they're cleaner. Advanced users are still quite capable of changing a plethora of options, using advanced methods. Only the very commonly changed options are placed in the menues and config panels, which makes it dead easy for both novices *and* experienced users to tweak the common things.
So far as the gatuitious UI changes, there are clear advantages to the way GNOME has chosen to do things. The dialog button order is a favorite thing of people who wish to bash GNOME, and thus serve as an excellent example. The new button order is *easier* on people both physically and mentally. (location of button wrt mouse movements, location wrt eye movements, etc.)
Additionally, there are no "OK" buttons. If you find one, it's a bug. Which is great. If you see a dialog, what the hell does "OK" mean? You have to read the whole dialog. And deal with the fact that in some cases, "OK" is the safe option, while in others it's the dangerous option. Different apps would pop up dialogs with different OK/Cancel meanings for the same dialog action. (like quit without saving - does OK mean "OK, Save" or "OK, Quit" ?) GNOME solves the problem by mandating that you don't use OK, but put the actual action as the button label. "Save" or "Quit". Much, much harder to accidently click OK when you meant Cancel because the meanings for two apps are different.
Granted, the last bit can be done even with the Windows/KDE button order (i.e. [Save] [Cancel] vs [Cancel] [Save]), which is something I really wish both Windows/KDE would do. The GNOME/Mac ordering however makes for consistent button location, however, since the "positive" (most commonly used) button is always in the same location in the dialog, which (as mentioned above) is both easier and more efficient physically and mentally, for both novice and experienced users. KDE having the ability to change button orders (as I've been told it does) is definitely cool; it would be great if they defaulted to the more human-friendly GNOME/Mac order, and let users who refused to learn switch back to the classic order.
Lots of users and developers think the GNOME/Mac button order is "weird" because they're used to the Windows' way, but that kind of thinking doesn't ever foster improvements. Thankfully, GNOME, OS X, KDE, and most other modern desktops are willing to break the mold and do things differently, even at the risk of "confusing" users, for the sake of moving the GUI experience forward, and not keeping us all locked into Microsoft's (and others') design mistakes made a decade or more ago.
I don't claim that GNOME has things perfect. Far from it. Simply explaining the reasoning behind certain 'controversial' changes. Hopefully useful.
Simple. The monkey *watches*. ;-)
- 06 -12&res=l
http://www.penny-arcade.com/view.php3?date=2002
"But I was only going one way, occifer." *hic*
Mono is not compiled as a Windows app. It does use WineLib for providing certain APIs for Windows.Forms. Using WineLib is no different than using GTK+ - they're both just APIs/libraries. Mono *is* working on Windows.Forms, using several different backends - WineLib, Cairo and GTK+. I believe the Cairo one is what they plan on using "officially" when complete. DotGNU and Mono can and do share code/assemblies, btw, so if DotGNU does indeed have a WinForms assembly, Mono should (theoretically) be capable of just using that.
...
On a side note, I just love how posts (like the parent) which are half-guessed speculation and mostly false manage to get "+5 Informative"
Honestly, just get some friends together on a LAN and play. It's more entertaining than playing with a mass of immature idiots online anyhow. ;-)
It'll also give you the opportunity to build up those skills to get good enough to compete with the losers^wpros who spend all their time playing FPS games.
You're confusing Open Source with Free Software. Free Software licenses protects the code from being "stolen" and used in a non-Free product. Open Source licenses merely let users who have the source do what they will with it (with varying restrictions).
AweMUD (my main projects) for example is Open Source to the core, and I fully support anyone wishing to use it in a non-Open/non-Free project. If AweMUD were Free Software, then that wouldn't be possible. (Without getting the code under a second license from me and all the AweMUD contributors.)
Don't forget patents. NVidia can't release code for things like S3TC and other patented algorithms, but several games/apps require these to work properly.
:(
Sure, one could blame the game developers for requiring patented code, but when you get to the people who want to just use their computers (like me), it all comes down to "does the damn thing work or not?"
On a completely different note, it's a bit sad how (some) kernel developers want to purposefully hard for binary only drivers. Even if drivers have source available, that's *still* a pain for users. What happens when the API changes? (Like it manages to do even in stable series.) Sure, the vendor GPL'd the driver, the driver is probably in some future kernel version the user doesn't have, and the driver on the disk/CD that came with the hardware doesn't work with the user's kernel. Upgrading kernels can be a nightmare (especially when you end up with an update that breaks something which previously worked; also a bit too common).
API and ABI compatibility has many more benefits than just allowing proprietary drivers. Too many developers don't seem to see them tho.
The ad's line "We're still going to download music for free" is in regards to the iTunes give-away. i.e., those who earn the points/prizes from Pepsi's promotion get to grab a limited number of songs off iTunes for free, with Pepsi footing the bill paying the artists/labels.
Shrink by not shrinking? ;-)
These systems don't look bad for business or casual use, and probably also good enough for development use, but the gamer in me likes the XPC systems a lot better.
Dictionary is your friend:
Joke, n. L. jocus. Cf Jeopardy, Jocular, Juggler.
- In joke, in jest; sportively; not meant seriously.
Must've been running BSD.
;-)
*ducks*
It's my sword arm, I swear!
Just use bochs or another VM.
Aaaah. OK, now I see, sorry. I get off on the wrong tanget *waay* too often. ~,^
Unfortunately, it doesn't work that way. You can't compile and get just the extra registers. You have to take it all, which includes changes to things size changes of certain data types. The software will likely need modifications for this if the developers never intended to run on non-32-bit systems.
"The men and women who play the stock market on a regular basis are no fools"
;-)
Right... explain to use the dot-com era then, eh?
Stock market history is filled with investors who had absolutely no idea what they were doing, because the companies or technologies they invested in were either entirely made of lies or simply not what the investors hoped it would be. These are, after all, stock market investors, and not technologists or lawyers who actually understand what they're investing in - just the press releases and marketing geared towards them.
Granted, it's entirely possible SCO does have some secret trump card. I'm doubting it, but it does still seem a bit foolish to write them off entirely until they are completely gone.
Likely, vendors will only ship one version of their app, the 32-bit version, since AMD64 CPUs can run 32-bit and 64-bit. If the app doesn't need or greatly benefit from 64-bit, why bother with it? (The code will likely need porting to 64-bit anyway, especially by average Windows programmers who've never had to worry about different CPU architectures before.)
Apps that greatly benefit from 64-bit support may either be 64-bit only, or provide both versions. I recall reading that the UT developers plan on requiring 64-bit mode for their next-gen game content development tools, for example.
Generally, it'll have to do with the market. If an app can get away with a 32-bit version, it will have one, since most people will still have 32-bit CPUs in the forseeable future. Apps that can really get a boost from 64-bit will have the extra money put into developing a 64-bit version in hopes that it will sell more copies that way.
I believe the "-" was meant as a separator, like how one would say mid-range.
You mean like the Itanium? ;-)
*ducks*
I quit cold turkey several months ago. Sure, I got slight headaches a bit for about a week after, but ever since, no problem. No blinding headaches, no severe grumpiness (well, technically I was grouchy ass even when I was drinking an eight pack of MD every day, and I'm no better now, but I didn't get any *worse* either). Was I just lucky that I could go from such an extreme amount of caffiene everyday to none with no major problems or side affects?
(For a note, I do drink caffiene again, but in very slight moderation, simply because even with caffiene I'm dead in the morning. I drink one bottle of either MD or Bawls in the morning when I first get into work, and nother but water the rest of the day. This is after about 4 months of no caffiene at all, tho.)
Switch my phone carriet just last weekend, actually. Much better, and much cheaper, service now, plus I have a nice new phone with features my old providor didn't support. And I still get to keep my very fun number. (Which I won't post here for obvious reasons. It is comprised of a rather interesting pattern of numbers, tho, very easy to remember, and I always get strange looks, like, "you're kidding," when I tell people my cell number.)
"Then there are problems with USB devices, and others that, being narrowed down, comes down to problems on the APIC interface [slashdot.org]. From what I've heard so far, it doesn't look stable, so why ship it on linux 2.6?"
Because a huge number of modern machines *require* ACPI in order to operate properly. my machine at work (Compaq Evo) requires it to reboot properly, my laptop can't be on for more than a few minutes without it, my home-built desktop machine needs it for a few things, etc.
Distributors or knowledgable users who know ACPI won't work for them and/or don't care about loss of features or inability to run on a wide-range of machines can just disable ACPI, so it shouldn't be that big of a deal.