extending Windows to capture the font rendering calls on the screen and then piping the text to a file?
It seems to me that these schemes are fundamentally flawed, since by presenting the material to the eyes of the reader in readable form, the material is decoded and can be captured somehow. Either in the software underlying the application, or worst case with digital camera and OCR.
You forget the hundreds of billions of dollars that exist in the DoD budget every year. They can easily afford to hire software staffs larger than Microsoft's and write entire operating systems on custom designed exotic hardware without ever releasing it. They can also afford to hire great mathematical and CS minds and bind them with classified information laws which prevent revealing anything on threat of imprisonment. You underestimate the resources at our military's disposal.
Software engineering is different because it is still more art than science. You either "see it" or you don't, and it's very fragile. No good painting, and no good software, was done by committee. It may be copied by committee (i.e. Microsoft's "innovation" techniques) but not originated by committee. You can't "manage" it with any canned techniques like this article proposes yet again and expect results. _You have to find what works for your people!_ If you experience turnover you may have to change to a whole new environment!
Software engineering is different because you are doing a different job every time. All the effort goes into writing it. Making an unlimited number of copies is easy. You don't learn one set of tasks and repeat to produce more units, you solve a problem every day and move on to something different the next day. This can be fun but also stressful on the brain. This is why measurement is difficult, and management is difficult, and predictability and project scheduling are difficult. The process of writing software is forever a moving target, and completely unique to each project.
You know, if two programmers producted a market cap of $30 billion, who gets all the stock?
Yes! Assuming biometrics would never be spoofed is a dangerous assumption.
The old standby of "something you have and something you know", like your ATM card and your PIN number, provides great security and quick handling of any stolen information. With DNA identification, if a malicious person gets a hair sample from you and publishes your gene info on the internet for the purposes of identity theft, you can't just change your genetic makeup for a new one.
Aren't parents now required by the IRS to get an SSN for their children before their 1st birthday? I think at this point everyone in the US _is_ required to have an SSN, even before they can talk.
Maybe you can get around it if you don't have any income taxes or something.
If you want to write proprietary code against Qt, buy a license from Troll Tech. Seems like fair licensing to me, more fair than LGPL in that respect.
Re:A good argument, misses the point
on
Is UNIX An OS?
·
· Score: 1
OK, you win. I used to think the kernel by itself was the OS, but then I realized a shell was so useful that it HAD to be part of the OS. But hey, what's an OS without an ls or a grep or a ps?? So I decided that those were definitely part of the OS. etc., etc., etc... now I'm convinced, all 1 GB of software that comes with Red Hat is really all just one OS, right?
You make a good point about the changing perspectives from CS to consumer and the accompanying changes in definitions. But are "purists" really going to care about the widely accepted definition of the term "operating system"? If anybody cares they should write an RFC or make a proposal to the IEEE with a precise definition of the phrase for all people and all times, amen. I think the real point here is that the lines are blurred, and also that it doesn't really matter where the line is, except maybe where it helps marketing your "OS" product. In the end, it doesn't affect any code, right? It's hot air.
Re:Definitions and Motivations
on
Is UNIX An OS?
·
· Score: 1
This is pretty much a marketing article with little real meaning to anybody but your average consumeroid because it feeds him some "facts" to debate platform superiority with his friends.
The author is trying to be a Webster redefining CS terminology, and also to make an emotional appeal that OS-X is much more than Unix.
So what? Some people in the early '90's used to loudly argue that DOS was an OS and Win3.1 was an "operating environment". Who cares now? Last I heard an OS was all about providing/controlling access to hardware in some simplified fashion, but there are so many freakin' layers between applications and the basest kernel or libc routines that this comes down to which layers do you personally draw the line at between OS and app library.
Give a precise definition of operating system to your taste, and someone can tell you if a given piece of code falls under your definition or not. Is it all free software or not: that's a more interesting question.
For Dell to talk about PC markets and not about OS merits is The Way It Ought To Be. He's the best kind of business man: he's not bullshitting us to get sales. His product is a Linux compatible hardware platform, not Linux.
Free markets are a good thing; and market driven businesses like Dell are ideal in a free market. Technology-driven as opposed to market-driven businesses tend to fail anyway, for the simple reason they aren't always concerned about offering what people want to fork their money over for.
I agree completely with this philosophy that components are a good thing. Yet generally in the details of a proposed/implemented component architecture there is something dissatisfying about it. Here's what could be learned from the Unix command line in the component world.
The lack of policy in Unix piping has been a good thing for the long-term survival of the architecture. Policies in an architecture naturally gravitate towards one class of problems, i.e. providing a consistent GUI for embedding GUI controls and document display components. To me, most interesting Unix programs are the ones you _can't_ see. Sorters, searchers, counters, manipulators, etc. before the printf() ever happens. Daemons, protocol stacks, moving a stream of bits from point A to point B. The universal "everything is a stream of bits" model is very powerful and universally applicable to nearly any computer problem, including the UI and configuration issues. It allows Unix to be a bridge between TCP/IP and SMB and Appletalk and Netware and DECnet with no integration programs required. Which leads to my second point:
Where's the component analog to the command line? Why do I have to be a programmer to use the Bonobo components? Here is opportunity to leap beyond COM and create something new and powerful. I can easily tie unrelated Unix "components" together with pipes at the shell.
Here's a crazy idea... what about having some kind of component-aware kernel and shell for interactive use? And what about the possibility of building applications through application definition file(s) in the component shell? I'm talking next generation shell scripts, connecting CORBA components together instead of regular open/read/write/close programs. Is Bonobo universal enough to give the user this kind of power? For example, in the component realm, can I pipe XML through a content-aware sorter and through an XML-HTML converter and then into a browser component on demand? Can I quickly add a context-aware word count to it? Can I modify my mail deamon and quickly remove or install a SPAM filter component from the inbound mail pipeline? If you could provide interactive component reuse to the non-programmer, you'd have something far beyond COM.
I think the GPL is often misinterpreted to say that source code must always be available to everyone in the world who wants it, and since that's not reasonable at certain times there are loopholes. My understanding is that it doesn't in fact say that. What it does say is that each executable or object must be distributed with source, or a written offer of source.
If you read the GPL section 3, it gives you 3 options a, b, and c to comply with the distribution requirement. If you meet option a, you don't have to distribute source to any 3rd parties as required by options b or c, the written offer options.
I quote the GPL preamble:
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
So you have to give program recipients the same rights to source as you have, but you don't have to give non-recipients _anything_. Hypothetically Red Hat could take down their anonymous FTP servers and distribute only on CD-ROM's in boxes, so long as a copy of the source accompanied each binary or was available at a nominal charge (like magtape days of old), and their customers have full GPL rights. If a company modifies a GPL program strictly for internal use, then the source must be available internally, but not necessarily externally if they don't distribute the program externally. Limited "beta" programs by software companies are allowed, so long as at least the limited "beta" participants are provided with source on request and have full GPL rights.
I don't see where GPL is all that unclear about distributions. It can be looked at on a person by person basis. If you give a GPL software program to a person for any purpose, you must give that same person a copy of the source, either immediately or on his request, and a statement of his GPL rights, but you are not required to do anything for anybody else. Seems pretty tight to me.
And that exposes yet more ways MS keeps the advantage. Like you said they can take internal shortcuts and use bad design, but also they can release enhanced DLL's or even NEW DLL's for the underlying system with an application release. Their exclusive knowledge and control of Windows internals gives them an advantage to do this.
If Corel wanted feature X in Windows to use in WordPerfect, say a rainbow scrolling title bar, they don't have the option to add that to the GDI in Windows, but if Microsoft wanted this for Office they could walk over to the GDI department and get it added, then release a new version of GDI on the Office CD; still preventing WordPerfect from having it because you've got to buy Office first. Big advantage. And they don't have to document the new API until later or not at all: it's not part of a Windows release.
These techniques I'm sure have been used many times in the past.
Competing with your app on top of somebody else's closed software platform is a losing proposition, API documentation or not. You're OK until the platform vendor decides he wants to make his own version of your app. The best you can hope for then is to be bought out or allowed to survive, otherwise you'll be fighting for your life as he uses the platform, which he owns and you don't, to his advantage.
Slashdot Mirror
Who wants the government making laws about movie release schedules?
extending Windows to capture the font rendering calls on the screen and then piping the text to a file?
It seems to me that these schemes are fundamentally flawed, since by presenting the material to the eyes of the reader in readable form, the material is decoded and can be captured somehow. Either in the software underlying the application, or worst case with digital camera and OCR.
You forget the hundreds of billions of dollars that exist in the DoD budget every year. They can easily afford to hire software staffs larger than Microsoft's and write entire operating systems on custom designed exotic hardware without ever releasing it. They can also afford to hire great mathematical and CS minds and bind them with classified information laws which prevent revealing anything on threat of imprisonment. You underestimate the resources at our military's disposal.
Software engineering is different.
Software engineering is different because it is still more art than science. You either "see it" or you don't, and it's very fragile. No good painting, and no good software, was done by committee. It may be copied by committee (i.e. Microsoft's "innovation" techniques) but not originated by committee. You can't "manage" it with any canned techniques like this article proposes yet again and expect results. _You have to find what works for your people!_ If you experience turnover you may have to change to a whole new environment!
Software engineering is different because you are doing a different job every time. All the effort goes into writing it. Making an unlimited number of copies is easy. You don't learn one set of tasks and repeat to produce more units, you solve a problem every day and move on to something different the next day. This can be fun but also stressful on the brain. This is why measurement is difficult, and management is difficult, and predictability and project scheduling are difficult. The process of writing software is forever a moving target, and completely unique to each project.
You know, if two programmers producted a market cap of $30 billion, who gets all the stock?
Yes! Assuming biometrics would never be spoofed is a dangerous assumption.
The old standby of "something you have and something you know", like your ATM card and your PIN number, provides great security and quick handling of any stolen information. With DNA identification, if a malicious person gets a hair sample from you and publishes your gene info on the internet for the purposes of identity theft, you can't just change your genetic makeup for a new one.
Aren't parents now required by the IRS to get an SSN for their children before their 1st birthday? I think at this point everyone in the US _is_ required to have an SSN, even before they can talk.
Maybe you can get around it if you don't have any income taxes or something.
If you want to write proprietary code against Qt, buy a license from Troll Tech. Seems like fair licensing to me, more fair than LGPL in that respect.
OK, you win. I used to think the kernel by itself was the OS, but then I realized a shell was so useful that it HAD to be part of the OS. But hey, what's an OS without an ls or a grep or a ps?? So I decided that those were definitely part of the OS. etc., etc., etc... now I'm convinced, all 1 GB of software that comes with Red Hat is really all just one OS, right?
You make a good point about the changing perspectives from CS to consumer and the accompanying changes in definitions. But are "purists" really going to care about the widely accepted definition of the term "operating system"? If anybody cares they should write an RFC or make a proposal to the IEEE with a precise definition of the phrase for all people and all times, amen. I think the real point here is that the lines are blurred, and also that it doesn't really matter where the line is, except maybe where it helps marketing your "OS" product. In the end, it doesn't affect any code, right? It's hot air.
This is pretty much a marketing article with little real meaning to anybody but your average consumeroid because it feeds him some "facts" to debate platform superiority with his friends.
The author is trying to be a Webster redefining CS terminology, and also to make an emotional appeal that OS-X is much more than Unix.
So what? Some people in the early '90's used to loudly argue that DOS was an OS and Win3.1 was an "operating environment". Who cares now? Last I heard an OS was all about providing/controlling access to hardware in some simplified fashion, but there are so many freakin' layers between applications and the basest kernel or libc routines that this comes down to which layers do you personally draw the line at between OS and app library.
Give a precise definition of operating system to your taste, and someone can tell you if a given piece of code falls under your definition or not. Is it all free software or not: that's a more interesting question.
For Dell to talk about PC markets and not about OS merits is The Way It Ought To Be. He's the best kind of business man: he's not bullshitting us to get sales. His product is a Linux compatible hardware platform, not Linux.
Free markets are a good thing; and market driven businesses like Dell are ideal in a free market. Technology-driven as opposed to market-driven businesses tend to fail anyway, for the simple reason they aren't always concerned about offering what people want to fork their money over for.
I agree completely with this philosophy that components are a good thing. Yet generally in the details of a proposed/implemented component architecture there is something dissatisfying about it. Here's what could be learned from the Unix command line in the component world.
The lack of policy in Unix piping has been a good thing for the long-term survival of the architecture. Policies in an architecture naturally gravitate towards one class of problems, i.e. providing a consistent GUI for embedding GUI controls and document display components. To me, most interesting Unix programs are the ones you _can't_ see. Sorters, searchers, counters, manipulators, etc. before the printf() ever happens. Daemons, protocol stacks, moving a stream of bits from point A to point B. The universal "everything is a stream of bits" model is very powerful and universally applicable to nearly any computer problem, including the UI and configuration issues. It allows Unix to be a bridge between TCP/IP and SMB and Appletalk and Netware and DECnet with no integration programs required. Which leads to my second point:
Where's the component analog to the command line? Why do I have to be a programmer to use the Bonobo components? Here is opportunity to leap beyond COM and create something new and powerful. I can easily tie unrelated Unix "components" together with pipes at the shell.
Here's a crazy idea... what about having some kind of component-aware kernel and shell for interactive use? And what about the possibility of building applications through application definition file(s) in the component shell? I'm talking next generation shell scripts, connecting CORBA components together instead of regular open/read/write/close programs. Is Bonobo universal enough to give the user this kind of power? For example, in the component realm, can I pipe XML through a content-aware sorter and through an XML-HTML converter and then into a browser component on demand? Can I quickly add a context-aware word count to it? Can I modify my mail deamon and quickly remove or install a SPAM filter component from the inbound mail pipeline? If you could provide interactive component reuse to the non-programmer, you'd have something far beyond COM.
I think the GPL is often misinterpreted to say that source code must always be available to everyone in the world who wants it, and since that's not reasonable at certain times there are loopholes. My understanding is that it doesn't in fact say that. What it does say is that each executable or object must be distributed with source, or a written offer of source.
If you read the GPL section 3, it gives you 3 options a, b, and c to comply with the distribution requirement. If you meet option a, you don't have to distribute source to any 3rd parties as required by options b or c, the written offer options.
I quote the GPL preamble:
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
So you have to give program recipients the same rights to source as you have, but you don't have to give non-recipients _anything_. Hypothetically Red Hat could take down their anonymous FTP servers and distribute only on CD-ROM's in boxes, so long as a copy of the source accompanied each binary or was available at a nominal charge (like magtape days of old), and their customers have full GPL rights. If a company modifies a GPL program strictly for internal use, then the source must be available internally, but not necessarily externally if they don't distribute the program externally. Limited "beta" programs by software companies are allowed, so long as at least the limited "beta" participants are provided with source on request and have full GPL rights.
I don't see where GPL is all that unclear about distributions. It can be looked at on a person by person basis. If you give a GPL software program to a person for any purpose, you must give that same person a copy of the source, either immediately or on his request, and a statement of his GPL rights, but you are not required to do anything for anybody else. Seems pretty tight to me.
And that exposes yet more ways MS keeps the advantage. Like you said they can take internal shortcuts and use bad design, but also they can release enhanced DLL's or even NEW DLL's for the underlying system with an application release. Their exclusive knowledge and control of Windows internals gives them an advantage to do this.
If Corel wanted feature X in Windows to use in WordPerfect, say a rainbow scrolling title bar, they don't have the option to add that to the GDI in Windows, but if Microsoft wanted this for Office they could walk over to the GDI department and get it added, then release a new version of GDI on the Office CD; still preventing WordPerfect from having it because you've got to buy Office first. Big advantage. And they don't have to document the new API until later or not at all: it's not part of a Windows release.
These techniques I'm sure have been used many times in the past.
Competing with your app on top of somebody else's closed software platform is a losing proposition, API documentation or not. You're OK until the platform vendor decides he wants to make his own version of your app. The best you can hope for then is to be bought out or allowed to survive, otherwise you'll be fighting for your life as he uses the platform, which he owns and you don't, to his advantage.
Thank God for free software.