You're just arguing over microsoft's interpretation of the word integration.
Yes I am, which is one of the major issues in this lawsuit. What does it mean to integrate components? Microsoft supporters seem to feel integration takes place once a component starts using another component. DOJ supporters feel that integration only takes place when the two components become largely inseparable.
To put it another way, Microsoft seems to be saying that integration is a one-way street. Even if a particular component can be used by any number of third-party applications, once that component is used by a "core" part of the operating system, that part is integrated. Keeping with the car analogy, it's like saying that once the battery is used by the car stereo, the battery and stereo are integrated components. To remove IE means removing the parts of Windows that use IE, much like removing the car stereo would mean removing the battery as well.
DOJ supporters believe that it is a two-way street. Integration means that two components depend on each other for the correct functioning, and that neither can exist alone. In this view, while IE the application may not work properly without IE the component, IE the component can - and does - exist separately from IE the application, much like a car stereo may not work correctly without a battery, but the battery can work and function properly without being connected to a car stereo. If
Furthermore, the two components must actually be used by each other. It might be possible to build a car stereo into a car battery, but if the car stereo doesn't use the battery, I wouldn't call the two components integrated. Similarly, putting the IE component code into the code for DirectX, the GDI, or the TCP/IP subsystem does not make the code "integrated" unless the DirectX, GDI, or TCP/IP code actually utilizes the functionality that the IE code provides.
Microsoft has publicly said that all software components (especially microsoft ones) are made up of smaller components.
And when they said that, they were correct. However, the same could be said for literally anything. My Lego X-Wing fighter at home is also made up of smaller components; does that mean that the Lego bricks are integrated? My computer is made up of a video card, processor, memory, monitor, keyboard, mouse - does that mean all of those components are integrated with each other? (If so, how do you explain the ability to upgrade components without replacing the entire system?)
Windows could work perfectly well without TCP/IP, a GUI, etc. But it wouldn't be as useful. Integration doesn't mean that it won't work without it.
Ah, but now you're playing the shell game by moving the shell with the pea under it. Now, instead of defining integration technologically, we're defining it by its utility.
Integration by utility, in the view of the author of the PDF, can only be justified by offering concrete, clear examples of what is specifically more useful for the two specific programs combined. Many of the advantages that Microsoft offered as rationale for the integration - a single installer, a single point of support, a single source of documentation - are not necessarily exclusive to the IE/Windows combination, nor are they necessarily exclusive to "integrated" components. Two standalone components can be installed with one installer, have one combined source of documentation, and a single point of support. Another useful result of the combination is not having to download the browser - but that too is disingenuous, as that is not really a result of the combination of IE and Windows as it is simply the ability to put the component DLLs on the CD at press time. The benefits - the enhanced utility - for the specific combination of the two must go above and beyond what would be provided if the two components were supplied separately, and at the same revision level (it's easy to say that the "integrated" Windows 98 offers improved functionality over the non-integrated Windows 95 - but how much of that improved functionality/utility is provided simply by the enhancements made in Windows 98?)
So now you have to offer me a list of the benefits of an "integrated" IE and Windows versus a non-integrated IE and Windows, at the same revision level for both programs, minus the subset of benefits that are common to any combined set of programs shipped from the same source.
That is small indeed, my friend, and not a single one immediately springs to mind. --
They can't do that? The APIs to IE are published so 3rd parties can use these DLLs, just like they would GDI, or COM.
Oh, they can do that all they like. In fact, APIs are necessary to program for Windows.
What I'm saying is that there is a difference between integrating technologies and simply shipping some standalone DLLs.
Removing IE from windows, whether you call it integrated or a dependency still cripples windows and windows applications.
Not exactly. As a dependency, it means that the component can be replaced. If I manufacture a component that conforms to the API - in this case, a component that looks like IE from an interface standpoint - then I can replace IE and Windows is none the wiser.
If IE were truly integrated, I would be absolutely unable to do that. Not only would the removal break the system, but I could not substitute my own components without major, major effort.
Microsoft has touted IE as a component for other developers to use, which means that the IE user interface, Explorer, and every other application which uses the IE component is accessing the API. As a result, Microsoft implicitly admits that IE is a component, and thus replaceable, and thus their claims that it is a true integration are simply wrong.
Microsoft added HTML display functionality to the Windows API so any third-party application could use it.
Not really. What Microsoft did was simply to add an extra few DLLs onto each Windows CD and then write their applications to take advantage of the capabilities of the DLLs.
Quicken (for example) doesn't want to say "this only works if you've installed IE as your choice of browsers", they want Quicken to run on Windows as it comes out of the box.
So? I seem to recall numerous products - including Microsoft's own products - that checked to see if you had a specific version of IE and upgraded you to that version if you didn't, in order to run/use a particular program (the one that immediately springs to mind is Visual Studio).
This doesn't prove that Windows and IE are integrated, only that there are benefits from having certain components (in this case, the HTML rendering DLLs) with the operating system.
If this is your particular definition of rendering, then it becomes trivial for anybody with a CD burner to integrate components with Microsoft Windows. Copy a Windows 98SE CD to your hard disk, add a Netscape install directory, and reburn. Voila! Netscape has, more or less, just been integrated with Windows 98.
Taking IE out of Windows would break this functionality.
Yes, it would. But that doesn't necessarily mean the two are integrated, any more than my car and my tires are integrated. If I take the tires off my car, my car doesn't move - therefore my car and tires are integrated components?
The flaw in your argument is that you are confusing dependency with integration. Simply because a component relies on another component does not make the two components integrated. It simply establishes a dependency. My car depends on tires, and won't work without them, but clearly my tires and car are not integrated (or you'd have to scrap your car the first time you had a flat tire). Similarly, Windows depends on IE and may not work without it, but that doesn't mean Windows and IE are integrated.
What Windows requires is a component that offers a specific interface, just like my car requires the standard tire interface for a tire. Any HTML renderer or tire, respectively, will work as long as it conforms to the API in use (which may or may not be the same as the published API). That no other HTML renderer has been written that conforms to the API IE uses in no way mitigates the fact that Windows is dependent on, but not integrated with, IE.
Microsoft was correct with this claim. I'm surprised by the number of Slashdot readers that don't seem to comprehend this.
Microsoft was wrong with this claim. I'm rather surprised at the number of Slashdot readers who can't seem to comprehend the distinction between dependency and integration.
Third, Mr. Hollaar has apparently forgotten that he became acquainted with the source code of Microsoft's operating systems in the Caldera and Bristol cases pursuant to protective orders that strictly prohibit him from using that knowledge for any purpose other than preparing his testimony in those cases.
I read the entire PDF file, and frankly I can't see one instance where Mr. Hollaar has used his knowledge of the source code to support any of his arguments. In fact, it seems the only place he mentions source code - beyond the time when he admits that he has seen it - is when he is advocating reviewing the source code to see whether it was simply mixed with some other code to enforce a product combination at compile time.
As I understand it, and please correct me if I am mistaken, in Linux only the Kernel is considered the OS, and everything else is software.
Roughly.
The Linux kernel is the heart of the system, but you can't run on the kernel alone. There is a subset of software which is considered required for a Linux system to work correctly, and which could therefore be considered part of the operating system.
I'm not experienced enough with Linux to be able to say specifically which pieces of software are necessary, and how much software is included depends on the definition of "work." Does "work" mean "a user can log in and manipulate files"? If so, that means everything up to, and including, a shell and a text editor. If you simply define "work" as "can boot, but errors are acceptable" then the subset becomes a great deal smaller.
Microsoft should be allowed to add new features to their products.
And here we come to the crux of the problem.
I don't think anybody here disagrees with you about Microsoft adding features to their products.
I think the disagreement is whether combining two products together can accurately be called a feature, especially when the technological benefits of combining the two are rather skimpy. As the PDF points out, many of the benefits Microsoft claims as benefits aren't really exclusive to the IE/Windows combination, but the result of what happens if you combine any two programs (for instance, one installer and one source of support, small code base and/or fewer modules to load into memory).
The test is really whether there is any benefit provided by a combined version of IE and Windows that you could not get by simply installing IE on top of Windows.
My personal opinion is no. After having used Internet Explorer 4.0 installed on top of Windows 95 (the original version, which did not come with a version of IE), and subsequently having used versions of Windows 95 and 98 with IE integrated, I honestly could not find any real difference between the two. A non-integrated IE worked as well for me as an integrated IE did. Given that Microsoft provided numerous benefits for the combination, but almost none that applied exclusively as to how the functioning of IE/Windows was improved by the combination of the two programs, I must therefore conclude that Microsoft had no real technological reason for combining the two programs.
Since they had no technological reason to combine them, but they went ahead anyways, Microsoft must have had some other motive for combining the programs. --
Of course, that would require the original poster to read the man pages. Horrors.
*chuckle*
As the second person to reply to my comment points out, though, there's no easy way to downgrade the entire distribution.
On the other hand, if all you have are a handful of bad packages, then the dpkg option is all you need. Realistically, if I do "upgrade" to unstable, am I really going to have much more than a handful or two "bad" packages which will require going back to the original version?
Gee, that's vague. I wonder if this bill contains any definitions for the words "sophisticated" and "intricate" so as to make that description meaningful.
Nah. That way, they can simply twist the words to mean anything they want!
Who pays for all the time and money I waste sitting at red lights or stalled traffic on the freeway?
Red lights? Traffic? What are those?
According to the actions of my fellow drivers, that's what gas pedals and breakdown lanes, respectively, are for. Why wait for a red light to change when you can storm through it a full ten seconds after it's turned red? Why sit in traffic when you can zoom down a breakdown lane going at least ten miles over the speed limit?
The problem with turning off Javascript is that some sites use Javascript legitimately.
What would be nice is a more advanced mechanism for handling Javascript, such as a global on/off option and a list for specifying which sites shouldn't be processed by that filter. That allows the user a lot of flexibility; they can turn off all Javascript except for those sites where it is absolutely needed, or can leave Javascript on except for the few sites that they find to be too much of a hassle to navigate with it enabled.
Really, when I step back and look at it objectively, I don't know who is right; It's a tough issue.
You're right, it is a tough issue. I'm not sure I entirely believe that I should be able to own said design.
But I think there's a strong argument to be made that having intellectual property - when intellectual property is used/supported/organized correctly - actually does foster innovation. Although I don't have a link or reference handy, I do recall reading something a few months ago that basically said it is a historical fact that countries with IP protection have a faster technology growth rate than those that don't. So, in some sense, having IP fosters innovation.
The problem we have today is that IP is becoming less about protecting a specific invention or idea as it is about trying to find as vague an "invention" as possible that will pass muster so as to foreclose entire technologies from being developed by somebody else. Basically, the process has become weak, and instead of protecting the rights of the inventor, it now hampers the rights of the person wishing to independently reproduce or expand upon a particular invention.
I think if the process was strengthened again, and shored up against the abuses that are so obviously running rampant today, the people bitching most would be those who were trying to abuse the system today. My personal opinion is that many of the people who are anti-IP are really just fed up with the abuses the current system is perpetrating, and if the IP system was suitably fixed, they would be satisfied.
(But, yes, in the end, it does come down to the philosophical discussion of whether anything as nebulous as ideas can be crammed into a framework designed to protect physical objects that we can touch, hold, and handle.)
I don't know that I buy that argument, even with your 'blatantly stupid' examples.
Intellectual property, when used correctly, is a very valuable thing to have. IP, when used incorrectly (also known as "abuse") is the bad thing. What really needs to happen is that the mechanisms that allow companies/individuals to claim IP have to be revised so that they do not allow companies/individuals to abuse their powers as owners of that IP.
I shouldn't be able to I own the concept of all round objects greater than 1mm in size. I should be able to own a particular wheel design that improves traction on slippery surfaces. But what the process is letting me do is say I own the concept of improved traction on slippery surfaces, which is what leads to abuse.
Let's reform the IP process; let's not throw it out.
I want a system that can understand context and ambiguity. I want an NLP shell.
Which is something you're not going to get for a very long time, if ever, because NLP - at least for the English language - may as well be angels dancing on the head of a pin.
In the meantime, you're going to have to be pragmatic and settle for something that is even remotely feasible.
Care to revise your blue-skying downward a little?
copy file_1.txt as file_2.txt, print it, and delete it
The problem you have here is that "it" is ambiguous. Which interpretation do you want, copy file_1.txt as file_2.txt, print file_1.txt, and delete file_1.txt, or copy file_1.txt as file2.txt, print file_2.txt, and delete file_2.txt? Frankly, even as a fluent English speaker, I'm not sure which "it" you are referring to!
As a result, you need to tack on the precise file name. Which, as you can see, doesn't result in a command which is drastically different from the UNIX command:
Theo is the single biggest reason to not use OpenBSD/OpenSSH.
Pffft.
I don't care how big of an asshole somebody is, if they write good, solid code that does what I want/need, I'm using it. Why boycott a piece of software because it's connected to someone who has a bug up their ass?
When you encounter some software that you want to install on Slack that doesn't exist in packaged form (meaning it's either just source, or not in a proper.tar.gz package), what do you do?
Do you convert it into a package and then run it through pkgtool, or do you simply eschew the use of pkgtool and handle your system manually?
If the latter, do you keep track of what files are installed where? If so, how?
Thanks (from somebody who keeps vacillating between Debian and Slack, and who would like some of his Slack questions answered!:)
Why do so many employers want to see Java on your resume then?
As a web developer, you may be responsible for interacting (or possibly/writing/) the back end of the web site in addition to doing the main web page. Java may suck as extras to a web page (the prevailing sentiment on Slashdot is that it does, but the larger jury is still out on that issue), but it rocks at the back end. Server-side Java is a whole different kettle of fish than client-side.
I had a PIII-700 w/ 256M of memory at work, and while I'm not a Windows-lover, I have to honestly say that I never had any of that type of trouble with any application. You might want to double-check to make sure that your system is working at optimal functionality, because that's certainly not normal Windows behaviour.
Slashdot Mirror
Where do you find out about this stuff?
--
You're just arguing over microsoft's interpretation of the word integration.
Yes I am, which is one of the major issues in this lawsuit. What does it mean to integrate components? Microsoft supporters seem to feel integration takes place once a component starts using another component. DOJ supporters feel that integration only takes place when the two components become largely inseparable.
To put it another way, Microsoft seems to be saying that integration is a one-way street. Even if a particular component can be used by any number of third-party applications, once that component is used by a "core" part of the operating system, that part is integrated. Keeping with the car analogy, it's like saying that once the battery is used by the car stereo, the battery and stereo are integrated components. To remove IE means removing the parts of Windows that use IE, much like removing the car stereo would mean removing the battery as well.
DOJ supporters believe that it is a two-way street. Integration means that two components depend on each other for the correct functioning, and that neither can exist alone. In this view, while IE the application may not work properly without IE the component, IE the component can - and does - exist separately from IE the application, much like a car stereo may not work correctly without a battery, but the battery can work and function properly without being connected to a car stereo. If
Furthermore, the two components must actually be used by each other. It might be possible to build a car stereo into a car battery, but if the car stereo doesn't use the battery, I wouldn't call the two components integrated. Similarly, putting the IE component code into the code for DirectX, the GDI, or the TCP/IP subsystem does not make the code "integrated" unless the DirectX, GDI, or TCP/IP code actually utilizes the functionality that the IE code provides.
Microsoft has publicly said that all software components (especially microsoft ones) are made up of smaller components.
And when they said that, they were correct. However, the same could be said for literally anything. My Lego X-Wing fighter at home is also made up of smaller components; does that mean that the Lego bricks are integrated? My computer is made up of a video card, processor, memory, monitor, keyboard, mouse - does that mean all of those components are integrated with each other? (If so, how do you explain the ability to upgrade components without replacing the entire system?)
Windows could work perfectly well without TCP/IP, a GUI, etc. But it wouldn't be as useful. Integration doesn't mean that it won't work without it.
Ah, but now you're playing the shell game by moving the shell with the pea under it. Now, instead of defining integration technologically, we're defining it by its utility.
Integration by utility, in the view of the author of the PDF, can only be justified by offering concrete, clear examples of what is specifically more useful for the two specific programs combined. Many of the advantages that Microsoft offered as rationale for the integration - a single installer, a single point of support, a single source of documentation - are not necessarily exclusive to the IE/Windows combination, nor are they necessarily exclusive to "integrated" components. Two standalone components can be installed with one installer, have one combined source of documentation, and a single point of support. Another useful result of the combination is not having to download the browser - but that too is disingenuous, as that is not really a result of the combination of IE and Windows as it is simply the ability to put the component DLLs on the CD at press time. The benefits - the enhanced utility - for the specific combination of the two must go above and beyond what would be provided if the two components were supplied separately, and at the same revision level (it's easy to say that the "integrated" Windows 98 offers improved functionality over the non-integrated Windows 95 - but how much of that improved functionality/utility is provided simply by the enhancements made in Windows 98?)
So now you have to offer me a list of the benefits of an "integrated" IE and Windows versus a non-integrated IE and Windows, at the same revision level for both programs, minus the subset of benefits that are common to any combined set of programs shipped from the same source.
That is small indeed, my friend, and not a single one immediately springs to mind.
--
They can't do that? The APIs to IE are published so 3rd parties can use these DLLs, just like they would GDI, or COM.
Oh, they can do that all they like. In fact, APIs are necessary to program for Windows.
What I'm saying is that there is a difference between integrating technologies and simply shipping some standalone DLLs.
Removing IE from windows, whether you call it integrated or a dependency still cripples windows and windows applications.
Not exactly. As a dependency, it means that the component can be replaced. If I manufacture a component that conforms to the API - in this case, a component that looks like IE from an interface standpoint - then I can replace IE and Windows is none the wiser.
If IE were truly integrated, I would be absolutely unable to do that. Not only would the removal break the system, but I could not substitute my own components without major, major effort.
Microsoft has touted IE as a component for other developers to use, which means that the IE user interface, Explorer, and every other application which uses the IE component is accessing the API. As a result, Microsoft implicitly admits that IE is a component, and thus replaceable, and thus their claims that it is a true integration are simply wrong.
--
Microsoft added HTML display functionality to the Windows API so any third-party application could use it.
Not really. What Microsoft did was simply to add an extra few DLLs onto each Windows CD and then write their applications to take advantage of the capabilities of the DLLs.
Quicken (for example) doesn't want to say "this only works if you've installed IE as your choice of browsers", they want Quicken to run on Windows as it comes out of the box.
So? I seem to recall numerous products - including Microsoft's own products - that checked to see if you had a specific version of IE and upgraded you to that version if you didn't, in order to run/use a particular program (the one that immediately springs to mind is Visual Studio).
This doesn't prove that Windows and IE are integrated, only that there are benefits from having certain components (in this case, the HTML rendering DLLs) with the operating system.
If this is your particular definition of rendering, then it becomes trivial for anybody with a CD burner to integrate components with Microsoft Windows. Copy a Windows 98SE CD to your hard disk, add a Netscape install directory, and reburn. Voila! Netscape has, more or less, just been integrated with Windows 98.
Taking IE out of Windows would break this functionality.
Yes, it would. But that doesn't necessarily mean the two are integrated, any more than my car and my tires are integrated. If I take the tires off my car, my car doesn't move - therefore my car and tires are integrated components?
The flaw in your argument is that you are confusing dependency with integration. Simply because a component relies on another component does not make the two components integrated. It simply establishes a dependency. My car depends on tires, and won't work without them, but clearly my tires and car are not integrated (or you'd have to scrap your car the first time you had a flat tire). Similarly, Windows depends on IE and may not work without it, but that doesn't mean Windows and IE are integrated.
What Windows requires is a component that offers a specific interface, just like my car requires the standard tire interface for a tire. Any HTML renderer or tire, respectively, will work as long as it conforms to the API in use (which may or may not be the same as the published API). That no other HTML renderer has been written that conforms to the API IE uses in no way mitigates the fact that Windows is dependent on, but not integrated with, IE.
Microsoft was correct with this claim. I'm surprised by the number of Slashdot readers that don't seem to comprehend this.
Microsoft was wrong with this claim. I'm rather surprised at the number of Slashdot readers who can't seem to comprehend the distinction between dependency and integration.
--
Third, Mr. Hollaar has apparently forgotten that he became acquainted with the source code of Microsoft's operating systems in the Caldera and Bristol cases pursuant to protective orders that strictly prohibit him from using that knowledge for any purpose other than preparing his testimony in those cases.
I read the entire PDF file, and frankly I can't see one instance where Mr. Hollaar has used his knowledge of the source code to support any of his arguments. In fact, it seems the only place he mentions source code - beyond the time when he admits that he has seen it - is when he is advocating reviewing the source code to see whether it was simply mixed with some other code to enforce a product combination at compile time.
--
As I understand it, and please correct me if I am mistaken, in Linux only the Kernel is considered the OS, and everything else is software.
Roughly.
The Linux kernel is the heart of the system, but you can't run on the kernel alone. There is a subset of software which is considered required for a Linux system to work correctly, and which could therefore be considered part of the operating system.
I'm not experienced enough with Linux to be able to say specifically which pieces of software are necessary, and how much software is included depends on the definition of "work." Does "work" mean "a user can log in and manipulate files"? If so, that means everything up to, and including, a shell and a text editor. If you simply define "work" as "can boot, but errors are acceptable" then the subset becomes a great deal smaller.
--
Microsoft should be allowed to add new features to their products.
And here we come to the crux of the problem.
I don't think anybody here disagrees with you about Microsoft adding features to their products.
I think the disagreement is whether combining two products together can accurately be called a feature, especially when the technological benefits of combining the two are rather skimpy. As the PDF points out, many of the benefits Microsoft claims as benefits aren't really exclusive to the IE/Windows combination, but the result of what happens if you combine any two programs (for instance, one installer and one source of support, small code base and/or fewer modules to load into memory).
The test is really whether there is any benefit provided by a combined version of IE and Windows that you could not get by simply installing IE on top of Windows.
My personal opinion is no. After having used Internet Explorer 4.0 installed on top of Windows 95 (the original version, which did not come with a version of IE), and subsequently having used versions of Windows 95 and 98 with IE integrated, I honestly could not find any real difference between the two. A non-integrated IE worked as well for me as an integrated IE did. Given that Microsoft provided numerous benefits for the combination, but almost none that applied exclusively as to how the functioning of IE/Windows was improved by the combination of the two programs, I must therefore conclude that Microsoft had no real technological reason for combining the two programs.
Since they had no technological reason to combine them, but they went ahead anyways, Microsoft must have had some other motive for combining the programs.
--
Or ATM machine, or PIN number...
--
Of course, that would require the original poster to read the man pages. Horrors.
*chuckle*
As the second person to reply to my comment points out, though, there's no easy way to downgrade the entire distribution.
On the other hand, if all you have are a handful of bad packages, then the dpkg option is all you need. Realistically, if I do "upgrade" to unstable, am I really going to have much more than a handful or two "bad" packages which will require going back to the original version?
--
Massachusetts, actually.
--
sophisticated and intricate scheme
Gee, that's vague. I wonder if this bill contains any definitions for the words "sophisticated" and "intricate" so as to make that description meaningful.
Nah. That way, they can simply twist the words to mean anything they want!
--
That is, IMHO, the biggest thing really missing from Debian, an easy way to downgrade.
Unless the package is a required package, why can't you simply remove the unstable package and install it again at the desired revision?
(Or, if your configuration needs are simple, you can always purge the package and reinstall it.)
--
Who pays for all the time and money I waste sitting at red lights or stalled traffic on the freeway?
Red lights? Traffic? What are those?
According to the actions of my fellow drivers, that's what gas pedals and breakdown lanes, respectively, are for. Why wait for a red light to change when you can storm through it a full ten seconds after it's turned red? Why sit in traffic when you can zoom down a breakdown lane going at least ten miles over the speed limit?
--
Turn off Javascript
The problem with turning off Javascript is that some sites use Javascript legitimately.
What would be nice is a more advanced mechanism for handling Javascript, such as a global on/off option and a list for specifying which sites shouldn't be processed by that filter. That allows the user a lot of flexibility; they can turn off all Javascript except for those sites where it is absolutely needed, or can leave Javascript on except for the few sites that they find to be too much of a hassle to navigate with it enabled.
--
Really, when I step back and look at it objectively, I don't know who is right; It's a tough issue.
You're right, it is a tough issue. I'm not sure I entirely believe that I should be able to own said design.
But I think there's a strong argument to be made that having intellectual property - when intellectual property is used/supported/organized correctly - actually does foster innovation. Although I don't have a link or reference handy, I do recall reading something a few months ago that basically said it is a historical fact that countries with IP protection have a faster technology growth rate than those that don't. So, in some sense, having IP fosters innovation.
The problem we have today is that IP is becoming less about protecting a specific invention or idea as it is about trying to find as vague an "invention" as possible that will pass muster so as to foreclose entire technologies from being developed by somebody else. Basically, the process has become weak, and instead of protecting the rights of the inventor, it now hampers the rights of the person wishing to independently reproduce or expand upon a particular invention.
I think if the process was strengthened again, and shored up against the abuses that are so obviously running rampant today, the people bitching most would be those who were trying to abuse the system today. My personal opinion is that many of the people who are anti-IP are really just fed up with the abuses the current system is perpetrating, and if the IP system was suitably fixed, they would be satisfied.
(But, yes, in the end, it does come down to the philosophical discussion of whether anything as nebulous as ideas can be crammed into a framework designed to protect physical objects that we can touch, hold, and handle.)
--
Intellectual property is blatantly stupid
I don't know that I buy that argument, even with your 'blatantly stupid' examples.
Intellectual property, when used correctly, is a very valuable thing to have. IP, when used incorrectly (also known as "abuse") is the bad thing. What really needs to happen is that the mechanisms that allow companies/individuals to claim IP have to be revised so that they do not allow companies/individuals to abuse their powers as owners of that IP.
I shouldn't be able to I own the concept of all round objects greater than 1mm in size. I should be able to own a particular wheel design that improves traction on slippery surfaces. But what the process is letting me do is say I own the concept of improved traction on slippery surfaces, which is what leads to abuse.
Let's reform the IP process; let's not throw it out.
--
I want a system that can understand context and ambiguity. I want an NLP shell.
Which is something you're not going to get for a very long time, if ever, because NLP - at least for the English language - may as well be angels dancing on the head of a pin.
In the meantime, you're going to have to be pragmatic and settle for something that is even remotely feasible.
Care to revise your blue-skying downward a little?
--
copy file_1.txt as file_2.txt, print it, and delete it
The problem you have here is that "it" is ambiguous. Which interpretation do you want, copy file_1.txt as file_2.txt, print file_1.txt, and delete file_1.txt, or copy file_1.txt as file2.txt, print file_2.txt, and delete file_2.txt? Frankly, even as a fluent English speaker, I'm not sure which "it" you are referring to!
As a result, you need to tack on the precise file name. Which, as you can see, doesn't result in a command which is drastically different from the UNIX command:
cp file_1.txt file_2.txt; lpr file_1.txt; rm file_1.txt
Put a few alias in (alias copy cp, alias print lpr, alias delete rm), and you can get a command line of:
copy file_1.txt file_2.txt; print file_1.txt; delete file_1.txt
Is it really that much worse than your plain-English equivalent?
--
Theo is the single biggest reason to not use OpenBSD/OpenSSH.
Pffft.
I don't care how big of an asshole somebody is, if they write good, solid code that does what I want/need, I'm using it. Why boycott a piece of software because it's connected to someone who has a bug up their ass?
--
Let me ask you this question about Slackware.
.tar.gz package), what do you do?
:)
When you encounter some software that you want to install on Slack that doesn't exist in packaged form (meaning it's either just source, or not in a proper
Do you convert it into a package and then run it through pkgtool, or do you simply eschew the use of pkgtool and handle your system manually?
If the latter, do you keep track of what files are installed where? If so, how?
Thanks (from somebody who keeps vacillating between Debian and Slack, and who would like some of his Slack questions answered!
--
Why do so many employers want to see Java on your resume then?
/writing/) the back end of the web site in addition to doing the main web page. Java may suck as extras to a web page (the prevailing sentiment on Slashdot is that it does, but the larger jury is still out on that issue), but it rocks at the back end. Server-side Java is a whole different kettle of fish than client-side.
As a web developer, you may be responsible for interacting (or possibly
--
You're smoking crack.
I had a PIII-700 w/ 256M of memory at work, and while I'm not a Windows-lover, I have to honestly say that I never had any of that type of trouble with any application. You might want to double-check to make sure that your system is working at optimal functionality, because that's certainly not normal Windows behaviour.
--
*chuckle*
:)
What a silly bunt!
--
Actually, it's a Dog Detector Van with 'dog' crossed out and 'cat' written in in crayon.
--
Obviously, I'm laughing my socks off here. Do you have a URL or a reference for these "research findings".
I think it's in one of Robert Zubrin's books, but I have long since returned both of them to my library.
Also, how does someone get onto one of these research programs?
If I remember correctly, it's more along the lines of "Hey, nobody's in the pool tonight..." rather than any documented, studied research program.
--