That's a Novell Linux ad, I might note, if that lends any more credibility to the omen.;-)
(My favorite Novell Linux ad has got to be the one about Worm: What a butterfly really is without the pretty wings. [you can see the MSN butterfly in the background just after all the servers crash in the ad.])
Windows does not have a spatial interface, never has, and likely never will. Spatial doesn't mean "opens files in new windows" which is the extend of the Windows behaviour people label "spatial."
Spatial works, and only works, because it's *spatial*. Which means that you can visualize locations and objects based on their relationships to other objects.
The classic spatial example is driving. There are probably tons of places you go on a daily basis on which you have no idea what the road names are. Or, if you do, you at least don't think about them while driving. Many people give directions that don't say things like "turn left on Elm" but instead things like "drive into town, turn left at the corner with the brown building, drive a couple hundred feet, etc."
Another example is a filing cabinent. (Closer to the computer folder/file metaphor.) I can tell someone where the records for my company's taxes are. The name of the drawer, the name of the folder. When I look for that folder though, I don't scan the cabinent for the drawer name, I don't filter through the folders one by one. I go straight to the third drawer, go straight to three fourths of the way back, look for the clump of red folders, and pull out the first one. I know the location of the proper draw in relation to the cabinet itself and the other drawers, and the know the location of the folder in relation to the folders around it. That's spatial.
And the great thing about the spatial Nautilus mode is that it works both spatially *and* navigationally! You can open a folder, scan through the list of folders and files in it, and make a choice based on a known path or set of directions. On the other hand, if you are already familiar with the file, you can navigate to it without so much as reading a single label/name, because all the items are in the same places, each folder opens in the same spot on your desktop, etc. You can remember where to click based on the location of the window and icons therein in relation to each other.
And just as the article states, your clutter argument is crack. Middle click or shift-click will close the parent window while opening the new, so there is absolutely no reason for your desktop to be cluttered other than you being unaware of the feature. Now that you are, that argument is invalid.;-)
I know at least in the GNOME camp there is constant work on improving performance, and especially in reducing memory usage.
One thing you have to realize is that most users _want_ their desktop to do more. There's a reason only a small fraction of users still use TWM; it doesn't do what they want it to. And, if you want more features, you have to realize that it will require more resources.
That said, there is a lot of code out there that was written first to Just Work(tm) with little thought of performance. Good practice indicates that, while you should keep performance in mind, real optimization and fine tuning should be done last.
Current work for performance improvements in GNOME including sharing data between processes (say, icon themes), reducing system calls and X requests during startup, and general speed improvements in the various library calls used to make the applications actually work.
More help is _always_ appreciated. There are several Plans of Attack available from GNOME developers who know what needs to be done but don't have the time. If you want to help implement those the other developers and users will be quite thankful.
a) Are you sure it's the same HTML/stylesheet/etc? Some broken sites try to alter their content for the user agent.
b) It could be that the stylesheet is broken and ASSumes the fonts and sizes being used are the Windows defaults, and not the Linux values you're using.
No, see, there has to be actual competition between the two, reason for a group to use one over the other, etc. Mozilla vs Konquerer isn't like Vi vs Emacs, it's like Vi vs ed.
I don't know about the rest of you, but I think nature is pretty swell. Forests are beautiful. Some of the best places on our planet.
'that the best thing for IBM to do would be to print out every single version as requested and send the resultant 20 tonnes or so of paper to SCO. That would keep them quiet for a while'.
Do we _really_ need to encourage wholesale destruction of every tree on our planet for something so incredibly stupid as the assholes at SCO? Seriously, can't you just electronically send all that code? DVDs or something? Just a small handful of them would be all that's needed, if you need more than one at all.
Now, I'm not going to even start discussing whether the product *should* have a backdoor. There are many reasons for including them, and many obvious reasons to not.
What I want to know is, why bother with user names and passwords in the backdoor? An SSH tunnel using only public key authentication would pretty much solve the problem of someone examining the firmware for the login information. You could also include multiple keys and provide a public key revokation server that the units automatically update from, as well as a general key update server that the units will grab new keys from using a callback mechanism (to guarantee that the key update servers have a valid private key for connecting to the unit).
OpenBSD for one is likely to change. They were one of the biggest opponents of the new XFree86 license.
The reasoning for why the new license sucks has absolutely nothing to do with the GPL, despite the uninformed ramblings of the Slashdot crowd. It has to do with practicality. The new XFree86 license is almost impossible to follow depending on your interpretation. The license itself is unclear, and instead of fixing the wording, XFree86 leaders have just made informal statements on mailing lists regarding their own personal interpretation.
The new license is impractical because it requires that attribution to be given to the XFree86 developers wherever any other attribution is given to another party. OpenBSD's complaint was with CD covers. Say you put a "Artwork provided by Foo Bob" on the CD insert. Now, according to some interpretations of the XFree86 license (and these are valid interpretations, because the license wording is very ambiguous and vague) you'd also have to put there in the same font size and prominance, "X Window system provided by XFree86, Inc." Then, if a contributor adds some stuff to the project under the same license, you have to add their name as well. And the next contributor. And so on. Pretty soon you run out of space to put all of these. There's also potential for the license to "spread" as people lift code, resulting a wide variety of apps with hundreds if not thousands of authors that have this incredibly stupid licensing stipulation.
The XFree86 developers have stated that the above scenario is not their intention. But what they say doesn't matter much, because the above is pretty much exactly what the license text implies.
The package revision is 0.1mdk. That means it is not yet the first real release of the package, but a pre-release. The changelog also clearly indicates it is a CVS copy of GCC. Once GCC 3.4.1 is officially out, and the package has been stabilized, the package release will become 1, and increase as other changes/improvements are made to the package.
Why in all the nine hells would including Mozilla, a Web Browser, allow them to get rid of Nautilus, a File Manager?
BTW, GNOME already depends on Mozilla. It's one of the requirements for Epiphany, which is included in the Desktop package set. Mozilla is _not_ defined as part of the Platform (developer packages) because Mozilla constantly breaks API/ABI, making it impossible to develop an application on top of it and expect it to actually Just Work(tm). Mozilla may move into the Platform once the GRE is out and stable.
The Roadmap, if you actually read it, states that the Mozilla work is in regards to cooperation with the Firefox developers, as the development goals of Firefox and Epiphany are pretty close, except Epiphany is all GTK/GNOME while Firefox uses that unfortunate cross platform hack.
And yes, cross paltform UIs are hacks. You either end up with Mozilla/Firefox, where the app looks like an alien everywhere, or OOo, where the app looks native on Windows and like an alient everywhere else. A far better strategy is something like Abiword where there is a single core and multiple frontends targetted at specific platforms, or something like the Mozilla GRE where the Mozilla core is provided for easy deployment of multiple platform specific front ends (like Epiphany or Camino).
SPF seems to be an IP-address-based whitelist mechanism. Which means that every possible host which might be serving as an MTA needs to be listed in my whitelist.
SPF provides a bit more flexibility than that. You should perhaps actually read the whole spec.
That's all well and good for a home or office user, but what about when you travel and you're stuck sending mail from, say, the hotel's port 25-filtered network which requires that you use their SMTP server?
Use your company's non-port 25 SMTP service, use your company's webmail service, and/or tell the hotel operator to suck it. Sure, you may be stopped in this theoretical case, but so are the spammers and scammers, which is the whole point. Any SPF-using company that has remote users will of course understand this problem and work around it as suggested. An ISP I use has port 25 blocked. I just send mail over port 10025 to a special relay that requires authentication. That relay is included in my SPF records.
(The inclusion mechanism instructs recipients to use the relay's SPF records, so they can update/modify their relay's configuration and my mail will just continute to work flawlessly with no changes needed to my own SPF records.)
And what happens when someone just uses that SPF record to see which systems will relay email for my domain and then just uses that server to send out lots of spam which looks like it originates from me, and then even worse is "proven" to be authentic?
The same thing that happens when a spammer uses any open relay - everybody suffers. SPF doesn't help when an MTA administrator is a moron and opens the relay. Any MTA you add to your SPF accepted list should be a well run MTA that only relays for specific hosts or requires authentication before relaying. This is something that should be done independent of SPF usage.
Please read the bazillion posts on this thread about SRS. If you have a server running SPF then you also are likely running SRS. Any mail forwarding service should likewise support SRS. With either SRS/SPF or DomainKeys, you need software upgrades, and SRS/SPF are a lot simpler to implement. (Very small patches or plugins for existing MTAs and a whopping 1 tiny line in DNS for each domain.)
The button ordering is not because of left-to-right reading. As you tried to explain, that doesn't make much sense anyhow.
The truth is, it is just easier to *spatially* find the buttons. Yes, that spatial stuff again. As with spatial Nautilus, human minds are in fact very, very good at managing spatial locations. Ars Technica in its Spatial Finder write up noted that even an expert programmer's ability to comprehend paths and abstract concepts is entirely dwarved by even a child's spatial recognition and manipulation ability.
With the buttons on the right of the dialog (which is how every well design OS/app works, independent of how the buttons are ordered) you are always able to spatially locate the button group in relation to the dialog itself. Just look in the bottom right corner, and there you have them. (The right alignment may be due to the fact that we read left-to-right, and thus our eyes find it easier to look in the bottom right after reading the text above.)
The reasoning for using Cancel/Action (*not* OK - there is never an OK button in properly designed GNOME apps. Explained below.) is just an extension of that same design/layout that even KDE and Windows use. Finding things is easier using spatial locations. Finding the button group as a whole is easy because its in the bottom right corner. Putting the main action button in the very bottom right thus makes it even easier to find. This has been tested, extensively, by both GNOME engineers (Sun and Ximians folks; both do a lot of usability testing) and the Apple folks, who do things the same way for similar reasons.
Regarding the OK buttons, it's just a matter of usefulness and safety. "OK" is 100% meaningless. OK what, exactly? The same thing with Yes/No: yes what, no what? You can change the meaning of OK/Cancel in any dialog you see, and the only way to tell the different is to read the whole text (which is often poorly written itself). By avoiding the term OK, and using the actual action the button does (Save, Quit, etc) you remove ambiguity. It increases safety, as well; say you usually see dialog A when doing some task, in which the OK button does what you need. Then after an upgrade, or maybe after some data corruption you're unware of, dialog B pops up instead. Due to habit, you don't even read the text, you just click OK. But oops, this OK did something else, something you didn't want to happen. Or maybe you expected something to happen (like saving) that didn't, but you have no idea it didn't happen. By labelling the buttons something other than OK, it's much less likely you'll just click the button and not notice something is different. Your eyes look directly at the button to aim for clicking, unlike the dialog text which you just skip over out of habit. If the button text changes, you'll notice. Cancel is also better defined in the GNOME/Apple HIGs. Cancel only shows up in dialogs caused by user action. Cancel does nothing other than cancel that action. No other side effects.
First off, how the hell do you call this crap a review? It mentions one specific feature and is incredibly infactual in doing so. All it does is even _mention_ the feature, then bitch and bitch about all of GNOME sucks with no factual examples. The only examples given are outright lies. (For example, the reason you can't edit colors in the GUI is because nobody's bothered to write an editor for it yet. If someone submitted a patch, it would be a most welcome feature.)
This article is complete trash. The first paragraph alone makes that rather clear, and the past articles by the same author also make it clear. This guy takes every chance he gets to insult GNOME.
The development series of Evolution has Groupwise support. Another interview from a few days ago also stated that a Windows version of Evolution is in the works. So the GroupWise client for Linux and a free one for Windows are on the way.
Knowing algorithms is pretty useless if you don't know how to code them, or write nightmarish code that can't be understood, can't be maintained, can't be debugged, and can't be marke... well, OK, so it could be sold, but still.;-)
And to be honest, with most languages, knowing algorithms isn't half that important, because the runtime takes care of it for you. Only if you're coding in low-level languages does it become important to know who to write an efficient search algorithm.
And it's those very low-level languages in which I'd want to see AP results for any employees. A coder who can write a very efficient hash table but doesn't understand how C "strings" work or who thinks MFC is the paragon of design is a coder I'd rather see shot than hired.
First, is GTK#, that (along with bindings to all others Gnome Libs) will allow you to quickly develop a linux application using an API just like windows.form but with GTK widgets.
GTK# is nothing like Windows.Forms. It's like C GTK+. The idea of GTK# isn't to allow porting Windows apps easily to GTK#, the idea is to allow writing new applications with a good, solid, intelligently designed toolkit.
GTK# also is not just a Linux solution. GTK+ runs on Windows, X11, and many other graphics architectures, and GTK# works with any of those. You can develop an app in GTK# intended only for Windows, if you feel the API for GTK# is friendlier and more usable than Windows.Forms. (Which wouldn't surprise me. ~,^ )
They are shipping both CLS and Microsoft compatible implementations. The basic idea is that new applications for Linux can use CLS plus the Mono stack (i.e., UNIX/Linux intended assemblies, like gtk-sharp, various DB libraries, POSIX wrappers, etc) and legacy or cross-platform apps can use the Microsoft stack (Windows.*, ASP.NET, ADO.NET, etc).
For example, a GNOME app written in C# for Mono would not use the Microsoft stack at all. So even if Microsoft broke/changed/patented the Microsoft (non-ECMA) stack, that would have zero effect on the tons of Open Source/Free Software apps developed using the ECMA and Mono assemblies. Thus, Mono provides both a great set of languages (C# and anything else that can run on the CLR), a good solid runtime (Mono+CLR stacks), an efficient and cross platform interpreter and JIT/AOT compilers, and so on.
The only thing Microsoft can kill is Microsoft compatibility. Which really isn't all that interesting to most FOSS developers.;-)
Erm, they _do_ work on speed. Each release of OS X has been faster than the previous, with Jaguar being a rather big leap for many users in terms of speed.
Many of the "bloat features" Apple adds are also quite important or useful. Things like fast user switching are good for security, for example. Other UI improvements just plain out make the OS more usable. And OS X could use plenty more of those improvements.;-)
While I appreciate the "just works" part of OS X, I honestly find GNOME and even [yuck] KDE to be much cleaner, saner, and easier to manage than OS X. OS X has a lot of very bad UI decisions in it that I'm hoping will get cleaned up in future releases. Like grouping windows based on process; 100% useless and counter-intuitive. Users and our work are based on tasks, not processes. Maybe one of my browser windows has content regarding the development project going on in my terminal window while another browser window has some information I'm discussing with a friend on iChat. Grouping the windows by process makes it much more difficult to get work done; either don't group at all, or allow users to group by task (be it by virtual desktops or some other mechanism).
Slashdot Mirror
That's a Novell Linux ad, I might note, if that lends any more credibility to the omen. ;-)
(My favorite Novell Linux ad has got to be the one about Worm: What a butterfly really is without the pretty wings. [you can see the MSN butterfly in the background just after all the servers crash in the ad.])
Also cue the spelling zealots!
P.S. SPF is the answer!
Windows does not have a spatial interface, never has, and likely never will. Spatial doesn't mean "opens files in new windows" which is the extend of the Windows behaviour people label "spatial."
;-)
Spatial works, and only works, because it's *spatial*. Which means that you can visualize locations and objects based on their relationships to other objects.
The classic spatial example is driving. There are probably tons of places you go on a daily basis on which you have no idea what the road names are. Or, if you do, you at least don't think about them while driving. Many people give directions that don't say things like "turn left on Elm" but instead things like "drive into town, turn left at the corner with the brown building, drive a couple hundred feet, etc."
Another example is a filing cabinent. (Closer to the computer folder/file metaphor.) I can tell someone where the records for my company's taxes are. The name of the drawer, the name of the folder. When I look for that folder though, I don't scan the cabinent for the drawer name, I don't filter through the folders one by one. I go straight to the third drawer, go straight to three fourths of the way back, look for the clump of red folders, and pull out the first one. I know the location of the proper draw in relation to the cabinet itself and the other drawers, and the know the location of the folder in relation to the folders around it. That's spatial.
And the great thing about the spatial Nautilus mode is that it works both spatially *and* navigationally! You can open a folder, scan through the list of folders and files in it, and make a choice based on a known path or set of directions. On the other hand, if you are already familiar with the file, you can navigate to it without so much as reading a single label/name, because all the items are in the same places, each folder opens in the same spot on your desktop, etc. You can remember where to click based on the location of the window and icons therein in relation to each other.
And just as the article states, your clutter argument is crack. Middle click or shift-click will close the parent window while opening the new, so there is absolutely no reason for your desktop to be cluttered other than you being unaware of the feature. Now that you are, that argument is invalid.
I know at least in the GNOME camp there is constant work on improving performance, and especially in reducing memory usage.
One thing you have to realize is that most users _want_ their desktop to do more. There's a reason only a small fraction of users still use TWM; it doesn't do what they want it to. And, if you want more features, you have to realize that it will require more resources.
That said, there is a lot of code out there that was written first to Just Work(tm) with little thought of performance. Good practice indicates that, while you should keep performance in mind, real optimization and fine tuning should be done last.
Current work for performance improvements in GNOME including sharing data between processes (say, icon themes), reducing system calls and X requests during startup, and general speed improvements in the various library calls used to make the applications actually work.
More help is _always_ appreciated. There are several Plans of Attack available from GNOME developers who know what needs to be done but don't have the time. If you want to help implement those the other developers and users will be quite thankful.
Mine would be, "I really need to find the bathroom!"
http://www.vanvonhunter.com/vvh43.html
a) Are you sure it's the same HTML/stylesheet/etc? Some broken sites try to alter their content for the user agent.
b) It could be that the stylesheet is broken and ASSumes the fonts and sizes being used are the Windows defaults, and not the Linux values you're using.
c) Blame it on Canada.
No, see, there has to be actual competition between the two, reason for a group to use one over the other, etc. Mozilla vs Konquerer isn't like Vi vs Emacs, it's like Vi vs ed.
(Note: tongue firmly in cheek.)
I don't know about the rest of you, but I think nature is pretty swell. Forests are beautiful. Some of the best places on our planet.
'that the best thing for IBM to do would be to print out every single version as requested and send the resultant 20 tonnes or so of paper to SCO. That would keep them quiet for a while'.
Do we _really_ need to encourage wholesale destruction of every tree on our planet for something so incredibly stupid as the assholes at SCO? Seriously, can't you just electronically send all that code? DVDs or something? Just a small handful of them would be all that's needed, if you need more than one at all.
Now, I'm not going to even start discussing whether the product *should* have a backdoor. There are many reasons for including them, and many obvious reasons to not.
What I want to know is, why bother with user names and passwords in the backdoor? An SSH tunnel using only public key authentication would pretty much solve the problem of someone examining the firmware for the login information. You could also include multiple keys and provide a public key revokation server that the units automatically update from, as well as a general key update server that the units will grab new keys from using a callback mechanism (to guarantee that the key update servers have a valid private key for connecting to the unit).
OpenBSD for one is likely to change. They were one of the biggest opponents of the new XFree86 license.
The reasoning for why the new license sucks has absolutely nothing to do with the GPL, despite the uninformed ramblings of the Slashdot crowd. It has to do with practicality. The new XFree86 license is almost impossible to follow depending on your interpretation. The license itself is unclear, and instead of fixing the wording, XFree86 leaders have just made informal statements on mailing lists regarding their own personal interpretation.
The new license is impractical because it requires that attribution to be given to the XFree86 developers wherever any other attribution is given to another party. OpenBSD's complaint was with CD covers. Say you put a "Artwork provided by Foo Bob" on the CD insert. Now, according to some interpretations of the XFree86 license (and these are valid interpretations, because the license wording is very ambiguous and vague) you'd also have to put there in the same font size and prominance, "X Window system provided by XFree86, Inc." Then, if a contributor adds some stuff to the project under the same license, you have to add their name as well. And the next contributor. And so on. Pretty soon you run out of space to put all of these. There's also potential for the license to "spread" as people lift code, resulting a wide variety of apps with hundreds if not thousands of authors that have this incredibly stupid licensing stipulation.
The XFree86 developers have stated that the above scenario is not their intention. But what they say doesn't matter much, because the above is pretty much exactly what the license text implies.
The package revision is 0.1mdk. That means it is not yet the first real release of the package, but a pre-release. The changelog also clearly indicates it is a CVS copy of GCC. Once GCC 3.4.1 is officially out, and the package has been stabilized, the package release will become 1, and increase as other changes/improvements are made to the package.
Why in all the nine hells would including Mozilla, a Web Browser, allow them to get rid of Nautilus, a File Manager?
BTW, GNOME already depends on Mozilla. It's one of the requirements for Epiphany, which is included in the Desktop package set. Mozilla is _not_ defined as part of the Platform (developer packages) because Mozilla constantly breaks API/ABI, making it impossible to develop an application on top of it and expect it to actually Just Work(tm). Mozilla may move into the Platform once the GRE is out and stable.
The Roadmap, if you actually read it, states that the Mozilla work is in regards to cooperation with the Firefox developers, as the development goals of Firefox and Epiphany are pretty close, except Epiphany is all GTK/GNOME while Firefox uses that unfortunate cross platform hack.
And yes, cross paltform UIs are hacks. You either end up with Mozilla/Firefox, where the app looks like an alien everywhere, or OOo, where the app looks native on Windows and like an alient everywhere else. A far better strategy is something like Abiword where there is a single core and multiple frontends targetted at specific platforms, or something like the Mozilla GRE where the Mozilla core is provided for easy deployment of multiple platform specific front ends (like Epiphany or Camino).
See, a Viking Funeral!
[insert mourning vikings]
See, Hitler on Ice!
[insert Hitler on, well, ice]
See, Jews... In... Space...!!
[just picture it]
SPF seems to be an IP-address-based whitelist mechanism. Which means that every possible host which might be serving as an MTA needs to be listed in my whitelist.
SPF provides a bit more flexibility than that. You should perhaps actually read the whole spec.
That's all well and good for a home or office user, but what about when you travel and you're stuck sending mail from, say, the hotel's port 25-filtered network which requires that you use their SMTP server?
Use your company's non-port 25 SMTP service, use your company's webmail service, and/or tell the hotel operator to suck it. Sure, you may be stopped in this theoretical case, but so are the spammers and scammers, which is the whole point. Any SPF-using company that has remote users will of course understand this problem and work around it as suggested. An ISP I use has port 25 blocked. I just send mail over port 10025 to a special relay that requires authentication. That relay is included in my SPF records.
(The inclusion mechanism instructs recipients to use the relay's SPF records, so they can update/modify their relay's configuration and my mail will just continute to work flawlessly with no changes needed to my own SPF records.)
And what happens when someone just uses that SPF record to see which systems will relay email for my domain and then just uses that server to send out lots of spam which looks like it originates from me, and then even worse is "proven" to be authentic?
The same thing that happens when a spammer uses any open relay - everybody suffers. SPF doesn't help when an MTA administrator is a moron and opens the relay. Any MTA you add to your SPF accepted list should be a well run MTA that only relays for specific hosts or requires authentication before relaying. This is something that should be done independent of SPF usage.
Please read the bazillion posts on this thread about SRS. If you have a server running SPF then you also are likely running SRS. Any mail forwarding service should likewise support SRS. With either SRS/SPF or DomainKeys, you need software upgrades, and SRS/SPF are a lot simpler to implement. (Very small patches or plugins for existing MTAs and a whopping 1 tiny line in DNS for each domain.)
http://spfproxy.com
Just add the DNS record as instructed, change your MX, and get free SPF protection.
The button ordering is not because of left-to-right reading. As you tried to explain, that doesn't make much sense anyhow.
The truth is, it is just easier to *spatially* find the buttons. Yes, that spatial stuff again. As with spatial Nautilus, human minds are in fact very, very good at managing spatial locations. Ars Technica in its Spatial Finder write up noted that even an expert programmer's ability to comprehend paths and abstract concepts is entirely dwarved by even a child's spatial recognition and manipulation ability.
With the buttons on the right of the dialog (which is how every well design OS/app works, independent of how the buttons are ordered) you are always able to spatially locate the button group in relation to the dialog itself. Just look in the bottom right corner, and there you have them. (The right alignment may be due to the fact that we read left-to-right, and thus our eyes find it easier to look in the bottom right after reading the text above.)
The reasoning for using Cancel/Action (*not* OK - there is never an OK button in properly designed GNOME apps. Explained below.) is just an extension of that same design/layout that even KDE and Windows use. Finding things is easier using spatial locations. Finding the button group as a whole is easy because its in the bottom right corner. Putting the main action button in the very bottom right thus makes it even easier to find. This has been tested, extensively, by both GNOME engineers (Sun and Ximians folks; both do a lot of usability testing) and the Apple folks, who do things the same way for similar reasons.
Regarding the OK buttons, it's just a matter of usefulness and safety. "OK" is 100% meaningless. OK what, exactly? The same thing with Yes/No: yes what, no what? You can change the meaning of OK/Cancel in any dialog you see, and the only way to tell the different is to read the whole text (which is often poorly written itself). By avoiding the term OK, and using the actual action the button does (Save, Quit, etc) you remove ambiguity. It increases safety, as well; say you usually see dialog A when doing some task, in which the OK button does what you need. Then after an upgrade, or maybe after some data corruption you're unware of, dialog B pops up instead. Due to habit, you don't even read the text, you just click OK. But oops, this OK did something else, something you didn't want to happen. Or maybe you expected something to happen (like saving) that didn't, but you have no idea it didn't happen. By labelling the buttons something other than OK, it's much less likely you'll just click the button and not notice something is different. Your eyes look directly at the button to aim for clicking, unlike the dialog text which you just skip over out of habit. If the button text changes, you'll notice. Cancel is also better defined in the GNOME/Apple HIGs. Cancel only shows up in dialogs caused by user action. Cancel does nothing other than cancel that action. No other side effects.
First off, how the hell do you call this crap a review? It mentions one specific feature and is incredibly infactual in doing so. All it does is even _mention_ the feature, then bitch and bitch about all of GNOME sucks with no factual examples. The only examples given are outright lies. (For example, the reason you can't edit colors in the GUI is because nobody's bothered to write an editor for it yet. If someone submitted a patch, it would be a most welcome feature.)
This article is complete trash. The first paragraph alone makes that rather clear, and the past articles by the same author also make it clear. This guy takes every chance he gets to insult GNOME.
Here's a public response by one of the ArsTechnica folks.
Bull. Linus is still very active in the actual coding. Look through the patches and see how many have him listed as the author.
The development series of Evolution has Groupwise support. Another interview from a few days ago also stated that a Windows version of Evolution is in the works. So the GroupWise client for Linux and a free one for Windows are on the way.
Stick a few electrical nodes outside, shock the shit out of the bear, eventually it'll learn not to sit on you.
Knowing algorithms is pretty useless if you don't know how to code them, or write nightmarish code that can't be understood, can't be maintained, can't be debugged, and can't be marke... well, OK, so it could be sold, but still. ;-)
And to be honest, with most languages, knowing algorithms isn't half that important, because the runtime takes care of it for you. Only if you're coding in low-level languages does it become important to know who to write an efficient search algorithm.
And it's those very low-level languages in which I'd want to see AP results for any employees. A coder who can write a very efficient hash table but doesn't understand how C "strings" work or who thinks MFC is the paragon of design is a coder I'd rather see shot than hired.
First, is GTK#, that (along with bindings to all others Gnome Libs) will allow you to quickly develop a linux application using an API just like windows.form but with GTK widgets.
GTK# is nothing like Windows.Forms. It's like C GTK+. The idea of GTK# isn't to allow porting Windows apps easily to GTK#, the idea is to allow writing new applications with a good, solid, intelligently designed toolkit.
GTK# also is not just a Linux solution. GTK+ runs on Windows, X11, and many other graphics architectures, and GTK# works with any of those. You can develop an app in GTK# intended only for Windows, if you feel the API for GTK# is friendlier and more usable than Windows.Forms. (Which wouldn't surprise me. ~,^ )
They are shipping both CLS and Microsoft compatible implementations. The basic idea is that new applications for Linux can use CLS plus the Mono stack (i.e., UNIX/Linux intended assemblies, like gtk-sharp, various DB libraries, POSIX wrappers, etc) and legacy or cross-platform apps can use the Microsoft stack (Windows.*, ASP.NET, ADO.NET, etc).
;-)
For example, a GNOME app written in C# for Mono would not use the Microsoft stack at all. So even if Microsoft broke/changed/patented the Microsoft (non-ECMA) stack, that would have zero effect on the tons of Open Source/Free Software apps developed using the ECMA and Mono assemblies. Thus, Mono provides both a great set of languages (C# and anything else that can run on the CLR), a good solid runtime (Mono+CLR stacks), an efficient and cross platform interpreter and JIT/AOT compilers, and so on.
The only thing Microsoft can kill is Microsoft compatibility. Which really isn't all that interesting to most FOSS developers.
Erm, they _do_ work on speed. Each release of OS X has been faster than the previous, with Jaguar being a rather big leap for many users in terms of speed.
;-)
Many of the "bloat features" Apple adds are also quite important or useful. Things like fast user switching are good for security, for example. Other UI improvements just plain out make the OS more usable. And OS X could use plenty more of those improvements.
While I appreciate the "just works" part of OS X, I honestly find GNOME and even [yuck] KDE to be much cleaner, saner, and easier to manage than OS X. OS X has a lot of very bad UI decisions in it that I'm hoping will get cleaned up in future releases. Like grouping windows based on process; 100% useless and counter-intuitive. Users and our work are based on tasks, not processes. Maybe one of my browser windows has content regarding the development project going on in my terminal window while another browser window has some information I'm discussing with a friend on iChat. Grouping the windows by process makes it much more difficult to get work done; either don't group at all, or allow users to group by task (be it by virtual desktops or some other mechanism).