Microsoft's traditional practice has been to have a heavy cash balance.
Their typical research and development technique is to swallow smaller fish that have somethign they want (WebTV, Hotmail, Direct3D, Direct3D Retained Mode, DirectX 2, etc.)
They wait for some other company to develop a product or service that they want, and then they buy that company outright.
I do still have the PDC 2000 (I think it was) pre-release DVD of.NET, where indeed there was a two hour video clip consisting of Balmer chanting "XML XML XML."
At that show, Microsoft was unable to get their product working (which is typical of their showing in the ohio area -- they rent PCs, and install them 2 minutes before the show so stuff doesn't run), and chanted XML is data and data is XML, which really has absolutely nothing to do with.NET (which has its own merits and weaknesses).
However their refusal to support basic features in Visual Studio that, say, #Develop supports is becoming annoying. Having to have 4 versions of Visual Studio installed in order to be able to work with down-level products that you still have to support simply isn't fun.
But in his defense, the PDC in Cincinnatti (I cannot speak for others) did a really lousy job at.NET's launch of saying anything remotely related to what the product was.
The huge "feature" was that they were giving away an XBox as I recall, that was why we sent developers in fact (I kid you not -- the management was hoping to score an XBox, because they were giving away '150' -- what they didn't mention was that those were scattered across over 100 "road shows" in the US, and not at each road show).
First of all, lets say for a second you're a bank. You have to regression test everything to do even a minimal install. If someone posts a "proof of concept" to a security mailing list, newsgroup, etc. this produces a problem. You can't just install some random patch from some random internet user, but meanwhile everyone on the internet at large has detailed instructions on how to break your box.
If you follow this through and think about it for a minute, all the services you depend on have electronic billing -- electricity, phone, internet, banking, etc. --and they can't patch on a heartbeat, they have a process that usually involves at least two weeks of testing, and often involves 30 days of testing.
However even in your example, unless you wrote your kernel from scratch, you don't have 100% control over the situation. Your configs, passwords, etc. aren't going to protect you from a buffer overflow in the TCP stack.
Even if you have ipchains, shorewall, etc. set up, they won't protect you, because the TCP stack has already processed data in order to obtain the IP address, etc. It's already decoded the packet, and as a result the damage could already be done.
Unless you are writing your own kernel, you're totally dependent on whoever the primary distributors to the kernel are, on the quality of the code that they wrote, for your security.
Linus is talking kernel level bugs here, things broken in the kernel. No amount of configuration will protect you from these kinds of problems. The kernel doesn't care about your passwords, and it doesn't care what services you have enabled. The only mitigating factor you might have (for a kernel bug) would be if it is in a file system or device driver that you do not use.
The other issue with rushing it out "as quickly as possible" is performing thorough regression and vulnerability analysis.
If you look at the Descent source code drop, for example, you can see where two developers "round robined" a bug fix. One made the fix, another undid it to correct a different issue, then someone came back and fixed the original issue again which broke the other place, and so forth for some time.
The fact that someone, anyone, distributes a "patch" for the problem doesn't mean that person or persons have the resources to perform an adequate regression test, etc. nor that they are skilled at performing analysis to ensure they've not either broken something else or made it worse.
And, of course, the black hats can make up a name on any e-mail service, and post a "fix" that farther compromises the system, intentionally opening holes, etc. if you really want to get paranoid about it. When it's discovered, they can type a message in all caps with no vowels saying that it was an accident or whatever, close that e-mail account and open a fresh one for next time.
Not that I would expect any to actually do that, it is just a paranoid thought, but the fact that they could is disturbing.
Of course, at the moment, the kernel provides no such isolation and as a basically monolithic model, loading everything into kernel space, would provide significant obstacles to actually obtaining true isolation/containment of damage.
Kernel damage usually doesn't have useable workarounds -- you can shut off apache, or modify settings maybe some percentage of the time (but not always), but in a real world environment, on a production machine, replacing the kernel is likely to be a no-go.
And what software are you running, on the firewall to filter the ports?
The Linux kernel in 2.2 and 2.4 (not sure about 2.6) contained an exploitable vulnerability that could be used to reload the entire kernel on Linksys hardware routers running Linux, for example. You could literally send them a malformed ping, and they would replace the kernel with any software of your choosing. And they would do this regardless of firewall settings, which ports were blocked, etc.
In order for this to work, you need subsystem level security. The TCP stack needs to run in user space, and needs to be able to restrict which devices and kernel functions it can call. If the TCP stack is "hit," but the OS knows when it was loaded it promised not to do any file io, etc. then an attack can only deny service, not bring the kernel down.
Again, looking at it from a pure security standpoint, most of the problems with Windows are also problems with Linux, and a lot of these revolve around assuming the OS itself and devices attached to it actually are working correctly and not vulnerable to attack.
If say "hey I found a buffer overrun" and the full disclosure is that module memhandler.c has a buffer overrun at line 10000, then the script kiddies won't be able to use it for a while (because they can just copy).
If my disclosure is a fully documented exploit that and script kiddie can pick up and use to subvert root on a thousand different systems, that's a different story.
I don't see a problem with a disclosure that gives an idea where the code is, but that doesn't explain a particular attack vector.
It's when you explain the attack vector that, to me, it crosses the line. If there's a vulnerability in the kernel, document it, say where it is, say what it is but don't detail how to exploit it.
i.e. a similar level of vagueness to Microsoft's disclosures:
When opening a file on a NFS share, the Linux kernel uses a stack buffer and doesn't use checked versions of the buffer routines.
vs.
run exploit.c and you'll get a root account with the password 'dilbert,' send 200 copies of a worm to people in the pine address book, and modify libc.so so that every time a file is opened, the password is reset.
The former doesn't give the kiddies anything useful to work with, while allowing anyone capable of actually fixing the problem the necessary information.
The latter gives the kiddies stuff to work with, and basically means half the systems out there will be infected before anyone gets it under control.
My tendency would be to avoid unmoderated disclosure, so that you could ensure if someone decides to post an exploit as a disclosure, you could edit it first.
Line #'s, file names, etc. are OK, just not "here's how to use it to attack." Most of teh script kiddies can't actually write a real attack program, and most don't know assembly well enough to be able to attack a newly discovered vulnerability. They just copy more advanced hackers work.
The more advanced hackers "toss bones" to the script kiddies. These are usually old hacks that are well established, versus new work. It's a trick they use to keep the various groups trying to correct the problems busy chasing their tales.
Not suprisingly, they don't have a lot of love for the Windows product line (having once vowed not to support it, before OS/2 folded), and have previously written cross-platform applications.
Window Blinds itself uses some code from Object Desktop, which at one time was the most popular shell add on in OS/2.
The pop up notifiers are particularly useful when you have an application server that uses RSS to feed error reports. If something goes wrong on my database, a popup notice means I already know about it by the time they call me to report it.
The bigger issue is that DRM are there because a handful of users cannot act responsibly.
Most major corporations want DRM in Word on Word documents. Those represent most of Microsoft's profit base. Open Source projects are looking at ways of providing similar systems, too, for the same reasons.
If a hacker breaks into your computer, you want to limit what they walk away with. If opening a word document requires obtaining a decryption key from a DRM server, then a hacker who breaks into your system gets nothing that they can use.
This is an absolutely critical security issue for many companies, who see cases like Wells Fargo's Linux box propogating credit card numbers into Google searches (it's been fixed) because it wasn't secured correctly.
I am not saying "OMG OMG OMG I love DRM," but there are legitimate uses and there are a lot of people legitimately asking for it.
The other issue you have are the irresponsible college to 25 year old set (maybe it extends down into high school) who see it as "glamorous" to rip off the recording industry, etc.
If I took Gentoo, popped it up on a peer to peer network, and claimed that if I downloaded it from the peer to peer network the copyright and terms of the GPL no longer applied, you would laugh.
However if I do essentially the same thing with the bits and bytes that make up a song, it somehow becomes ok. Or the data that makes up a movie.
The same law, of course, applies in both cases, and redistribution of anothers copyrighted work to hundreds of thousands of people is quite clearly both irresponsible and illegal, but people have shown they don't care and will do it anyway.
And so we get saddled with DRM. You want DRM to go away, then get people to start sharing responsibly and not redistributing other people's work to the internet at large.
XNA (it had been www.microsoft.com/xna, I've not tested it in a while and didn't feel like hitting it at the moment) is bringing XBox Live services to the PC.
Their goal with XBox 2 is to have a single XNA platform that extends to whoever is willing to purchase it. There will be XNA for the PC, as well.
The idea is you write your game or whatever to XNA and DirectX, then you distribute it through Microsoft's online store. For it to work, Messenger and XBox Live must become, more or less, one service.
Their intent is to distribute products for XNA the same way that Steam does. You purchase a license for a particular user, and Messenger (or whatever they call it as the service) associates the license with a passport. Because of this, it can make sure you don't have ten copies of the software running, etc.
The current assumption is that it would come in the forms of a "Games" option on Messenger, versus Microsoft writing a new stand alone XBox Live client for the PC
I agree with your point, however there's one additional case where it is nice.
The best use for XML is at system or domain boundaries, where you cannot control the software on both sides.
For example, a support system might use file exchange to open support tickets in a vendors system for hardware failures. In this case, the vendor probably needs to deal with multiple different customers, and each of their customers might be dealing with several vendors.
Being able to encapsulate to XML, in this case, is valuable so that all partners can understand the data.
You could do this with a binary format, etc. but there is no binary format with the universal library support, and C doesn't guarauntee byte orders and structure layout between platforms, so in that case XML is useful.
That's the only time it's useful.
I strongly dislike using it for comms protocols, because the extensibility and transformation capabilities are lost, and it cripples throughput in the best of situations.
Quote> What's wrong with just compressing the XML as it is with an open and easy-to-implement algorithm like gzip or bzip2?...
There is some repetetive data, but not a lot. A compact binary representation, for the vast majority of common documents, will both be smaller and can be gzip/bzipped with a greater efficiency than the XML can be.
Just taking this and usnig a basic ASCII binary-esque encoding: AB12Test AccountC4test~C~B~A
This will bzip/gzip "as well" as the XML does, it's as extensible as the XML is, it can represent hierarchal data as well as the XML can, it's more compact, it can be processed faster, etc.
If you have to process tens of thousands of transcations per second, you don't want to be processing a 32k text file. Gzip/bzip help transport level size only.
Note that all it takes is a dictionairy and a tagged binary format to get all the functionality of XML, in terms of extensibility, etc. You pick (and require) a byte order, etc.
XML has its uses -- but a standard binary form also has its uses. There's this assumption "there's always a bigger pipe," but it's not reasonable to be using mountains of bandwidth "just because you can."
Totally agree. However, even the non-legit uses will probably eventually become legit. Like VCRs did after Sony was vindicated by the court decision against the MPAA which found that there were more legal uses for video tapes than illegal uses, or at least enough to justify their existence in the consumer market. Once the MPAA had to embrace it, they stopped fighting the VCR, and--miracle of miracles--the rental market padded their wallets quite nicely.
Peer to Peer is not in any way analogous to a VCR, and I wish idiots would quit using the comparison.
If you want to compare it to something, compare it to Radio or to the Printing Press. It is not, in any way, even remotely similar to the situation with VCR's or the various forms of tape.
The General Public License, version 2, is applied to a stream of binary ones and zeroes that happens to represent the Linux operating system. The General Public License, version 2, specifies when, how, etc. you may distribute the Linux operating system. If you are not prepared to follow its rules, you may not use the operating system.
It does not matter if the operating system is delivered via a p2p network, via a web site, via a CD, or if I print the source code character by character on toothpicks, and hand you a copy. The license still applies to the code.
If you take a movie file protected by a Warner Brothers Copyright, and you transcode it -- by any mechanism -- international copyright law recognizes it is still under their protection. They put CSS on the disk, so that you cannot easily duplicate the contents of the disk. You cannot claim "I didn't know it was copyrighted" because you've had to intentionally and willfully run an application to strip the protection.
All Warner Brothers is asking is for the same level of respect you would give the Free Software Foundation.
Just like the Free Software Foundation represents hundreds of thousands of open source projects and their developers, the MPAA/RIAA represent the industry players and their employees.
Just like you would want the FSF to go after Microsoft if it were found that Longhorn used the Linux kernel (or even a significant portion of code from it), the organizations in the MPAA want to go after people who are knowingly, intentionally and systematically disregarding their legal right to determine how their data is distributed.
The people comparing P2P to a VCR "don't get it." A VCR doesn't magically distribute the resulting tape to hundreds of thousands of people, and doesn't make a perfect copy.
All this DRM, etc. is because of a small percentage of the users (mostly/. readers, from reading comments) who seem to feal that the holder of a copyright doesn't have any say in how their project or product is distributed.
So one can only assume that they'd have no problems if Microsoft decided to incorporate the whole of Linux into their OS, since copyrights obviosly don't apply if Microsoft downloads it via P2P.
The search tool can index private documents, such as contracts, business agreements, financial data, etc. that you don't necessarily want to share with the internet at large.
With site search, you can only search publicly available dcuments, that yuo want to expose to the internet at large.
As such, yes, these things are incredibly valuable tools. This is why Windows ships with the (horrible) Indexing function.
WebDAV has unacceptable security and performance characteristics, and no indexing capabilities. Most of this would have been indexing and search tools.
It would be exceptionally bad to be able to go to google and find information on in-progress FBI investigations, after all.
You would have had to spend the $3000 up front, though, and you wouldn't be allowed to distributethe source. So a "freeware" program would be OK, but "free" software wouldn't be possible except under, say, a BSD license where you could pick and choose what source to distribute.
You send a malformed message, and you get some data remaining in the memory block. You can't control what account that data is from, it might or might not be something interesting to read and it might or might not contain sensitive data, etc. If you get lucky, someone using a single password at every site or a simply recognized pattern happens to have the one message that isn't spam in their buffer copied into your message so you can view it, you see their password, guess at the pattern and then have access to all of their data.
In the more likely case, you view their advertisement for v1agra.
Windows TCP stack is the very same one used in BSD, so you might want to re-evaluate that comment, unless of course you don't consider BSD to be a Unix.
The difference between support on linux and support on windows is mostly statistical. Look at debian, gentoo, even freebsd. You can upgrade to stable packages (maybe not gentoo) dynamically without running a time wasting installer.
Remind me again, what is apt-get? Oh right, a time wasting installer. Thanks.
Total cost of ownership comes into play here, too.
You have a lab assistant getting paid, say, $6/hour. If Opera provides support for the browser, then the lab assistant has less work that they have to do to support Opera, and can devote more time to helping people with other problems.
Depending on the situation, number of browsers, etc. this might be able to reduce the number of lab assistants you need, or it might be able to improve the level of support for individual users who need help.
Note that I'm not saying "FireFox sucks" or anythign else here, what I'm saying is that from an economic standpoint, if you have to have two people doing full time FireFox support, it's more expensive than if the vendor provides the support for their product.
This is what motivates corporations, too. If I have to "fix it myself" in Open Source, then ever hour I spend "fixing it myself" is billed to the company at $30/hour. If the software worked, I could be doing productive tasks instead, which long term is better for the company.
Note that this is, of course, all a matter of perspective.
This is one reason why I hold both open and closed source software have their purposes.
A history, drama or music major is unlikely to be able to build from source, and almost certainly is going to be unable to take over maintenence of a program. They are buying the closed source program because they can install it and it just works. They don't have to think (it hurts them to think), they put the CD in the drive, they click install, and the software just works.
When something goes wrong, they have someone they can call for help. They aren't capable of maintaining the code themselves, and they don't have to be. They don't have to post to a newsgroup or mailing list and have the first hundred replies be from the "its open source, fix it yourself" troll gang.
In business, I get $30/hour to develop software, most of which these days being web pages. I can use open source tools for some of it, and for some of it I use closed source tools. I use whatever tool gets the job done. However, I'm unlikely to "fix it myself" unless I cannot work around a problem, even in open source -- because it will impact another schedule to do so, and the page "has" to be up on xyz date.
This is what needs to be understood -- there are two viewpoints here. One viewpoint is of a "do it yourselfer." This viewpoint is I want source code, so I can "do it myself" when there's a problem.
The other viewpoint is that "if it fails, I want to be able to call someone and have them have the responsibility to fix it."
If you look at MySQL, for example, they understand this distinction. You can use their GPL database, or you can obtain a commercial license. If you obtain a commercial license and something breaks, you can get them to fix it.:)
FireFox consists of a bunch of XPCOM components glued together. Thunderbird, likewise, is a bunch of XPCOM components glued together.
If you look at Mozilla, you start the browser, then you go to tools | email to switch to email or to tools | composer to switch to composer, etc. The pieces are still "stand alone" applications, it's just a matter the menus are wired to load them as if they were integrated.
If you made each "piece" an XPCOM component, you could have a stub "FireFox" executable that loaded just the web browser "piece" and then you could have the "suite" that just loaded all the pieces.
That's the way it really should probably be. It means an unmeasurable hit on startup of firefox, but it makes everything consistent throughout the "suite."
The fractal encoding SDK, as I recall, sold for around $2500 and required a 5% royalty per copy (the royalty may have been higher).
Despite all the advantages of the format, few commercial companies are going to pay $2500 for the SDK and then give up 5% of their profits to support a format that isn't interoperable with other software.
If you're a scanner company, the space savings is offset by the pictures not working with the user's word processor, etc. If you're Adobe, you don't want to give up 5% on your flagship products just to support one file format, etc.
Had they had more reasonable licensing, it probably would have taken off in the commercial market (say $300 for the library, and $0.50 per program sold -- this would still be a mountain of money if you got scanner companies, etc. to adopt it).
So far as noncommercial adoptation goes, the freeware folks would have picked it up in a heart beat if the license terms weren't so harsh.
Slashdot Mirror
Quote> much less a woman who would sleep with him (without paying, of course).
How many jokes out of this?
* You would expect the woman to pay?
* I know he's bad, but I don't think what he has is contagious?
* He's big but not that big?
So many oppportunities, from just one sentence.
Microsoft's traditional practice has been to have a heavy cash balance.
Their typical research and development technique is to swallow smaller fish that have somethign they want (WebTV, Hotmail, Direct3D, Direct3D Retained Mode, DirectX 2, etc.)
They wait for some other company to develop a product or service that they want, and then they buy that company outright.
Well in his defense,
.NET, where indeed there was a two hour video clip consisting of Balmer chanting "XML XML XML."
.NET (which has its own merits and weaknesses).
.NET's launch of saying anything remotely related to what the product was.
I do still have the PDC 2000 (I think it was) pre-release DVD of
At that show, Microsoft was unable to get their product working (which is typical of their showing in the ohio area -- they rent PCs, and install them 2 minutes before the show so stuff doesn't run), and chanted XML is data and data is XML, which really has absolutely nothing to do with
However their refusal to support basic features in Visual Studio that, say, #Develop supports is becoming annoying. Having to have 4 versions of Visual Studio installed in order to be able to work with down-level products that you still have to support simply isn't fun.
But in his defense, the PDC in Cincinnatti (I cannot speak for others) did a really lousy job at
The huge "feature" was that they were giving away an XBox as I recall, that was why we sent developers in fact (I kid you not -- the management was hoping to score an XBox, because they were giving away '150' -- what they didn't mention was that those were scattered across over 100 "road shows" in the US, and not at each road show).
Microsoft runs tons of banner advertisements, particularly on open source friendly sites (sf.net), and runs many TV commercials.
The TV commercials run like this:
We see the next president, we see the next big business owner, we see whatever.
They run advertisements of people sitting around the table on top of a mountain.
I'd really like to know how you would say that a company that spends more on advertising than any other in the computer industry isn't advertising.
You're just not noticing it -- it's why the media is wrapped around their fingers, and why they were able to kill coverage of competing products, etc.
Oh yes, they advertise.
Except that you still don't.
First of all, lets say for a second you're a bank. You have to regression test everything to do even a minimal install. If someone posts a "proof of concept" to a security mailing list, newsgroup, etc. this produces a problem. You can't just install some random patch from some random internet user, but meanwhile everyone on the internet at large has detailed instructions on how to break your box.
If you follow this through and think about it for a minute, all the services you depend on have electronic billing -- electricity, phone, internet, banking, etc. --and they can't patch on a heartbeat, they have a process that usually involves at least two weeks of testing, and often involves 30 days of testing.
However even in your example, unless you wrote your kernel from scratch, you don't have 100% control over the situation. Your configs, passwords, etc. aren't going to protect you from a buffer overflow in the TCP stack.
Even if you have ipchains, shorewall, etc. set up, they won't protect you, because the TCP stack has already processed data in order to obtain the IP address, etc. It's already decoded the packet, and as a result the damage could already be done.
Unless you are writing your own kernel, you're totally dependent on whoever the primary distributors to the kernel are, on the quality of the code that they wrote, for your security.
Linus is talking kernel level bugs here, things broken in the kernel. No amount of configuration will protect you from these kinds of problems. The kernel doesn't care about your passwords, and it doesn't care what services you have enabled. The only mitigating factor you might have (for a kernel bug) would be if it is in a file system or device driver that you do not use.
The other issue with rushing it out "as quickly as possible" is performing thorough regression and vulnerability analysis.
If you look at the Descent source code drop, for example, you can see where two developers "round robined" a bug fix. One made the fix, another undid it to correct a different issue, then someone came back and fixed the original issue again which broke the other place, and so forth for some time.
The fact that someone, anyone, distributes a "patch" for the problem doesn't mean that person or persons have the resources to perform an adequate regression test, etc. nor that they are skilled at performing analysis to ensure they've not either broken something else or made it worse.
And, of course, the black hats can make up a name on any e-mail service, and post a "fix" that farther compromises the system, intentionally opening holes, etc. if you really want to get paranoid about it. When it's discovered, they can type a message in all caps with no vowels saying that it was an accident or whatever, close that e-mail account and open a fresh one for next time.
Not that I would expect any to actually do that, it is just a paranoid thought, but the fact that they could is disturbing.
Of course, at the moment, the kernel provides no such isolation and as a basically monolithic model, loading everything into kernel space, would provide significant obstacles to actually obtaining true isolation/containment of damage.
Kernel damage usually doesn't have useable workarounds -- you can shut off apache, or modify settings maybe some percentage of the time (but not always), but in a real world environment, on a production machine, replacing the kernel is likely to be a no-go.
And what software are you running, on the firewall to filter the ports?
The Linux kernel in 2.2 and 2.4 (not sure about 2.6) contained an exploitable vulnerability that could be used to reload the entire kernel on Linksys hardware routers running Linux, for example. You could literally send them a malformed ping, and they would replace the kernel with any software of your choosing. And they would do this regardless of firewall settings, which ports were blocked, etc.
In order for this to work, you need subsystem level security. The TCP stack needs to run in user space, and needs to be able to restrict which devices and kernel functions it can call. If the TCP stack is "hit," but the OS knows when it was loaded it promised not to do any file io, etc. then an attack can only deny service, not bring the kernel down.
Again, looking at it from a pure security standpoint, most of the problems with Windows are also problems with Linux, and a lot of these revolve around assuming the OS itself and devices attached to it actually are working correctly and not vulnerable to attack.
The issue of "what is disclosure" come in too.
If say "hey I found a buffer overrun" and the full disclosure is that module memhandler.c has a buffer overrun at line 10000, then the script kiddies won't be able to use it for a while (because they can just copy).
If my disclosure is a fully documented exploit that and script kiddie can pick up and use to subvert root on a thousand different systems, that's a different story.
I don't see a problem with a disclosure that gives an idea where the code is, but that doesn't explain a particular attack vector.
It's when you explain the attack vector that, to me, it crosses the line. If there's a vulnerability in the kernel, document it, say where it is, say what it is but don't detail how to exploit it.
i.e. a similar level of vagueness to Microsoft's disclosures:
When opening a file on a NFS share, the Linux kernel uses a stack buffer and doesn't use checked versions of the buffer routines.
vs.
run exploit.c and you'll get a root account with the password 'dilbert,' send 200 copies of a worm to people in the pine address book, and modify libc.so so that every time a file is opened, the password is reset.
The former doesn't give the kiddies anything useful to work with, while allowing anyone capable of actually fixing the problem the necessary information.
The latter gives the kiddies stuff to work with, and basically means half the systems out there will be infected before anyone gets it under control.
My tendency would be to avoid unmoderated disclosure, so that you could ensure if someone decides to post an exploit as a disclosure, you could edit it first.
Line #'s, file names, etc. are OK, just not "here's how to use it to attack." Most of teh script kiddies can't actually write a real attack program, and most don't know assembly well enough to be able to attack a newly discovered vulnerability. They just copy more advanced hackers work.
The more advanced hackers "toss bones" to the script kiddies. These are usually old hacks that are well established, versus new work. It's a trick they use to keep the various groups trying to correct the problems busy chasing their tales.
You might talk to Stardock.
Not suprisingly, they don't have a lot of love for the Windows product line (having once vowed not to support it, before OS/2 folded), and have previously written cross-platform applications.
Window Blinds itself uses some code from Object Desktop, which at one time was the most popular shell add on in OS/2.
The pop up notifiers are particularly useful when you have an application server that uses RSS to feed error reports. If something goes wrong on my database, a popup notice means I already know about it by the time they call me to report it.
The bigger issue is that DRM are there because a handful of users cannot act responsibly.
Most major corporations want DRM in Word on Word documents. Those represent most of Microsoft's profit base. Open Source projects are looking at ways of providing similar systems, too, for the same reasons.
If a hacker breaks into your computer, you want to limit what they walk away with. If opening a word document requires obtaining a decryption key from a DRM server, then a hacker who breaks into your system gets nothing that they can use.
This is an absolutely critical security issue for many companies, who see cases like Wells Fargo's Linux box propogating credit card numbers into Google searches (it's been fixed) because it wasn't secured correctly.
I am not saying "OMG OMG OMG I love DRM," but there are legitimate uses and there are a lot of people legitimately asking for it.
The other issue you have are the irresponsible college to 25 year old set (maybe it extends down into high school) who see it as "glamorous" to rip off the recording industry, etc.
If I took Gentoo, popped it up on a peer to peer network, and claimed that if I downloaded it from the peer to peer network the copyright and terms of the GPL no longer applied, you would laugh.
However if I do essentially the same thing with the bits and bytes that make up a song, it somehow becomes ok. Or the data that makes up a movie.
The same law, of course, applies in both cases, and redistribution of anothers copyrighted work to hundreds of thousands of people is quite clearly both irresponsible and illegal, but people have shown they don't care and will do it anyway.
And so we get saddled with DRM. You want DRM to go away, then get people to start sharing responsibly and not redistributing other people's work to the internet at large.
XNA (it had been www.microsoft.com/xna, I've not tested it in a while and didn't feel like hitting it at the moment) is bringing XBox Live services to the PC.
Their goal with XBox 2 is to have a single XNA platform that extends to whoever is willing to purchase it. There will be XNA for the PC, as well.
The idea is you write your game or whatever to XNA and DirectX, then you distribute it through Microsoft's online store. For it to work, Messenger and XBox Live must become, more or less, one service.
Their intent is to distribute products for XNA the same way that Steam does. You purchase a license for a particular user, and Messenger (or whatever they call it as the service) associates the license with a passport. Because of this, it can make sure you don't have ten copies of the software running, etc.
The current assumption is that it would come in the forms of a "Games" option on Messenger, versus Microsoft writing a new stand alone XBox Live client for the PC
I agree with your point, however there's one additional case where it is nice.
The best use for XML is at system or domain boundaries, where you cannot control the software on both sides.
For example, a support system might use file exchange to open support tickets in a vendors system for hardware failures. In this case, the vendor probably needs to deal with multiple different customers, and each of their customers might be dealing with several vendors.
Being able to encapsulate to XML, in this case, is valuable so that all partners can understand the data.
You could do this with a binary format, etc. but there is no binary format with the universal library support, and C doesn't guarauntee byte orders and structure layout between platforms, so in that case XML is useful.
That's the only time it's useful.
I strongly dislike using it for comms protocols, because the extensibility and transformation capabilities are lost, and it cripples throughput in the best of situations.
Quote> What's wrong with just compressing the XML as it is with an open and easy-to-implement algorithm like gzip or bzip2? ...
There is some repetetive data, but not a lot. A compact binary representation, for the vast majority of common documents, will both be smaller and can be gzip/bzipped with a greater efficiency than the XML can be.
Just taking this and usnig a basic ASCII binary-esque encoding:
AB12Test AccountC4test~C~B~A
This will bzip/gzip "as well" as the XML does, it's as extensible as the XML is, it can represent hierarchal data as well as the XML can, it's more compact, it can be processed faster, etc.
If you have to process tens of thousands of transcations per second, you don't want to be processing a 32k text file. Gzip/bzip help transport level size only.
Note that all it takes is a dictionairy and a tagged binary format to get all the functionality of XML, in terms of extensibility, etc. You pick (and require) a byte order, etc.
XML has its uses -- but a standard binary form also has its uses. There's this assumption "there's always a bigger pipe," but it's not reasonable to be using mountains of bandwidth "just because you can."
Peer to Peer is not in any way analogous to a VCR, and I wish idiots would quit using the comparison.
If you want to compare it to something, compare it to Radio or to the Printing Press. It is not, in any way, even remotely similar to the situation with VCR's or the various forms of tape.
The General Public License, version 2, is applied to a stream of binary ones and zeroes that happens to represent the Linux operating system. The General Public License, version 2, specifies when, how, etc. you may distribute the Linux operating system. If you are not prepared to follow its rules, you may not use the operating system.
It does not matter if the operating system is delivered via a p2p network, via a web site, via a CD, or if I print the source code character by character on toothpicks, and hand you a copy. The license still applies to the code.
If you take a movie file protected by a Warner Brothers Copyright, and you transcode it -- by any mechanism -- international copyright law recognizes it is still under their protection. They put CSS on the disk, so that you cannot easily duplicate the contents of the disk. You cannot claim "I didn't know it was copyrighted" because you've had to intentionally and willfully run an application to strip the protection.
All Warner Brothers is asking is for the same level of respect you would give the Free Software Foundation.
Just like the Free Software Foundation represents hundreds of thousands of open source projects and their developers, the MPAA/RIAA represent the industry players and their employees.
Just like you would want the FSF to go after Microsoft if it were found that Longhorn used the Linux kernel (or even a significant portion of code from it), the organizations in the MPAA want to go after people who are knowingly, intentionally and systematically disregarding their legal right to determine how their data is distributed.
The people comparing P2P to a VCR "don't get it." A VCR doesn't magically distribute the resulting tape to hundreds of thousands of people, and doesn't make a perfect copy.
All this DRM, etc. is because of a small percentage of the users (mostly
So one can only assume that they'd have no problems if Microsoft decided to incorporate the whole of Linux into their OS, since copyrights obviosly don't apply if Microsoft downloads it via P2P.
The search tool can index private documents, such as contracts, business agreements, financial data, etc. that you don't necessarily want to share with the internet at large.
With site search, you can only search publicly available dcuments, that yuo want to expose to the internet at large.
As such, yes, these things are incredibly valuable tools. This is why Windows ships with the (horrible) Indexing function.
WebDAV has unacceptable security and performance characteristics, and no indexing capabilities. Most of this would have been indexing and search tools.
It would be exceptionally bad to be able to go to google and find information on in-progress FBI investigations, after all.
You would have had to spend the $3000 up front, though, and you wouldn't be allowed to distributethe source. So a "freeware" program would be OK, but "free" software wouldn't be possible except under, say, a BSD license where you could pick and choose what source to distribute.
OK so here's the vulnerability...
You send a malformed message, and you get some data remaining in the memory block. You can't control what account that data is from, it might or might not be something interesting to read and it might or might not contain sensitive data, etc. If you get lucky, someone using a single password at every site or a simply recognized pattern happens to have the one message that isn't spam in their buffer copied into your message so you can view it, you see their password, guess at the pattern and then have access to all of their data.
In the more likely case, you view their advertisement for v1agra.
Windows TCP stack is the very same one used in BSD, so you might want to re-evaluate that comment, unless of course you don't consider BSD to be a Unix.
Remind me again, what is apt-get? Oh right, a time wasting installer. Thanks.
Total cost of ownership comes into play here, too.
:)
You have a lab assistant getting paid, say, $6/hour. If Opera provides support for the browser, then the lab assistant has less work that they have to do to support Opera, and can devote more time to helping people with other problems.
Depending on the situation, number of browsers, etc. this might be able to reduce the number of lab assistants you need, or it might be able to improve the level of support for individual users who need help.
Note that I'm not saying "FireFox sucks" or anythign else here, what I'm saying is that from an economic standpoint, if you have to have two people doing full time FireFox support, it's more expensive than if the vendor provides the support for their product.
This is what motivates corporations, too. If I have to "fix it myself" in Open Source, then ever hour I spend "fixing it myself" is billed to the company at $30/hour. If the software worked, I could be doing productive tasks instead, which long term is better for the company.
Note that this is, of course, all a matter of perspective.
This is one reason why I hold both open and closed source software have their purposes.
A history, drama or music major is unlikely to be able to build from source, and almost certainly is going to be unable to take over maintenence of a program. They are buying the closed source program because they can install it and it just works. They don't have to think (it hurts them to think), they put the CD in the drive, they click install, and the software just works.
When something goes wrong, they have someone they can call for help. They aren't capable of maintaining the code themselves, and they don't have to be. They don't have to post to a newsgroup or mailing list and have the first hundred replies be from the "its open source, fix it yourself" troll gang.
In business, I get $30/hour to develop software, most of which these days being web pages. I can use open source tools for some of it, and for some of it I use closed source tools. I use whatever tool gets the job done. However, I'm unlikely to "fix it myself" unless I cannot work around a problem, even in open source -- because it will impact another schedule to do so, and the page "has" to be up on xyz date.
This is what needs to be understood -- there are two viewpoints here. One viewpoint is of a "do it yourselfer." This viewpoint is I want source code, so I can "do it myself" when there's a problem.
The other viewpoint is that "if it fails, I want to be able to call someone and have them have the responsibility to fix it."
If you look at MySQL, for example, they understand this distinction. You can use their GPL database, or you can obtain a commercial license. If you obtain a commercial license and something breaks, you can get them to fix it.
Just a thought...
FireFox consists of a bunch of XPCOM components glued together. Thunderbird, likewise, is a bunch of XPCOM components glued together.
If you look at Mozilla, you start the browser, then you go to tools | email to switch to email or to tools | composer to switch to composer, etc. The pieces are still "stand alone" applications, it's just a matter the menus are wired to load them as if they were integrated.
If you made each "piece" an XPCOM component, you could have a stub "FireFox" executable that loaded just the web browser "piece" and then you could have the "suite" that just loaded all the pieces.
That's the way it really should probably be. It means an unmeasurable hit on startup of firefox, but it makes everything consistent throughout the "suite."
The fractal encoding SDK, as I recall, sold for around $2500 and required a 5% royalty per copy (the royalty may have been higher).
Despite all the advantages of the format, few commercial companies are going to pay $2500 for the SDK and then give up 5% of their profits to support a format that isn't interoperable with other software.
If you're a scanner company, the space savings is offset by the pictures not working with the user's word processor, etc. If you're Adobe, you don't want to give up 5% on your flagship products just to support one file format, etc.
Had they had more reasonable licensing, it probably would have taken off in the commercial market (say $300 for the library, and $0.50 per program sold -- this would still be a mountain of money if you got scanner companies, etc. to adopt it).
So far as noncommercial adoptation goes, the freeware folks would have picked it up in a heart beat if the license terms weren't so harsh.