The main problem with that is that even if SQL was 100% standard, databases still have different behavior. For example, if you tune something for MS SQL Server, performance will suck on postgres and viceversa. If you try to make it run well on both, it'll run suboptimally on both.
For instance: MS SQL Server 2000, as a database that uses locks, likes small transactions. The smaller the better. A long running transaction in MS SQL is potentially troublesome. Big transaction locks row, another connection waits on that, another connection waits on the second one, and so on. Database grinds to a halt until the big transaction is done.
On the other hand, postgres has a high overhead for creating a transaction, but once that's done, the more you do there the better. The same long running transaction in postgres won't create any problems in postgres due to MVCC. Now, if you use postgres where nearly every database query is one sentence in its own transaction, then performance won't be impressive.
And who'd protect this hardware lockdown mechanism?
Without copyright, anybody could pass schematics, specs and firmware dumps around. Any chinese company could manufacture compatible, DRM-less hardware.
It's easy to do this in ZFS but it's impossible to do this with LVM, because filesystem driver needs to know about physical distribution of block device's sectors.
Not impossible at all, although not very easy either.
1. Resize the filesystem itself (resize_reiserfs, etc) 2. lvreduce the underlying logical volume 3. pvmove data from the device you want to free up elsewhere 4. pvremove the now free physical volume
Major problems here are the need to resize the filesystem (which may require unmounting it), and that resizing the FS and lvreduce need to be in sync or you get data corruption. It's not ideal, and not as nice as ZFS, but it's definitely doable.
The point being - users of the kernel (end-users, developers, commercial and OEMs) and NIC vendors now have to scramble around to find ways to try to appease the Linux community - comply with GPL - and/or hack around the kernel, stack, hardware and user-apps - all to still get the performance that the Linux stack is sorley lacking.
And that's precisely the way I like it. Why the hell should I surrender to the whims of some network card manufacturer? If they don't produce the stuff I want, I'll buy from somebody who does.
Not that MS doesn't do the same, for example by dropping hardware acceleration from DirectSound.
Ok, under LVM,/dev/hda is a physical volume. PVs get grouped into volume groups, then get subdivided into logical volumes.
It doesn't make sense to talk of a snapshot of/dev/hda (which maps to a single hardware device) because nothing stops you from creating a logical volume spanning 4 hard disks. What exactly would a snapshot of/dev/hda in that case be? As far as LVM is concerned, your data is somewhere in volume group, which is a virtual entity made of a number of physical volumes. Your logical volume may span one or several PVs, and doesn't have a fixed location either. You can at any time tell LVM to free up a physical volume and disconnect it.
Because with the incumbent volume management strategy you may not continue to use/dev/hda directly when it is snapshotted.
No, you may not continue to use/dev/hda the moment you turn it into a LVM physical volume. You can't snapshot anything that isn't a LVM logical volume (using LVM at least).
If you're using LVM, you don't mount/dev/hda, you mount/dev/mapper/something
qmail seems to have been abandoned by DJB, and his licensing requirements mean other people can't fork development, they can only distribute patches for it.
In ZFS, a snapshot can be promoted to a clone, which is a writeable copy of the original filesystem, sharing unmodified blocks using a copy-on-write algorithm.
LVM has this already. CONFIG_DM_SNAPSHOT in the kernel config.
Would you expect a 'first class' writeable clone to have a name like 'dev/mapper/snapshotted-hda' or 'dev/hda.1'? Which one makes more sense?
If you use LVM, then all devices you put a filesystem on are in/dev/mapper. My root is in/dev/data/root,/home is in/dev/data/home (or/dev/mapper/data-home, same thing), a snapshot of that would also be in/dev/mapper, with whatever name I choose for it. If you use LVM,/dev/hda isn't directly usable, as it's a LVM physical volume. The writable device is in/dev/mapper.
Why would the original have a special name, when the clone is identical?
But they aren't identical. LVM works with block devices, it doesn't know about the filesystem. If you do a bit-by-bit comparison of the original device with its snapshot, if the original changed, then there will be differences. The snapshot contains the data it would if you unmounted the FS and make a copy of the device.
Ok, if I understand this correctly, then LVM and ZFS snapshots have different uses.
For me, the main point of LVM snapshots is consistent backups. LVM can freeze any block device in time. The nice thing is that it doesn't have to be a known filesystem. It could be for example a device used by vmware, or a database as-is, with no filesystem on it. A neat application of this is data recovery. LVM can take a writable snapshot of a corrupted filesystem. Then you can try the latest experimental fsck tool on it, without worrying about it breaking something, and not needing to keep a full copy of the data.
ZFS is certainly really neat, but it can't fully replace LVM snapshots, nor LVM can provide what ZFS can.
Why can't I say "/dev/hda, you are now snapshotted, shazam"? No, instead I have change my system over to use/dev/mapper/snapshotted-hda
You don't seem to understand snapshots.
A snapshot works by creating a copy of the device, with the contents it had when the snapshot was created. If you make a snapshot of/dev/hda at 12:15, then you'll get/dev/mapper/snapshotted-hda as it was at 12:15, while/dev/hda will continue being possible to modify.
Why would you change anything over? Snapshots are temporary. You snapshot your drive, use the snapshot to create a consistent backup (or whatever), then destroy it.
Normally you won't keep a snapshot around for long, as they're maintained by keeping copies of modified blocks, and that takes space. Unless you have enough space for fully duplicating the device you made a snapshot of, you won't be able to keep it around forever.
That sounds like the wrong way to solve the problem. I'd rather solve it in the RAID layer, so that anything using the disk can take advantage.
For instance, vmware can use a block device for a virtual disk. Why should it have to implement its own version of that when it could be implemented in a single place?
Same goes for snapshotting. Why does the FS have to support it? With LVM I can snapshot vfat if need to for whatever reason.
Layers might not be ideal, but they're consistent. The filesystem does its part, RAID/LVM does its own, etc.
ZFS seems to want to take all over the disk subsystem. Why? Is there a reason why it needs its own snapshot capabilities, instead of just using LVM?
These sorts of things always smell fishy to me, due to a feeling that once you start using it, it locks you in more and more until you're doing it all in this new wonderful way that's incompatible with everything else. Even though it's open source, it's still inconvenient.
This approach reminds me a lot of DJB's software: If you try to get djbdns you'll be also strongly suggested to use daemontools as well. The resulting system is rather unlike anything else, and a reason why many people avoid DJB's software.
The point of SL is precisely that it's what you make it to be. SL isn't WoW, in SL all content is user created. Any user can create the scripts and animations required for it. Animations can be created with a program and then uploaded to SL.
A rape can be simulated in SL just fine, but it's stupid to compare it to the real thing. It's most definitely a reason to ban somebody, but for a lawsuit?
In SL, people can make your avatar execute an animation if you give consent. Things that involve animating both avatars, such as a hug for instance, are initiated by one of them, and the other must click "ok" to accept the offer.
Of course they could make it be misleading by presenting it as something harmless and then make the actual thing be nasty, but you can always teleport away, and reset all animations in progress (it's an option in the tools menu). It's not really possible to do something to somebody that they'd be unable to stop.
It's a nice theory, but I've never seen it in practice.
I've seen it in practice on Linux -- my bug report resulted in an email from the developer the next day, and a fix for the bug I found in the next few hours.
Sure you can send reports to MS, but I've never ever seen anything come out of it. If the device manufacturer ever gets around fixing it I won't hear about it, and if MS does fix it I won't notice either -- it'll be quietly rolled into the next service pack that might come out 4 months later, if it gets there at all.
And that still doesn't address what I was talking about, anyway. Yeah, great, the user can click "ok" and get a dump sent to MS. Wonderful. And meanwhile what? An user still can't find out what failed without a developer's asistance, and on Linux those are a whole lot easier to get a hold of, and a lot more responsive. Patches for kernel exploits come out in *hours*.
That still makes it a bad deal. There's absolutely no reason why transferring 100MB of data should cost more than fabricating, packaging, storing, delivering to a shop, displaying and selling a chunk of metal and plastic.
The cost of downloaded music by all logic should be below the half of what the CD of the same stuff costs. Now allofmp3.com had reasonable prices.
Generally I would expect that not needing packaging, delivery trucks, shelf space, etc, would result in the end product being cheaper due to the lack of need to pay for all that stuff... but no, somehow delivering less is a "feature" that makes sense to pay extra money for.
Don't get me wrong, I don't care much for the packaging either, but calling it progress to pay extra for the lack of something is quite bizarre.
I was talking how on Linux it's quite easy for an end user to gather some information for a developer, and determine where the problem is. Chances are they'll get a fix too. Windows specifically makes this difficult because due to the "behavior preferrable for 99% of the users" you mention, guess what? The user never sees anything to report in the first place!
Grandparent said: "Wouldn't it be better that an ill-supported webcam gets abandoned by the consumers, thus giving the market better-supported webcams as manufacturers are forced to lift up their games?".
My argument here is that the way Windows works is utterly unhelpful for the consumer to find out where the problem is. If a driver makes the system crash, they will never see that in the first place. All they see is their computer reboot. Hence they won't have a clue as to what happened, won't even try to ask anybody knowledgeable, and will never find the driver their hardware came with was crap.
I'm not talking about tools available to a programmer, I'm talking about tools available to a normal user. Besides, how does that data help you in Windows when it's of no use to anybody but MS or the hardware manufacturer?
I've actually reported bugs in a few drivers in the kernel, and got mail from the author asking to provide the required details, then a patch with a fix. In less than a week everything was working the way it should.
In Windows though? Good luck getting that sort of service. It's very common for a manufacturer to make hardware, release a buggy driver, then forget about it and go work on something newer. Even if you can get the info that would be needed to diagnose the problem, there's really not much point in it, as MS doesn't care unless it's in their code, and if the manufacturer doesn't care, you're screwed. If you do manage to report a bug and get it fixed, you might finally get it when they release the service pack 4 months later.
See my other post, it's the same thing as with sound cards for instance. Linux doesn't have a driver specifically for the "Creative SB Live Value", it has a driver for the EMU10K1 chip the card is based on. This driver works for several models of the SB Live series, and perhaps even for non-Creative cards if some other company builds cards using the EMU10K1 chip.
This guy wrote drivers that support 253 webcams, not 253 drivers.
Linux isn't Windows. In Windows, a Creative webcam would appear in the device manager as a "Creative Webcam". In Linux, a driver supports the chip the camera uses, not the specific camera itself. Logitech or Creative usually won't be making the whole camera from scratch. Instead, they purchase the electronics from some chinese company, then build their own body around it, and write some software to support it.
In the screenshots it can be easily seen that "Trust", "Canon" and "Logitech" webcams are all supported by the same driver.
In Linux, this is possible. You actually have chances of getting somebody knowledgeable to tell you that the hardware itself sucks (there used to be comments about how much realtek hardware sucks somewhere in the kernel source), or that the driver isn't properly written. Linux also makes it easy to make it possible for people to tell you so: somebody can tell you to run "lspci -v" and "dmesg" and paste it into your mail, which is easy even if you have no clue what all that stuff is.
Windows on the other hand, gets more and more obscure with each passing day. Starting from XP it reboots instead of letting you see the BSOD, so without considerable effort you can't even find what went wrong. You go to make tea, come back, and the box mysteriosly rebooted meanwhile. Windows installations are also often infested with spyware, which makes it a lot harder to figure out what exactly is going wrong, as something going wrong in bizarre ways is depressingly common.
There's also that consumers are simply not informed. Most people don't spend time googling around to try to find out whether the webcam they're about to buy is any good. If they find reviews, often they will be by somebody who tried it for 15 minutes, which will miss any longer term issues. About the only way of a bad one getting abandoned by consumers is that it's such incredible crap that even people with no experience at all see it's horrible and return it.
No, "libre" is "free", not "liberated". There's "liberado/a" in Spanish for that.
"Soy un hombre libre" -- "I'm a free man" "Los prisioneros han sido liberados" -- "The prisoners have been liberated"
"Liberated" has the specific connotation of what something has been made free, which wasn't free before. Both in English and in its Spanish "liberado" equivalent.
Freedom has very specific connotations, while all those confuse the issue quite a lot. Say, independent from what? "Ungoverned", "unruled" and "unsupervised" don't work, take the kernel for instance, which has a very clear structure. "Sovereign" is weird. "Liberated" is probably the closest meaning, but it has the connotation of that it wasn't free before and now it is. That perhaps applies to Blender, but doesn't make sense for software that was Free in the first place.
Non-free software isn't always supervised. If I write something myself, and release it under some draconian license, who is supervising that?
Slashdot Mirror
The main problem with that is that even if SQL was 100% standard, databases still have different behavior. For example, if you tune something for MS SQL Server, performance will suck on postgres and viceversa. If you try to make it run well on both, it'll run suboptimally on both.
For instance: MS SQL Server 2000, as a database that uses locks, likes small transactions. The smaller the better. A long running transaction in MS SQL is potentially troublesome. Big transaction locks row, another connection waits on that, another connection waits on the second one, and so on. Database grinds to a halt until the big transaction is done.
On the other hand, postgres has a high overhead for creating a transaction, but once that's done, the more you do there the better. The same long running transaction in postgres won't create any problems in postgres due to MVCC. Now, if you use postgres where nearly every database query is one sentence in its own transaction, then performance won't be impressive.
And who'd protect this hardware lockdown mechanism?
Without copyright, anybody could pass schematics, specs and firmware dumps around. Any chinese company could manufacture compatible, DRM-less hardware.
Not impossible at all, although not very easy either.
1. Resize the filesystem itself (resize_reiserfs, etc)
2. lvreduce the underlying logical volume
3. pvmove data from the device you want to free up elsewhere
4. pvremove the now free physical volume
Major problems here are the need to resize the filesystem (which may require unmounting it), and that resizing the FS and lvreduce need to be in sync or you get data corruption. It's not ideal, and not as nice as ZFS, but it's definitely doable.
And that's precisely the way I like it. Why the hell should I surrender to the whims of some network card manufacturer? If they don't produce the stuff I want, I'll buy from somebody who does.
Not that MS doesn't do the same, for example by dropping hardware acceleration from DirectSound.
Ok, under LVM, /dev/hda is a physical volume. PVs get grouped into volume groups, then get subdivided into logical volumes.
/dev/hda (which maps to a single hardware device) because nothing stops you from creating a logical volume spanning 4 hard disks. What exactly would a snapshot of /dev/hda in that case be? As far as LVM is concerned, your data is somewhere in volume group, which is a virtual entity made of a number of physical volumes. Your logical volume may span one or several PVs, and doesn't have a fixed location either. You can at any time tell LVM to free up a physical volume and disconnect it.
It doesn't make sense to talk of a snapshot of
No, you may not continue to use
If you're using LVM, you don't mount
Second? A bit of googling suggests qmail was third in 2003: http://www.credentia.cc/research/surveys/smtp/2003 04/0 701/mxsurvey.html
And this survey suggests it's falled to 22nd in 2007: http://www.securityspace.com/s_survey/data/man.20
qmail seems to have been abandoned by DJB, and his licensing requirements mean other people can't fork development, they can only distribute patches for it.
LVM has this already. CONFIG_DM_SNAPSHOT in the kernel config.
If you use LVM, then all devices you put a filesystem on are in
But they aren't identical. LVM works with block devices, it doesn't know about the filesystem. If you do a bit-by-bit comparison of the original device with its snapshot, if the original changed, then there will be differences. The snapshot contains the data it would if you unmounted the FS and make a copy of the device.
Ok, if I understand this correctly, then LVM and ZFS snapshots have different uses.
For me, the main point of LVM snapshots is consistent backups. LVM can freeze any block device in time. The nice thing is that it doesn't have to be a known filesystem. It could be for example a device used by vmware, or a database as-is, with no filesystem on it. A neat application of this is data recovery. LVM can take a writable snapshot of a corrupted filesystem. Then you can try the latest experimental fsck tool on it, without worrying about it breaking something, and not needing to keep a full copy of the data.
ZFS is certainly really neat, but it can't fully replace LVM snapshots, nor LVM can provide what ZFS can.
You don't seem to understand snapshots.
A snapshot works by creating a copy of the device, with the contents it had when the snapshot was created. If you make a snapshot of
Why would you change anything over? Snapshots are temporary. You snapshot your drive, use the snapshot to create a consistent backup (or whatever), then destroy it.
Normally you won't keep a snapshot around for long, as they're maintained by keeping copies of modified blocks, and that takes space. Unless you have enough space for fully duplicating the device you made a snapshot of, you won't be able to keep it around forever.
That sounds like the wrong way to solve the problem. I'd rather solve it in the RAID layer, so that anything using the disk can take advantage.
For instance, vmware can use a block device for a virtual disk. Why should it have to implement its own version of that when it could be implemented in a single place?
Same goes for snapshotting. Why does the FS have to support it? With LVM I can snapshot vfat if need to for whatever reason.
Layers might not be ideal, but they're consistent. The filesystem does its part, RAID/LVM does its own, etc.
ZFS seems to want to take all over the disk subsystem. Why? Is there a reason why it needs its own snapshot capabilities, instead of just using LVM?
These sorts of things always smell fishy to me, due to a feeling that once you start using it, it locks you in more and more until you're doing it all in this new wonderful way that's incompatible with everything else. Even though it's open source, it's still inconvenient.
This approach reminds me a lot of DJB's software: If you try to get djbdns you'll be also strongly suggested to use daemontools as well. The resulting system is rather unlike anything else, and a reason why many people avoid DJB's software.
The point of SL is precisely that it's what you make it to be. SL isn't WoW, in SL all content is user created. Any user can create the scripts and animations required for it. Animations can be created with a program and then uploaded to SL.
A rape can be simulated in SL just fine, but it's stupid to compare it to the real thing. It's most definitely a reason to ban somebody, but for a lawsuit?
In SL, people can make your avatar execute an animation if you give consent. Things that involve animating both avatars, such as a hug for instance, are initiated by one of them, and the other must click "ok" to accept the offer.
Of course they could make it be misleading by presenting it as something harmless and then make the actual thing be nasty, but you can always teleport away, and reset all animations in progress (it's an option in the tools menu). It's not really possible to do something to somebody that they'd be unable to stop.
It's a nice theory, but I've never seen it in practice.
I've seen it in practice on Linux -- my bug report resulted in an email from the developer the next day, and a fix for the bug I found in the next few hours.
Sure you can send reports to MS, but I've never ever seen anything come out of it. If the device manufacturer ever gets around fixing it I won't hear about it, and if MS does fix it I won't notice either -- it'll be quietly rolled into the next service pack that might come out 4 months later, if it gets there at all.
And that still doesn't address what I was talking about, anyway. Yeah, great, the user can click "ok" and get a dump sent to MS. Wonderful. And meanwhile what? An user still can't find out what failed without a developer's asistance, and on Linux those are a whole lot easier to get a hold of, and a lot more responsive. Patches for kernel exploits come out in *hours*.
That still makes it a bad deal. There's absolutely no reason why transferring 100MB of data should cost more than fabricating, packaging, storing, delivering to a shop, displaying and selling a chunk of metal and plastic.
The cost of downloaded music by all logic should be below the half of what the CD of the same stuff costs. Now allofmp3.com had reasonable prices.
Yay for Apple fan logic.
Generally I would expect that not needing packaging, delivery trucks, shelf space, etc, would result in the end product being cheaper due to the lack of need to pay for all that stuff... but no, somehow delivering less is a "feature" that makes sense to pay extra money for.
Don't get me wrong, I don't care much for the packaging either, but calling it progress to pay extra for the lack of something is quite bizarre.
Who said anything about writing drivers?
I was talking how on Linux it's quite easy for an end user to gather some information for a developer, and determine where the problem is. Chances are they'll get a fix too. Windows specifically makes this difficult because due to the "behavior preferrable for 99% of the users" you mention, guess what? The user never sees anything to report in the first place!
Grandparent said: "Wouldn't it be better that an ill-supported webcam gets abandoned by the consumers, thus giving the market better-supported webcams as manufacturers are forced to lift up their games?".
My argument here is that the way Windows works is utterly unhelpful for the consumer to find out where the problem is. If a driver makes the system crash, they will never see that in the first place. All they see is their computer reboot. Hence they won't have a clue as to what happened, won't even try to ask anybody knowledgeable, and will never find the driver their hardware came with was crap.
I'm not talking about tools available to a programmer, I'm talking about tools available to a normal user. Besides, how does that data help you in Windows when it's of no use to anybody but MS or the hardware manufacturer?
I've actually reported bugs in a few drivers in the kernel, and got mail from the author asking to provide the required details, then a patch with a fix. In less than a week everything was working the way it should.
In Windows though? Good luck getting that sort of service. It's very common for a manufacturer to make hardware, release a buggy driver, then forget about it and go work on something newer. Even if you can get the info that would be needed to diagnose the problem, there's really not much point in it, as MS doesn't care unless it's in their code, and if the manufacturer doesn't care, you're screwed. If you do manage to report a bug and get it fixed, you might finally get it when they release the service pack 4 months later.
See my other post, it's the same thing as with sound cards for instance. Linux doesn't have a driver specifically for the "Creative SB Live Value", it has a driver for the EMU10K1 chip the card is based on. This driver works for several models of the SB Live series, and perhaps even for non-Creative cards if some other company builds cards using the EMU10K1 chip.
This guy wrote drivers that support 253 webcams, not 253 drivers.
Linux isn't Windows. In Windows, a Creative webcam would appear in the device manager as a "Creative Webcam". In Linux, a driver supports the chip the camera uses, not the specific camera itself. Logitech or Creative usually won't be making the whole camera from scratch. Instead, they purchase the electronics from some chinese company, then build their own body around it, and write some software to support it.
In the screenshots it can be easily seen that "Trust", "Canon" and "Logitech" webcams are all supported by the same driver.
So how does the market know?
In Linux, this is possible. You actually have chances of getting somebody knowledgeable to tell you that the hardware itself sucks (there used to be comments about how much realtek hardware sucks somewhere in the kernel source), or that the driver isn't properly written. Linux also makes it easy to make it possible for people to tell you so: somebody can tell you to run "lspci -v" and "dmesg" and paste it into your mail, which is easy even if you have no clue what all that stuff is.
Windows on the other hand, gets more and more obscure with each passing day. Starting from XP it reboots instead of letting you see the BSOD, so without considerable effort you can't even find what went wrong. You go to make tea, come back, and the box mysteriosly rebooted meanwhile. Windows installations are also often infested with spyware, which makes it a lot harder to figure out what exactly is going wrong, as something going wrong in bizarre ways is depressingly common.
There's also that consumers are simply not informed. Most people don't spend time googling around to try to find out whether the webcam they're about to buy is any good. If they find reviews, often they will be by somebody who tried it for 15 minutes, which will miss any longer term issues. About the only way of a bad one getting abandoned by consumers is that it's such incredible crap that even people with no experience at all see it's horrible and return it.
No, "libre" is "free", not "liberated". There's "liberado/a" in Spanish for that.
"Soy un hombre libre" -- "I'm a free man"
"Los prisioneros han sido liberados" -- "The prisoners have been liberated"
"Liberated" has the specific connotation of what something has been made free, which wasn't free before. Both in English and in its Spanish "liberado" equivalent.
None of those are really appropiate.
Freedom has very specific connotations, while all those confuse the issue quite a lot. Say, independent from what? "Ungoverned", "unruled" and "unsupervised" don't work, take the kernel for instance, which has a very clear structure. "Sovereign" is weird. "Liberated" is probably the closest meaning, but it has the connotation of that it wasn't free before and now it is. That perhaps applies to Blender, but doesn't make sense for software that was Free in the first place.
Non-free software isn't always supervised. If I write something myself, and release it under some draconian license, who is supervising that?
What does karma have to do with freedom?