The BSA knows exactly what they are doing and they are very smart. They simply interpret the facts in the most convenient way they can to advance their agenda. Open source software is a threat to their members, so why should they make any allowances for it in their statistics if they don't have to?
I suspect the BSA is run by rampant free market ideologues. If you pressed them about their philosophy, they would probably say something like that open source software is a threat to the free enterprise system and mostly copies commercial software; while open source may not be illegal, maybe it should be.
Don't expect to be able to reason with those people. Oppose their claims with facts whereever you can, and expose the irrationality and inefficiency of their model of software distribution.
You can see where this has led Microsoft
on
Tech-Interview Riddles
·
· Score: 3, Insightful
Yes, these questions look exactly what Microsoft optimizes for: employees who are really "smart" in a Mensa-sort-of-way. Too bad that programming isn't about being "smart", it's about craftsmanship, taste, engineering tradeoffs, tradition, experience, and long-term dedication. And, not surprisingly, those are areas where Microsoft is sadly lacking.
Actually, the.NET CLI is an ECMA spec as well. MS has released two specs to the ECMA: C# and the CLI.
That's like saying that UNIX is standardized because ANSI C defines stdio; it's confusing a language and a standard library with a platform.
The ECMA standard defines a limited set of facilities that is not equivalent to the whole.NET platform..NET is proprietary, ECMA C# (which includes CLI and some libraries) isn't.
It is useful that Mono tries to implement both the language and library standard (ECMA C#) and the proprietary and non-standardized platform (.NET). But the difference is still very important. Among other things, Mono may well start diverging from Microsoft.NET over time, and that's OK.
The.NET Framework has been released as an open standard via ECMA. Microsoft have added some useful extensions to it to keep them competitive (which may be standardized soon) but the heart of the.NET Framework - the IL standard (like Java bytecode) and the CLR - are open.
Come on, you are playing the same naming games that Microsoft and Sun both are playing. As I was saying, ECMA C# looks nice and non-proprietary. However, ECMA C# is not.NET and it won't run most.NET applications..NET and Java are both proprietary, non-standardized platforms.
However, I like code that runs in a managed environment
"Managed environment" is a most ridiculous term. "Managed environments" have been around since the 1960's. What I can't figure out is whether Microsoft's developers are merely incompetent and don't know what's been happening in the computer industry for decades, or whether this is a deliberate attempt to rewrite history. 2002: Microsoft invents "managed environments". Woohoo. What's next? 2003: Microsoft invents bell bottoms?
Interface designers design interfaces. Programmers implement them. Programmers use toolkits, not Flash. Being an interface designer doesn't qualify you as a programmer.
the reason why people can't set the clock on their vcr is that technical people make the interfaces, not interface designers.
Yeah, right: if your VCR were designed by interface designers, like Microsoft Word, it would have 200 buttons, be bigger than the TV set, crash with regularity, and cost $500. The reason why VCR clocks are hard to set is because there isn't much room for buttons or much money for fancy software. It's called an "engineering tradeoff". Get used to it. If you want a better VCR, pay more: the high end ones are simpler to use or set themselves automatically.
Btw, how is that different from Microsoft's "ownership stripping" licenses? Microsoft's licenses, for example, strip me of the ownership of copyrighted materials that I paid for by restricting my ability to resell copies of Windows I don't want. And Microsoft's source and service licenses also often say that they own some of what I create.
Commercial software vendors and service providers have been stripping people of ownership for many decades. If it's acceptable for commercial software, it ought to be acceptable to keep free and open source software free and open. Or do you think only money-making ventures out to be allowed to strip others of ownership?
It may not look as "flashy", but Java has a much more traditional toolkit than Flash and has extensive libraries to support this kind of functionality. And embedded system programmers are much more likely to feel comfortable with Java than with Flash.
Note that it doesn't matter whether the Flash player is smaller than the Java runtime because that part of it runs in the web browser, not the embedded system. From the point of view of the embedded system, what matters is the footprint of the Flash or application specific class files, and Java is probably competitive there.
PHP and Perl are far more widespread than JSP or J2EE for dynamically created content. Languages like Java or C# are simply too cumbersome and general-purpose for most site developers. So, altogether, I don't believe this is a tremendously important event for most people.
Call me a heretic, but I think.net is a good thing. Not.net as made by Microsoft, but.net as an open standard - for example Mono. The concept of making Web services as easy to run and use as regular applications.
The problem is that.NET is as proprietary as Java. What is not proprietary is ECMA C#.
I predict that systems like Mono will be mostly "like.NET", but they will be fully interoperable only in their ECMA C# subset. And, you know, I think that's perfectly OK. But let's not crown.NET as an open cross-platform environment--it isn't until Microsoft submits the entirely platform for standardization, which is probably going to be when hell freezes over.
Both.NET and Java are proprietary technologies: neither is standardized, and both only have proprietary implementations available for them. What is not proprietary is ECMA C#, which may turn out to be a decent language.
Now, as for "free", you cannot compare.NET with Java. Sun makes available a very high quality implementation on many platforms and provides sources for it. Microsoft makes available one implementation for Windows, and provides an unusable reference implementation under a restrictive license for others. Since you need to have an expensive Microsoft Windows license in order to run their.NET implementation, their "free".NET implementation is, in fact, not free.
Conecpts behind open source and free software are permeating *every* company these days, [...] Microsoft recognizes that to be competitive in some markets (web browsers like IE, Graphic API's like DirectX, and ystem-neutral platforms like.NET), even they need to give stuff away for free.
Microsoft engages in traditional marketing techniques, nothing more. Calling that "free" or "being permeated by open source" is ridiculous. The only way that open source "permeates" Microsoft is by making them fear for their monopoly.
Specifically, what I want to know is how to deal with unwanted suggestions by contributors. By unwanted, I mean submissions which may be nice but which would cause the project to deviate significantly from where you are trying to head.
You explain ahead of time, in the README, what kinds of contributions you are interested in and what kinds you aren't. You might even say "no patches accepted at all". Of course, how much you accept relates to how much benefit you derive from open source.
If someone sends you something you aren't interested in, you thank them but are under no obligation to include it. You put in the work to maintain the code all by yourself, you ultimately decide what goes in (it's more complicated for projects maintained by multiple people). If someone else cares enough about it, they can fork the code and make their own distribution (that's why it's open source).
If you don't want the possibility of forking, release the code under a more restrictive license initially. But I think people generally overestimate the probability or risks of forks.
Be glad the IP laws are different - otherwise, the owners of books and movies *WOULD* be legally obliged to sue fanfic writers.
First of all, many claims against fan fiction are based on trademarks. However, if the trademarks are used in a non-commercial way, things get murky with regard to having to enforce the trademark.
Second, I think it would be good if companies were required to enforce all of their IP claims quickly and fully. Then, writers of fan fiction would have clarity, and companies would be force to make a choice. Does company X want a thriving communities of fans, or do they want tight control of their "property"? Right now, they have people enhance the value of their property, but then they go after them when a buck is to be made.
Strict enforcement of laws is good even if you disagree with the laws: it is only through strict enforcement that the general public sees why some laws don't make sense.
This seems like a pretty clunky piece of equipment. You can get telephone services that give you voice dialing with any phone. Many cell phones already have something like this built in. If, at least, the thing worked standalone and didn't use the PC for voice recognition. You can probably throw together an application like this from open source speech recognition and Linux telephony software fairly easily.
It seems to me books or e-books are all around better: they can be read at the user's pace, they are easier to produce, and they are more compact. Videos might be good for an occasional clip demonstrating something that is difficult to describe; when that is necessary, they are easy to include in e-books. They might also be good for people who are illiterate, but perhaps the first thing to do for people who are illiterate is to teach them how to read.
So, altogether, I just don't see the point of producing a lot of video at all.
I'm sorry, but you really don't "grasp" what was happening in Florida.
The reason for counting was that it was alleged (and appears to have been true) that disproportionate numbers of Democratic ballots were "tossed" in some counties. And that's because such counties were using voting equipment different from that used in other counties.
The solution is to have uniform ballots, which is presumably what they have in the UK. If you don't have uniform ballots, you have to ask the question whether the use of different ballots in different counties favors one or the other party.
You can run the DOS app emulated (using dosemu) or interpreted (using Bochs). You can then automate this by using something like "expect" to simulate typing at the simulated DOS window.
Linux has tons of games, tons of programming tools, several office suites, lots graphics programs, etc. There are probably more apps for Linux than there are for, say, OSX.
The problem isn't that the software doesn't exist, the problem is that people don't know about that. And the cause of that is lack of a marketing budget: a big company can market the hell out of a redundant little utility to copy a disk partition and get lots of people to buy it for $50/copy, which they then use to market more redundant, overpriced utilities. On Linux, you get that stuff included for free, but nobody markets it. As a result, consumers assume it doesn't exist because nobody is throwing big, colorful boxes in their face or putting ads into USA Today that say "Optimize and simplify your dial-up connections with kppp."
Linux on the desktop is fine, really. I have seen quite a number of non-technical users use it, and they do OK. It is a bit disappointing to me that Linux on the desktop isn't any better than commercial desktops--it uses the same stale metaphors and the same cumbersome paradigms--but it isn't any worse either.
I think the biggest obstacle for more widespread adoption of Linux right now is the kernel. Unlike userland, where you have thousands of independently developed programs available on the same machine, the kernel is one big, monolithic chunk. While drivers could in principle be developed and distributed separately, in practice, few are. Most Linux installs that I do involve recompiling the kernel. Whether it's merely packaging or architecture, something isn't working there.
But on ext2 I had kernelcrashes, and fsck's where lots of files were thrown away, like/usr/lib/libgtk+.so or similar.
Actually those files are read by a user process, and I didn't even have write access to it.
Reading a file causes its "last access" time to be written. That means that the inode is being written and may get lost under ext2.
I'm not sure how ext3 handles this with the different options, but if it works that way i don't really like it.
I believe that should not happen under ext3 because it tries to keep your file system structure (which includes inodes) consistent.
Transactional guarantees for file contents are generally useless because programs don't expect them and don't have any means of expressing complex transactions involving file contents.
For example, if the machine dies while AbiWord is in the middle of writing a file, transactional guarantees do you no good because you will still have a truncated AbiWord file. The fact that it is truncated in a consistent way doesn't really help you. Now, you might suggest that files should revert to their original content if the machine crashes before they are closed, but that has huge performance problems and leads to other inconsistencies.
Transactioning file operations only makes sense if you give people an API to express their transaction boundaries. But those APIs already exist, and they work with any file system.
In a nutshell, that's why it doesn't make much sense to journal file contents and why pretty much all journalling file systems only do structure.
One thing that might be useful is if journalling file systems mark any file that was being written or read at the time of a crash as "potentially bad".
Come on, if you don't get it, why waste your moderation points on it? Any geek worth his salt should know that that refers to the Hitchhiker's Guide to the Galazy.
Slashdot Mirror
I suspect the BSA is run by rampant free market ideologues. If you pressed them about their philosophy, they would probably say something like that open source software is a threat to the free enterprise system and mostly copies commercial software; while open source may not be illegal, maybe it should be.
Don't expect to be able to reason with those people. Oppose their claims with facts whereever you can, and expose the irrationality and inefficiency of their model of software distribution.
Yes, these questions look exactly what Microsoft optimizes for: employees who are really "smart" in a Mensa-sort-of-way. Too bad that programming isn't about being "smart", it's about craftsmanship, taste, engineering tradeoffs, tradition, experience, and long-term dedication. And, not surprisingly, those are areas where Microsoft is sadly lacking.
That's like saying that UNIX is standardized because ANSI C defines stdio; it's confusing a language and a standard library with a platform.
The ECMA standard defines a limited set of facilities that is not equivalent to the whole .NET platform. .NET is proprietary, ECMA C# (which includes CLI and some libraries) isn't.
It is useful that Mono tries to implement both the language and library standard (ECMA C#) and the proprietary and non-standardized platform (.NET). But the difference is still very important. Among other things, Mono may well start diverging from Microsoft .NET over time, and that's OK.
Come on, you are playing the same naming games that Microsoft and Sun both are playing. As I was saying, ECMA C# looks nice and non-proprietary. However, ECMA C# is not .NET and it won't run most .NET applications. .NET and Java are both proprietary, non-standardized platforms.
However, I like code that runs in a managed environment
"Managed environment" is a most ridiculous term. "Managed environments" have been around since the 1960's. What I can't figure out is whether Microsoft's developers are merely incompetent and don't know what's been happening in the computer industry for decades, or whether this is a deliberate attempt to rewrite history. 2002: Microsoft invents "managed environments". Woohoo. What's next? 2003: Microsoft invents bell bottoms?
There are several, including Java and (more recently) SVG. Most sites don't benefit from Flash anyway and it just scares users away.
the reason why people can't set the clock on their vcr is that technical people make the interfaces, not interface designers.
Yeah, right: if your VCR were designed by interface designers, like Microsoft Word, it would have 200 buttons, be bigger than the TV set, crash with regularity, and cost $500. The reason why VCR clocks are hard to set is because there isn't much room for buttons or much money for fancy software. It's called an "engineering tradeoff". Get used to it. If you want a better VCR, pay more: the high end ones are simpler to use or set themselves automatically.
Btw, how is that different from Microsoft's "ownership stripping" licenses? Microsoft's licenses, for example, strip me of the ownership of copyrighted materials that I paid for by restricting my ability to resell copies of Windows I don't want. And Microsoft's source and service licenses also often say that they own some of what I create.
Commercial software vendors and service providers have been stripping people of ownership for many decades. If it's acceptable for commercial software, it ought to be acceptable to keep free and open source software free and open. Or do you think only money-making ventures out to be allowed to strip others of ownership?
Note that it doesn't matter whether the Flash player is smaller than the Java runtime because that part of it runs in the web browser, not the embedded system. From the point of view of the embedded system, what matters is the footprint of the Flash or application specific class files, and Java is probably competitive there.
PHP and Perl are far more widespread than JSP or J2EE for dynamically created content. Languages like Java or C# are simply too cumbersome and general-purpose for most site developers. So, altogether, I don't believe this is a tremendously important event for most people.
The problem is that .NET is as proprietary as Java. What is not proprietary is ECMA C#.
I predict that systems like Mono will be mostly "like .NET", but they will be fully interoperable only in their ECMA C# subset. And, you know, I think that's perfectly OK. But let's not crown .NET as an open cross-platform environment--it isn't until Microsoft submits the entirely platform for standardization, which is probably going to be when hell freezes over.
Now, as for "free", you cannot compare .NET with Java. Sun makes available a very high quality implementation on many platforms and provides sources for it. Microsoft makes available one implementation for Windows, and provides an unusable reference implementation under a restrictive license for others. Since you need to have an expensive Microsoft Windows license in order to run their .NET implementation, their "free" .NET implementation is, in fact, not free.
Conecpts behind open source and free software are permeating *every* company these days, [...] Microsoft recognizes that to be competitive in some markets (web browsers like IE, Graphic API's like DirectX, and ystem-neutral platforms like .NET), even they need to give stuff away for free.
Microsoft engages in traditional marketing techniques, nothing more. Calling that "free" or "being permeated by open source" is ridiculous. The only way that open source "permeates" Microsoft is by making them fear for their monopoly.
You explain ahead of time, in the README, what kinds of contributions you are interested in and what kinds you aren't. You might even say "no patches accepted at all". Of course, how much you accept relates to how much benefit you derive from open source.
If someone sends you something you aren't interested in, you thank them but are under no obligation to include it. You put in the work to maintain the code all by yourself, you ultimately decide what goes in (it's more complicated for projects maintained by multiple people). If someone else cares enough about it, they can fork the code and make their own distribution (that's why it's open source).
If you don't want the possibility of forking, release the code under a more restrictive license initially. But I think people generally overestimate the probability or risks of forks.
Because for many purposes, that's what matters. I can use Dell hardware or software with a Compaq, but not natively with a Mac.
Its one of the largest computer companies in the world and for a long time was the largest.
Apple never was the largest computer company by any measure. That title has mostly been held by IBM.
First of all, many claims against fan fiction are based on trademarks. However, if the trademarks are used in a non-commercial way, things get murky with regard to having to enforce the trademark.
Second, I think it would be good if companies were required to enforce all of their IP claims quickly and fully. Then, writers of fan fiction would have clarity, and companies would be force to make a choice. Does company X want a thriving communities of fans, or do they want tight control of their "property"? Right now, they have people enhance the value of their property, but then they go after them when a buck is to be made.
Strict enforcement of laws is good even if you disagree with the laws: it is only through strict enforcement that the general public sees why some laws don't make sense.
This seems like a pretty clunky piece of equipment. You can get telephone services that give you voice dialing with any phone. Many cell phones already have something like this built in. If, at least, the thing worked standalone and didn't use the PC for voice recognition. You can probably throw together an application like this from open source speech recognition and Linux telephony software fairly easily.
Just look at the ears on this one.
So, altogether, I just don't see the point of producing a lot of video at all.
And they are right.
I just laughed and laughed when I saw them on TV testifying in the Florida election debacle hearings.
If they had used paper, it would have been much easier. They used machines, and that was the problem.
The reason for counting was that it was alleged (and appears to have been true) that disproportionate numbers of Democratic ballots were "tossed" in some counties. And that's because such counties were using voting equipment different from that used in other counties.
The solution is to have uniform ballots, which is presumably what they have in the UK. If you don't have uniform ballots, you have to ask the question whether the use of different ballots in different counties favors one or the other party.
You can run the DOS app emulated (using dosemu) or interpreted (using Bochs). You can then automate this by using something like "expect" to simulate typing at the simulated DOS window.
The problem isn't that the software doesn't exist, the problem is that people don't know about that. And the cause of that is lack of a marketing budget: a big company can market the hell out of a redundant little utility to copy a disk partition and get lots of people to buy it for $50/copy, which they then use to market more redundant, overpriced utilities. On Linux, you get that stuff included for free, but nobody markets it. As a result, consumers assume it doesn't exist because nobody is throwing big, colorful boxes in their face or putting ads into USA Today that say "Optimize and simplify your dial-up connections with kppp."
I think the biggest obstacle for more widespread adoption of Linux right now is the kernel. Unlike userland, where you have thousands of independently developed programs available on the same machine, the kernel is one big, monolithic chunk. While drivers could in principle be developed and distributed separately, in practice, few are. Most Linux installs that I do involve recompiling the kernel. Whether it's merely packaging or architecture, something isn't working there.
Reading a file causes its "last access" time to be written. That means that the inode is being written and may get lost under ext2.
I'm not sure how ext3 handles this with the different options, but if it works that way i don't really like it.
I believe that should not happen under ext3 because it tries to keep your file system structure (which includes inodes) consistent.
For example, if the machine dies while AbiWord is in the middle of writing a file, transactional guarantees do you no good because you will still have a truncated AbiWord file. The fact that it is truncated in a consistent way doesn't really help you. Now, you might suggest that files should revert to their original content if the machine crashes before they are closed, but that has huge performance problems and leads to other inconsistencies.
Transactioning file operations only makes sense if you give people an API to express their transaction boundaries. But those APIs already exist, and they work with any file system.
In a nutshell, that's why it doesn't make much sense to journal file contents and why pretty much all journalling file systems only do structure.
One thing that might be useful is if journalling file systems mark any file that was being written or read at the time of a crash as "potentially bad".
Come on, if you don't get it, why waste your moderation points on it? Any geek worth his salt should know that that refers to the Hitchhiker's Guide to the Galazy.