It's the lawyers. Laywers aren't in the business of selling a product, all they know how to do is create problems. Really. Find your own problems before the other guys does to keep him from suing you, and find his before he does so you can sue him. It isn't about productivity, it's about extortion. Some lawyers will still consider the productivity benefits of serving their clients, corporate lawyers have lost even that small incentive to be business smart.
A lawyer doesn't think in terms of right or wrong, good or evil, ethical or unethical. They think in terms of the costs of going to court. If the costs of getting sued is less than the benefits of violating your copyright or patent, they will do so. Conversely, if the costs of suing you into bankruptcy are sufficiently high, they won't sue you.
The reason Microsoft is acting like a bunch of spoiled children is because they have too many lawyers working for them.
Tiny correction. The license is per developer, not per seat.
As for your overall post, I agree. They're not going to turn down hard currency. But that notice in the FAQ is there for a reason. They can still refuse to do business with you, especially if you're being a dick about it.
The point is, spending an hour to save ten dollars is silly. It doesn't matter if you're a business owner or not. If you're that concerned about the ten dollars, there are thousands of other things you can do in less time to save or make the same amount.
What if you could save eleven dollars with two hours of research? Or save twelve dollars with four hours of research? Heck, you might even save one hundred dollars if you took the whole week off!
It is enforcable, by virtue of the fact that Trolltech doesn't have to sell you a proprietary license. You have to buy the licenses direct from Trolltech, and if they think you've been cheating to avoid the license costs, they're going to tell you to take a flying leap through a rolling donut.
If you have made an honest mistake, then tell them you goofed. Trolltech is quite flexible. I'm sure they'll sell you licenses for developers that worked on your project in the past.
One of the execs at Trolltech explained this a couple of years ago. Proprietary Qt is licensed per developer. Without this requirement, a company could put twenty developers on a project using GPL/QPL Qt, then a day before release to the public, purchase a proprietary license for the buildmaster, thus avoiding having to purchase nineteen licenses.
That's the rationale. Now here's the good news: If you've written a real-world Open Source software application using GPL/QPL Qt, and now want to offer a proprietary version of it, simply ask. Trolltech isn't going to say "no" to honest developers with cash in hand.
The STL may have been around that long, but ubiquitous and working implementations have not. At work I have to use a ten year old GCC (gnupro 96r1) and its STL implementation is horrible. That's just one example. Even the immediate prior release to the current VisualStudio doesn't have it right.
When you're a cross-platform/cross-compiler toolkit, you're forced to make due with the lowest common denominator.
As a FreeBSD user who has had SATA support for at least two years, what's the big deal with the separate driver under Linux? Isn't there a unified ATA driver that covers both PATA and SATA? To me, a separate SATA driver sounds as odd as having a separate EIDE driver.
There's no problem with drag and drop. But there's a problem when you combine drag and drop with holding down various different key combinations to get to the drag and drop to do what you want.
It's context help, and is used in many desktops, not just Windows. The icon only appears when the window can make use of it. Usually this is when the window is a dialog. KDE is one example. If the window sets the context help flag (it's a standard X11 WM hint), then the window titlebar will have that icon, and the appropriate message sent to the application when it is used. Right now as I type this my Konqueror window has this icon and it's fully functional.
I hate to be the one to defend software patents, because I really despise them, but in this case, as in most others, it's the infringing company that's getting hurt, and not "the people".
p.s. Of course, the people are getting hurt indirectly, as they are thus deprived of a choice in the marketplace.
Of course it's a silly example. It's taking the opposing proposition to the extreme to make the point.
Realistically, how many actions can you perform with a document icon? If it's a folder icon, how many actions will it have? How many will device icons like the trash can and DVD drive have? An executable? A zipped file? Etc, etc.
I'm guessing there will be about actions common to all icons (open/run, cut, copy, rename, trash or delete, and view properties). Then there are actions specific to only some icon types, like compress (for a normal file), play (for a CD icon), empty (for the trash), eject (for any removable media icon), etc. Overall I would say a dozen unique actions are available. Since you shouldn't overload the gesture semantics because it makes it harder to learn and remember, these will all require equally unique gestures.
Assuming a one button mouse (to please the Mac people), counting click, doubleclick and drag-drop as separate actions, and with four meta keys to use, we end up with twelve possible gestures. It's sufficient, but just barely. But the PROBLEM is remembering those gestures. There are twelve gestures to remember. People already have problems remembering with button does what with a two button mouse, imagine them trying to remember twelve different things. They will need a cheat sheet, because after all, we've completely removed the context menu because it's user unfriendly.
Tell me about it. I did an SVG icon recently for an app of mine. It looked great at 48x48. But when I went to create bitmaps for the Mac OSX icon (which required a greater range of resolutions), I discovered that what looks good at 48x48 often looks like crap at 16x16, and fugly at 128x128. The problem is that when you scale an SVG image, everything scales, including the line widths. I had to manually tweak each resolution by hand.
Why would you need so many resolutions? Why can't everything be 128x128? Because that same icon is going to be used as the app icon in the folder or destkop, a smaller size if the folder is in a columnar view mode, as a quick launch icon on the panel, and as a mini icon in the titlebar or task manager. You will also have the rude heretic users who will change the GNOME defaults.
I understand what you're saying, but the "gestural paradigm" doesn't work when you have lots of available actions. Some of them are fine. But to do everything with some sort of gesture, you're going to end up with dozens of keys to press while dragging. You can't remember them all. Alt+P+drag equals print, Alt+Y+drop equals compress, Shift+Alt+M equals upgrade the package the icon came from, etc, etc. What if you do Alt+P+drag on a binary executable? Does it print out the splash screen?
That's why there are context menus. The most common items can remain gestures (copy, delete), but you're going to have to put actions in a context menu, especially if they are not universal to the object being manipulated.
Drag-and-drop and other gestural interfaces are far more obvious.
Nonsense. The only reason it seems that way is because so many people have prior experience with other desktops. There are no analogues in real life to holding down a key while dragging. Some people may stick their tongues out while trying to thread a needle, but that's an individual behavioral quirk, and not a universal instinct applicatble to the computer desktop.
The look very closely follows the original NEXTstep look. It looks ugly now, but at the time it was the best look out there. What could you do with only an eight bit color palette? Contemporary styles in the computing world were at the time were Motif, Win30, and classic Mac, which came nowhere close to NEXT in the looks department.
I've got a NEXT style for KDE called NEWstep which you may want to use when you feel in the retro mood.
Don't laugh. A few years ago I changed a login system to use s/key style keys to aide in memorization. To refresh your memories, s/key would take a 56 bit key and mutate into a string of six short English words. It used an internal dictionary of thousands of words. One week after I checked in the code a software tester came to me with a red embarassed face. The very first phrase the system generated for him started with the words "klan kills coon..." That one got moved all the way up to a mandatory must fix bug.
Why? Seriously, why? Is it merely because more people are apt to sit on their butts getting fat watching spectator sports than they are to sit on their butts getting fat reading email?...she won't want to play with your Jibba-Jabba anymore.
But she will if you have cute little footballs all over your shorts? Who would have thunk it!
Google it. Unit tests are automated white box tests typically written at the same time the code is written. They don't test the program as a whole, but test the functions and objects within the program.
When the program is finished you end up with a complete automated test suite. It won't be an integration test, that's still a separate task. But it's going to catch a heck of a lot more errors than if you sit in front of the program for five minutes manually fiddling with it.
Put "test" targets in your make files, and make them part of your nightly builds. Do you perform a complete comprehensive low level test of your code every time you check something in? No you don't. But a suite of unit tests can.
The key is to write you unit tests at the SAME TIME as you write your productive code. If you wait till later you'll forget some of the boundaries.
Comparing kernel development to military generals is quite a stretch. The analogy falls down at every point. War is a race against time and resources, so that quick and flexible generals win. Deperate times call for desperate men. But kernel development should NOT be done by desperate men.
We need real-time scheduling support, POSIX real-time extensions, and thread-safe libraries.
That would be AWESOME. NetBSD is already great for embedded, but with the addition of real time we can finally get rid of the hegemony of proprietary RTOS vendors. My company was using an RT Unix, but the royalties were just too great and we had to abandon it for... WinXPe + INtime. Aaargh! NetBSD was actually evaluated for this, but it had to be abandoned due to the lack of RT.
I must be using a different STL than you, because I can index off the end of a vector without any memory errors. Of course, if I don't manually check this, my program isn't going to be running the way I expect it to, but that's hardly a problem limited to C++. Even the sacred Java and C# don't prevent this.
There is no way that anyone could inject code in java written server programs and execute it, unless the java programs' purpose is explicitly to load classes and run them.
The exploits you are talking about have NOTHING to do with the language, and everything to do with the run time environment.
The interoperability of open source software is astounding. I'm running KDE on FreeBSD and Windowmaker on Solaris. I hear they both work under Linux. That's true interoperability.
Slashdot Mirror
It's the lawyers. Laywers aren't in the business of selling a product, all they know how to do is create problems. Really. Find your own problems before the other guys does to keep him from suing you, and find his before he does so you can sue him. It isn't about productivity, it's about extortion. Some lawyers will still consider the productivity benefits of serving their clients, corporate lawyers have lost even that small incentive to be business smart.
A lawyer doesn't think in terms of right or wrong, good or evil, ethical or unethical. They think in terms of the costs of going to court. If the costs of getting sued is less than the benefits of violating your copyright or patent, they will do so. Conversely, if the costs of suing you into bankruptcy are sufficiently high, they won't sue you.
The reason Microsoft is acting like a bunch of spoiled children is because they have too many lawyers working for them.
...you have pay per seat anyway...
Tiny correction. The license is per developer, not per seat.
As for your overall post, I agree. They're not going to turn down hard currency. But that notice in the FAQ is there for a reason. They can still refuse to do business with you, especially if you're being a dick about it.
The point is, spending an hour to save ten dollars is silly. It doesn't matter if you're a business owner or not. If you're that concerned about the ten dollars, there are thousands of other things you can do in less time to save or make the same amount.
What if you could save eleven dollars with two hours of research? Or save twelve dollars with four hours of research? Heck, you might even save one hundred dollars if you took the whole week off!
It is enforcable, by virtue of the fact that Trolltech doesn't have to sell you a proprietary license. You have to buy the licenses direct from Trolltech, and if they think you've been cheating to avoid the license costs, they're going to tell you to take a flying leap through a rolling donut.
If you have made an honest mistake, then tell them you goofed. Trolltech is quite flexible. I'm sure they'll sell you licenses for developers that worked on your project in the past.
One of the execs at Trolltech explained this a couple of years ago. Proprietary Qt is licensed per developer. Without this requirement, a company could put twenty developers on a project using GPL/QPL Qt, then a day before release to the public, purchase a proprietary license for the buildmaster, thus avoiding having to purchase nineteen licenses.
That's the rationale. Now here's the good news: If you've written a real-world Open Source software application using GPL/QPL Qt, and now want to offer a proprietary version of it, simply ask. Trolltech isn't going to say "no" to honest developers with cash in hand.
The STL may have been around that long, but ubiquitous and working implementations have not. At work I have to use a ten year old GCC (gnupro 96r1) and its STL implementation is horrible. That's just one example. Even the immediate prior release to the current VisualStudio doesn't have it right.
When you're a cross-platform/cross-compiler toolkit, you're forced to make due with the lowest common denominator.
As a FreeBSD user who has had SATA support for at least two years, what's the big deal with the separate driver under Linux? Isn't there a unified ATA driver that covers both PATA and SATA? To me, a separate SATA driver sounds as odd as having a separate EIDE driver.
There's no problem with drag and drop. But there's a problem when you combine drag and drop with holding down various different key combinations to get to the drag and drop to do what you want.
It's context help, and is used in many desktops, not just Windows. The icon only appears when the window can make use of it. Usually this is when the window is a dialog. KDE is one example. If the window sets the context help flag (it's a standard X11 WM hint), then the window titlebar will have that icon, and the appropriate message sent to the application when it is used. Right now as I type this my Konqueror window has this icon and it's fully functional.
I hate to be the one to defend software patents, because I really despise them, but in this case, as in most others, it's the infringing company that's getting hurt, and not "the people".
p.s. Of course, the people are getting hurt indirectly, as they are thus deprived of a choice in the marketplace.
Of course it's a silly example. It's taking the opposing proposition to the extreme to make the point.
Realistically, how many actions can you perform with a document icon? If it's a folder icon, how many actions will it have? How many will device icons like the trash can and DVD drive have? An executable? A zipped file? Etc, etc.
I'm guessing there will be about actions common to all icons (open/run, cut, copy, rename, trash or delete, and view properties). Then there are actions specific to only some icon types, like compress (for a normal file), play (for a CD icon), empty (for the trash), eject (for any removable media icon), etc. Overall I would say a dozen unique actions are available. Since you shouldn't overload the gesture semantics because it makes it harder to learn and remember, these will all require equally unique gestures.
Assuming a one button mouse (to please the Mac people), counting click, doubleclick and drag-drop as separate actions, and with four meta keys to use, we end up with twelve possible gestures. It's sufficient, but just barely. But the PROBLEM is remembering those gestures. There are twelve gestures to remember. People already have problems remembering with button does what with a two button mouse, imagine them trying to remember twelve different things. They will need a cheat sheet, because after all, we've completely removed the context menu because it's user unfriendly.
Tell me about it. I did an SVG icon recently for an app of mine. It looked great at 48x48. But when I went to create bitmaps for the Mac OSX icon (which required a greater range of resolutions), I discovered that what looks good at 48x48 often looks like crap at 16x16, and fugly at 128x128. The problem is that when you scale an SVG image, everything scales, including the line widths. I had to manually tweak each resolution by hand.
Why would you need so many resolutions? Why can't everything be 128x128? Because that same icon is going to be used as the app icon in the folder or destkop, a smaller size if the folder is in a columnar view mode, as a quick launch icon on the panel, and as a mini icon in the titlebar or task manager. You will also have the rude heretic users who will change the GNOME defaults.
I understand what you're saying, but the "gestural paradigm" doesn't work when you have lots of available actions. Some of them are fine. But to do everything with some sort of gesture, you're going to end up with dozens of keys to press while dragging. You can't remember them all. Alt+P+drag equals print, Alt+Y+drop equals compress, Shift+Alt+M equals upgrade the package the icon came from, etc, etc. What if you do Alt+P+drag on a binary executable? Does it print out the splash screen?
That's why there are context menus. The most common items can remain gestures (copy, delete), but you're going to have to put actions in a context menu, especially if they are not universal to the object being manipulated.
Drag-and-drop and other gestural interfaces are far more obvious.
Nonsense. The only reason it seems that way is because so many people have prior experience with other desktops. There are no analogues in real life to holding down a key while dragging. Some people may stick their tongues out while trying to thread a needle, but that's an individual behavioral quirk, and not a universal instinct applicatble to the computer desktop.
That ain't the way I Hurd it!
</joke>
The look very closely follows the original NEXTstep look. It looks ugly now, but at the time it was the best look out there. What could you do with only an eight bit color palette? Contemporary styles in the computing world were at the time were Motif, Win30, and classic Mac, which came nowhere close to NEXT in the looks department.
I've got a NEXT style for KDE called NEWstep which you may want to use when you feel in the retro mood.
Don't laugh. A few years ago I changed a login system to use s/key style keys to aide in memorization. To refresh your memories, s/key would take a 56 bit key and mutate into a string of six short English words. It used an internal dictionary of thousands of words. One week after I checked in the code a software tester came to me with a red embarassed face. The very first phrase the system generated for him started with the words "klan kills coon ..." That one got moved all the way up to a mandatory must fix bug.
Clothing and athleticism complement one another.
...she won't want to play with your Jibba-Jabba anymore.
Why? Seriously, why? Is it merely because more people are apt to sit on their butts getting fat watching spectator sports than they are to sit on their butts getting fat reading email?
But she will if you have cute little footballs all over your shorts? Who would have thunk it!
Google it. Unit tests are automated white box tests typically written at the same time the code is written. They don't test the program as a whole, but test the functions and objects within the program.
When the program is finished you end up with a complete automated test suite. It won't be an integration test, that's still a separate task. But it's going to catch a heck of a lot more errors than if you sit in front of the program for five minutes manually fiddling with it.
Put "test" targets in your make files, and make them part of your nightly builds. Do you perform a complete comprehensive low level test of your code every time you check something in? No you don't. But a suite of unit tests can.
The key is to write you unit tests at the SAME TIME as you write your productive code. If you wait till later you'll forget some of the boundaries.
They still haven't forked off 2.7? You're kidding me!
Comparing kernel development to military generals is quite a stretch. The analogy falls down at every point. War is a race against time and resources, so that quick and flexible generals win. Deperate times call for desperate men. But kernel development should NOT be done by desperate men.
We need real-time scheduling support, POSIX real-time extensions, and thread-safe libraries.
That would be AWESOME. NetBSD is already great for embedded, but with the addition of real time we can finally get rid of the hegemony of proprietary RTOS vendors. My company was using an RT Unix, but the royalties were just too great and we had to abandon it for... WinXPe + INtime. Aaargh! NetBSD was actually evaluated for this, but it had to be abandoned due to the lack of RT.
I must be using a different STL than you, because I can index off the end of a vector without any memory errors. Of course, if I don't manually check this, my program isn't going to be running the way I expect it to, but that's hardly a problem limited to C++. Even the sacred Java and C# don't prevent this.
There is no way that anyone could inject code in java written server programs and execute it, unless the java programs' purpose is explicitly to load classes and run them.
The exploits you are talking about have NOTHING to do with the language, and everything to do with the run time environment.
What makes an athletic company any more suitable for a shirt than an OS?
The interoperability of open source software is astounding. I'm running KDE on FreeBSD and Windowmaker on Solaris. I hear they both work under Linux. That's true interoperability.