So I read partway down the list and every patent I looked lies somewhere between completely worthless and awfully dubious. For example, in this patent Microsoft claim rights over the concept of a tree which contains different kinds of trees.
Maybe there is a defensible patent in there somewhere but I only saw garbage so far. Yes, somebody needs to sift through the whole lot and perhaps post a selection of the more preposterous claims publicly, but that will not be me. My time is better used developing software.
Nobody who knows Bill Gates gives him low grades for his knowledge, capacity to learn, or drive to know everything he can about any subject he takes on. Perhaps you need to be careful about believing everything you hear. Bill Gates as self-appointed "Chief Architect" of Microsoft was nothing less than a disaster in the role, being largely responsible for the technological tilting at windmills that led the the "reset" and abandonment of the Vista code base that had been worked on for three years, attempting to achieve idiotic goals like replacing the filesystem with a database, a pet project of Billg's. What Microsoft calls Vista today is really Windows NT, essentially a clone of Dec VMS, which Bill Gates had very little to do with. Luckily for Microsoft, it would appear.
Couldn't we start a site/database that organizes all of Microsoft's patents and start documenting prior art and such for each. The patents themselves aren't hidden :
Microsoft's UI patent (155 patents) The first one on the UI list is a design patents, not a software patent: "CLAIM The ornamental design for a user interface for a portion of a display screen, as shown and described."
As such, "a design is manifested in appearance, the subject matter of a design patent application may relate to the configuration or shape of an article" and unless Mscosoft has patented Tux the penguin, that is one patent off the list already.
I'm sure Bill Gate's comments about the internals of windows would be meaningless patter as well. That they would be. Bill Gates knows next to nothing about operating systems design, his delusions notwithstanding.
I work in a software company, and I can assure you that we would be writing just as much software if there were no software patents.
More even. Consider that writing up a patent application takes a major number of hours of investment from a software engineer, besides the costly lawyering involved. Such time and money would be better spent developing useful software.
Given the size of MS pool of patents this set is ridiculously small. I think the ones they selected are pretty bulletproof. Based on what? Microsoft's past record of originality and innovation? Let's see them, and let's see if they are bulletproof or not.
...Even more fun if it's bundled in a self-propagating Windows rootkit. Fun but nasty. Let's beat Microsoft, but let's hold on to the ethical high ground while we do it.
Perhaps, as in the case of SCO, MSFT would rather not have PJ at Groklaw dissect their claims... No doubt. And wasn't there some kind of concerted smear campaign against PJ in the weeks immediately prior to this open declaration of war? From what we know of Microsoft's business methods, it should not surprise us a bit if a connection surfaces.
Personally, I don't think it was meant as a troll. I just think that it was badly thought out and presented. AFAICT they just cut and pasted the HTML code that the poll-site generated for them.
Yes, most probably. Well, there's only one thing to do now:
Does the poll at http://slashdot.org/comments.pl?sid=234451&cid=190 93647 yield skewed results by linking directly to the yes/no votes and failing to show the choices in a way that makes it clear when and for what a vote will be cast?
I am having the hardest time figuring out why parent was modded down. If anything, it should be modded up insightful. There is nothing bad about the poll, and it is somewhat informative and interesting. That post is a troll because it does not disclose that the links go to a poll, and that you will already have voted by the time you first see the page. I, like others I presume, clicked on both links in order before looking at either of them. To my surprise I saw in the first tab that I had already voted for HD DVD, which I had no intention of doing, and in the second that I could not vote for BluRay because I had already been fooled into "voting". I would have voted for Blu-Ray if I had known it was a poll because Blu-Ray offers significantly more storage in the same form factor.
So the GP really does need to be modded into oblivion. Whoever posted that makes Diebold look honest in comparison.
If you want a 'Beginners Guide to Physics' go to the children's library.
Anybody who wants to can add a layman's introduction onto the beginning of the article. Preferably clearly marked as such, and preferably written by someone who understands the in depth article completely.
This is a little off-topic, but could someone please explain to me this fascination and momentum behind Ubuntu? Mandrake/Mandriva has always been extremely user friendly... I dare say more so than Ubuntu? So what's the deal, seriously? One word: apt.
It's not like Solaris with ZFS is any different in this regard. To use snapshotting or any other zfs feature on a physical disk, you have to add the raw block device to the zfs pool. Just like you have to add a physical disk to LVM before you can use LVM snapshots on Linux. You can't just snapshot arbitrary block devices on either OS, holistic layering violations or not.
Exactly my point. It is a stupid, unnecessary restriction whether the stupidity is implemented on Linux or Solaris. Hey, think about this: before some clever ancient person invented and carefully explained to everyone the concept of zero, the human race was unable to count below the number one. Needless to say, negative numbers were beyond the comprehension of the average person. Similarly, you are unable to perceive the benefit of removing a bogus interface layer while at the same time simplifying the user interface and making it easier to add new, sophisticated storage features. Well that is not my problem, it is yours.
funnel all 3D operations through a low level driver
Which is the WHOLE FREAKING point, where that driver sits in the system for performance reasons. I suppose I must just throw up my hands and admit that you are just too dense to understand how delivering geometry via DMA negates any perceived performance benefit of putting a 3D driver in the kernel, leaving only the drawbacks.
You are mental...
And so I understand firstly that you consider yourself competent to judge my mental ability and secondly that you lack the wherewithal to perceive the irony there.
Which would be true if the games were using direct access with no driver interaction and not going through APIs like OpenGL and DirectX. However, since GAMES do, you are either trolling or still in 1990.
You have either sniffed too much glue or smoked too much crack. Both OpenGL and DirectX ultimately funnel all 3D operations through a low level driver, which interacts with the 3D hardware predominantly via DMA just as I said. Now please go back and occupy yourself with some more of those mind altering drugs, just try to refrain from posting on subjects you know next to nothing about.
Very insightful reply. You are right, if we keep sitting around on our fat asses, Apple will do this for us. Or maybe we already do a great job if it, but it will take Apple to add the cool factor. In that case, we penguins can add the "it's free and I own it" factor.
I just need the right brick to run this one on. Did I mention it needs a 3 1/2" sata drive with 500 gig or more? It does. And besides that, the rest of the unit should basically just be a small circuit board with an ethernet jack attached to the side of the drive.
Taking a snapshot of a networked device using GFS and then promoting it to read-write would be downright dangerous and could result in severe data corruption Incidentally, that assertion is just plain wrong. By the definition of snapshot, you can go ahead and write to your snapshot all you like and it will not corrupt your shared network volume because the network volume is (ahem) snapshotted. This is ACID! The "I" in ACID as you are no doubt aware stands for "independent". In this context it means that a change to one snapshot will never affect the data of any other snapshot or the volume that was snapshotted.
First, if you are so convinced that you are right and the world is wrong, nothing is stopping you (aside from your own technical understanding) from maintianing a patch to the Linux source which does exactly as you describe. What a great idea. Why didn't I think of that? (please do not miss the irony)
If it is really that useful, I am sure other people will want it to be included in the source tree. Wow, you are getting warm. (please note the milder irony)
Even if it is only useful in certain niche cases, I am sure you will have a lot of help maintaining it. Yes, funny how that works. And I could expect to receive even more help if it turned out to cure a bad case of braindamage.
But I personally don't think it would be very useful at all, and making the software which is everything to everyone is a recipe for disaster. Always. Oh, and besides the empty rhetoric, what technical basis have you got for spout... err sorry, making such a bold claim?
However, my argument is simply that the LVM layer is a *better* place for this because it can be guaranteed to be reasonably safe and meaningful there. Oh! It looks like the beginning of an argument. Oh wait, no it looks more like more empty rhetoric backed up with a double helping of ungrounded opinion.
In fact, honestly I think that the bottom half of the filesystem is the best place for this functionality simply because the driver has enough knowledge to do this safely under all circumstances. Aha! Why am I not surprised that your argument immediately fell off the rails? To begin with, you have no idea about the relative safety. If anything, safety comes from simplicity and there is no question that abstracting a snapshot as a block device is simpler than implementing it inside a filesystem. Besides, you now propose to saddle us with the choice of either reimplementing the snapshot code for every filesystem which is to have the benefit of this wondrous technology, or deciding to ride bravely into the future with exactly one filesystem which must necessarily be all things to all people. Good luck selling either of those proposals.
Anyway, the discussion is by no means limited to snapshotting. What about mirroring, higher level raid, encryption, multipathing, etc? Do you want to roll all those features into your one, perfect, all singing all bloating filesystem to the exclusion of all other filesystems?
Perhaps the *best* way to handle it would be to put hooks into the LVM and md layers to make it handle this through calls from the filesystem driver. Wow! You are so close. What if I were to tell you that those hooks already exist with minor correctable deficiencies, and that they do not need to be incorporated into the lowest level of the LVM as you wish, because that whole layer is a bogus fabrication of some muddled mind and needs to die?
Sorry about ridiculing your post. To avoid such ridicule in the future, please leave out the empty rhetoric and stick to informed, supportable arguments. If you are unable to do this, then please ask a friend who is informed and thoughtful to post in your place.
Why would you want to do this? It does not buy you anything, as you can already set your system up to create LVM volumes of all your block devices and forget the non-LVM volumes exist. The existence of "raw" block devices that don't allow you access to the LVM features doesn't take away any functionality from you.
Did you bother reading the article? Did you see the part about "the Linux community's inability to design, plan, and act in a holistic manner"? You are an excellent example of that inability.
So much for the rhetoric, now please pay attention if you wish to stop being part of the problem. What this buys is removal of a whole bogus layer that has no technical justification whatsoever for existing. In the process, life becomes simpler for the system admin and we open the door to fixing some of the stupid limitations that we have been saddled with for years because of the idiotic device mapper misfactoring. Got your attention? Think I'm wrong? Well here is some advice: you should not only have read the article and understood it before posting, you should have read the code in question and you obviously have not.
A "physical" block device represents a piece of hardware (usually a hard disk) with some fixed capacity. A LVM block device represents a chunk of some LVM volume group. It makes no sense to have LVM-style snapshotting on block devices that aren't LVM logical volumes - snapshots are implemented using copy-on-write, which requires extra storage space for the modified sectors, and there's nowhere sane to put that with a normal block device.
You have confused "specific driver" with "block device interface". Sigh. Hint: in a C++ context it would be the difference between an abstract interface and an instance of an object of a class derived from the abstract interface. In other words, you are a couple of levels of abstraction away from enlightenment. I suggest starting by learning about the kernel block device interface.
If I understand you correctly, you're proposing to hide the disk driver behind your "LVM" driver.
You might say that, though this is nothing new because disk drivers are already hidden behind LVM drivers.
This is a problem because/dev/hda provides a number of ATA/ATAPI specific system calls. The same is true for devices representing SATA, SCSI or whatever drives. This means your "LVM" needs to know about those system calls.
No that is not a problem because in all cases (hda,/dev/mapper, md, floppy, whatever) the upstream interface is the standard block device api. Only the downstream side of a "physical" driver knows about sata, scsi etc.
And the Linux kernel may have a problem with the entire ideia of "hiding" drivers: how can your "LVM" reference the ATA driver while the remaing kernel thinks/dev/hda means your "LVM" driver?
Device mapper already knows how to "hide" the actual driver[1] and the remaining kernel knows how to sort that out. How do you think it is possible to create a device mapper device as a linear mapping (say) and later even while the device is in use stack a mirror or snapshot on top of it? So how come I can't do that with/dev/hda, hmm?
Another aproach would be adding snapshotting capabilities to your disk driver.
And do it separately for each different kind of disk? Bleah.
Then again, you're making all this mess just to hide stuff from users.
You don't know that. Perhaps this is more simple and powerful than the mess we currently have, which is a great example of bogus layering with no good plan for abstracting across it.
[1] How does device mapper stack one block driver on top of another while the device is in use? Easy, it allocates a new device number internally, moves the existing block driver from the old device number to the new device number, then initializes the new block driver to do its downstream IO to the new device number, and finally stuffs the new block driver into the old device number. There is no reason why this stacking trick could not be learned by all block devices (by lifting it into the generic block layer) then not only would we be able to stack a mirror or snapshot on top of/dev/hda, we could get rid of the device mapper layer entirely.
Right-- there is no technical reason this *cannot* be done. But there are technical reasons this *should* not be done.
There is not a single one that I know of, and in particular, you have not presented a single technical argument against. "Used in fundamentally different ways" is not a technical argument. Neither is "could result in severe data corruption". If I want severe data corruption I can produce it in any number of fine and otherwise useful Unixy ways. You need to take off those blinkers and think about "could be useful" and "could make life nicer for users" and "could be implemented nicely".
My point is that physical and logical devices are used in fundamentally different ways.
My point is that there is no such thing as a "physical" device, there are only block device drivers and instances thereof. And if I want to take a snapshot of/dev/hda, a perfectly reasonable thing to do, I should be able to continue to access the snapshotted device as/dev/hda, which will then be running a different driver that knows about the snapshot). There is no technical reason why this cannot be done. Bold is in the hope that I do not have to say "oh darn" about that point again.
Slashdot Mirror
So I read partway down the list and every patent I looked lies somewhere between completely worthless and awfully dubious. For example, in this patent Microsoft claim rights over the concept of a tree which contains different kinds of trees.
Maybe there is a defensible patent in there somewhere but I only saw garbage so far. Yes, somebody needs to sift through the whole lot and perhaps post a selection of the more preposterous claims publicly, but that will not be me. My time is better used developing software.
...that Micro$oft doesn't have to do anything. The FUD is already spreading, so sit back and watch the corporate CTO's and CIO's squirmunder the pressure of having to (possibly) justify to their boards why they changed to a Linux environment and risk exposure or worse, rather
than pay the usual license fees, and be safe by staying with an all-Windows environment.
Another telltale sign of this is that all of these threads on here and elsewhere are getting zero answers or rebukes from anyone even remotely
associated with Redmond, as they probably all are under strict orders not to do so....
It is plain as day that M$ would probably not dare actual lawsuits, but yet these tactics indicate increasingly desperate attempts at solving
what many at the helm there have identified as a deeper and more pressing crisis:
As we read every day, Linux is gaining a hefty amount of traction worldwide, and this may yet be the safest course for slowling down
what they perceive as the ineluctable spread of a killer virus, and which in the OSS camp others view as nothing less than the long-awaited
liberation from the dark embrace of proprietary software's biggest monopolist.
Make no mistakes!... The M$ ship is finally flying its true colors.
It will be easy to dismiss these tactics, yet Redmond is full of very cunning and determined people who will 'fight to the death' to retain their
cushy jobs, $tock options and have grown accustomed to a way of life where they decide everything.
This was only the first salvo. Brace for more of the same tactics, only uglier.
Z. Who modded your post redundant, does Bill Hilf have mod points today?
Microsoft's UI patent (155 patents) The first one on the UI list is a design patents, not a software patent: "CLAIM The ornamental design for a user interface for a portion of a display screen, as shown and described."
As such, "a design is manifested in appearance, the subject matter of a design patent application may relate to the configuration or shape of an article" and unless Mscosoft has patented Tux the penguin, that is one patent off the list already.
I work in a software company, and I can assure you that we would be writing just as much software if there were no software patents.
More even. Consider that writing up a patent application takes a major number of hours of investment from a software engineer, besides the costly lawyering involved. Such time and money would be better spent developing useful software.
...Even more fun if it's bundled in a self-propagating Windows rootkit. Fun but nasty. Let's beat Microsoft, but let's hold on to the ethical high ground while we do it.
...among others should have standing to file against microsoft Interesting.Personally, I don't think it was meant as a troll. I just think that it was badly thought out and presented. AFAICT they just cut and pasted the HTML code that the poll-site generated for them.
0 93647 yield skewed results by linking directly to the yes/no votes and failing to show the choices in a way that makes it clear when and for what a vote will be cast?
Yes, most probably. Well, there's only one thing to do now:
Does the poll at http://slashdot.org/comments.pl?sid=234451&cid=19
Yes, the poll is misleading
No, the poll is completely fair
Who cares about the damn poll?
OMGPoNiEs!
So the GP really does need to be modded into oblivion. Whoever posted that makes Diebold look honest in comparison.
If you want a 'Beginners Guide to Physics' go to the children's library.
Anybody who wants to can add a layman's introduction onto the beginning of the article. Preferably clearly marked as such, and preferably written by someone who understands the in depth article completely.
It's not like Solaris with ZFS is any different in this regard. To use snapshotting or any other zfs feature on a physical disk, you have to add the raw block device to the zfs pool. Just like you have to add a physical disk to LVM before you can use LVM snapshots on Linux. You can't just snapshot arbitrary block devices on either OS, holistic layering violations or not.
Exactly my point. It is a stupid, unnecessary restriction whether the stupidity is implemented on Linux or Solaris. Hey, think about this: before some clever ancient person invented and carefully explained to everyone the concept of zero, the human race was unable to count below the number one. Needless to say, negative numbers were beyond the comprehension of the average person. Similarly, you are unable to perceive the benefit of removing a bogus interface layer while at the same time simplifying the user interface and making it easier to add new, sophisticated storage features. Well that is not my problem, it is yours.
Which is the WHOLE FREAKING point, where that driver sits in the system for performance reasons. I suppose I must just throw up my hands and admit that you are just too dense to understand how delivering geometry via DMA negates any perceived performance benefit of putting a 3D driver in the kernel, leaving only the drawbacks.
You are mental...
And so I understand firstly that you consider yourself competent to judge my mental ability and secondly that you lack the wherewithal to perceive the irony there.
Which would be true if the games were using direct access with no driver interaction and not going through APIs like OpenGL and DirectX. However, since GAMES do, you are either trolling or still in 1990.
You have either sniffed too much glue or smoked too much crack. Both OpenGL and DirectX ultimately funnel all 3D operations through a low level driver, which interacts with the 3D hardware predominantly via DMA just as I said. Now please go back and occupy yourself with some more of those mind altering drugs, just try to refrain from posting on subjects you know next to nothing about.
Very insightful reply. You are right, if we keep sitting around on our fat asses, Apple will do this for us. Or maybe we already do a great job if it, but it will take Apple to add the cool factor. In that case, we penguins can add the "it's free and I own it" factor.
I just need the right brick to run this one on. Did I mention it needs a 3 1/2" sata drive with 500 gig or more? It does. And besides that, the rest of the unit should basically just be a small circuit board with an ethernet jack attached to the side of the drive.
Anyway, the discussion is by no means limited to snapshotting. What about mirroring, higher level raid, encryption, multipathing, etc? Do you want to roll all those features into your one, perfect, all singing all bloating filesystem to the exclusion of all other filesystems? Perhaps the *best* way to handle it would be to put hooks into the LVM and md layers to make it handle this through calls from the filesystem driver. Wow! You are so close. What if I were to tell you that those hooks already exist with minor correctable deficiencies, and that they do not need to be incorporated into the lowest level of the LVM as you wish, because that whole layer is a bogus fabrication of some muddled mind and needs to die?
Sorry about ridiculing your post. To avoid such ridicule in the future, please leave out the empty rhetoric and stick to informed, supportable arguments. If you are unable to do this, then please ask a friend who is informed and thoughtful to post in your place.
Why would you want to do this? It does not buy you anything, as you can already set your system up to create LVM volumes of all your block devices and forget the non-LVM volumes exist. The existence of "raw" block devices that don't allow you access to the LVM features doesn't take away any functionality from you.
Did you bother reading the article? Did you see the part about "the Linux community's inability to design, plan, and act in a holistic manner"? You are an excellent example of that inability.
So much for the rhetoric, now please pay attention if you wish to stop being part of the problem. What this buys is removal of a whole bogus layer that has no technical justification whatsoever for existing. In the process, life becomes simpler for the system admin and we open the door to fixing some of the stupid limitations that we have been saddled with for years because of the idiotic device mapper misfactoring. Got your attention? Think I'm wrong? Well here is some advice: you should not only have read the article and understood it before posting, you should have read the code in question and you obviously have not.
A "physical" block device represents a piece of hardware (usually a hard disk) with some fixed capacity. A LVM block device represents a chunk of some LVM volume group. It makes no sense to have LVM-style snapshotting on block devices that aren't LVM logical volumes - snapshots are implemented using copy-on-write, which requires extra storage space for the modified sectors, and there's nowhere sane to put that with a normal block device.
You have confused "specific driver" with "block device interface". Sigh. Hint: in a C++ context it would be the difference between an abstract interface and an instance of an object of a class derived from the abstract interface. In other words, you are a couple of levels of abstraction away from enlightenment. I suggest starting by learning about the kernel block device interface.
If I understand you correctly, you're proposing to hide the disk driver behind your "LVM" driver.
/dev/hda provides a number of ATA/ATAPI specific system calls. The same is true for devices representing SATA, SCSI or whatever drives. This means your "LVM" needs to know about those system calls.
/dev/mapper, md, floppy, whatever) the upstream interface is the standard block device api. Only the downstream side of a "physical" driver knows about sata, scsi etc.
/dev/hda means your "LVM" driver?
/dev/hda, hmm?
/dev/hda, we could get rid of the device mapper layer entirely.
You might say that, though this is nothing new because disk drivers are already hidden behind LVM drivers.
This is a problem because
No that is not a problem because in all cases (hda,
And the Linux kernel may have a problem with the entire ideia of "hiding" drivers: how can your "LVM" reference the ATA driver while the remaing kernel thinks
Device mapper already knows how to "hide" the actual driver[1] and the remaining kernel knows how to sort that out. How do you think it is possible to create a device mapper device as a linear mapping (say) and later even while the device is in use stack a mirror or snapshot on top of it? So how come I can't do that with
Another aproach would be adding snapshotting capabilities to your disk driver.
And do it separately for each different kind of disk? Bleah.
Then again, you're making all this mess just to hide stuff from users.
You don't know that. Perhaps this is more simple and powerful than the mess we currently have, which is a great example of bogus layering with no good plan for abstracting across it.
[1] How does device mapper stack one block driver on top of another while the device is in use? Easy, it allocates a new device number internally, moves the existing block driver from the old device number to the new device number, then initializes the new block driver to do its downstream IO to the new device number, and finally stuffs the new block driver into the old device number. There is no reason why this stacking trick could not be learned by all block devices (by lifting it into the generic block layer) then not only would we be able to stack a mirror or snapshot on top of
Right-- there is no technical reason this *cannot* be done. But there are technical reasons this *should* not be done.
There is not a single one that I know of, and in particular, you have not presented a single technical argument against. "Used in fundamentally different ways" is not a technical argument. Neither is "could result in severe data corruption". If I want severe data corruption I can produce it in any number of fine and otherwise useful Unixy ways. You need to take off those blinkers and think about "could be useful" and "could make life nicer for users" and "could be implemented nicely".
My point is that physical and logical devices are used in fundamentally different ways.
/dev/hda, a perfectly reasonable thing to do, I should be able to continue to access the snapshotted device as /dev/hda, which will then be running a different driver that knows about the snapshot). There is no technical reason why this cannot be done. Bold is in the hope that I do not have to say "oh darn" about that point again.
My point is that there is no such thing as a "physical" device, there are only block device drivers and instances thereof. And if I want to take a snapshot of