Privacy is not synonymous with freedom, or personal sovereignty.
privacy 1.a.The quality or condition of being secluded from the presence or view of others. 1.b.The state of being free from unsanctioned intrusion: a person's right to privacy. 2.The state of being concealed; secrecy.
freedom 1.The condition of being free of restraints. 2.Liberty of the person from slavery, detention, or oppression. 3.a.Political independence. 3.b.Possession of civil rights; immunity from the arbitrary exercise of authority. 4.Exemption from an unpleasant or onerous condition: freedom from want. 5.The capacity to exercise choice; free will: We have the freedom to do as we please all afternoon. 6.Ease or facility of movement: loose sports clothing, giving the wearer freedom. 7.Frankness or boldness; lack of modesty or reserve: the new freedom in movies and novels. 8.a.The right to unrestricted use; full access: was given the freedom of their research facilities. 8.b.The right of enjoying all of the privileges of membership or citizenship: the freedom of the city.
What most people want is not privacy per se, but the right to live their lives they way they see fit -- in other words, freedom in the "liberty" sense, not in the sense of #4 above. Privacy not not a necessary condition for freedom and personal liberty. It is often a by-product of it, but is not a necessary condition. Privacy itself is not a good thing. Who wants the FBI to have a lot of privacy? I don't want to live in a police state where we're not allowed to pull back the curtain and see what the government is doing. The government is us, and as such we should be able to know what it is dooing to who. It should be accountable to us, the people.
As technology becomes more sophisticated, and as we grow more dependant on it, and people in power want to have their provacy while removing yours, then loss of privacy for individuals is inevitable. The best defense is not to fight it, but to turn it to your advantage. Turn the camera back on the cameramen. Don't give your DNA to the insurance company. Or if you do, demand that the officers of that corporation make available their DNA records to its customers.
It's always a good idea to include in any debate over privacy the idea of a bilateral loss of privacy. Debates are almost always make the assmption that those in power will retain their privacy, while those not in power will lose. It doesn't have to be that way.
David Brin and you seem to make the assumption that the government can be made transparent and accountable only if the citizens' privacy is destroyed as well.
Umm... no. David Brin's premise, which I am also using, is that technology combined with power is and will erode personal privacy, and there's nothing we can do about that. You can't un-invent technology, and outlawing it creates the police state we want to avoid. Given that erosion of privacy is going to happen due to the technology existing and the will of those in power to use it, we need to re-think how to defend ourselves. The answer is, turn the cameras back on the cameramen.
But the FBI, CIA, etc, are "voyeurs" with the power of the legal system (i.e., the ability to use force, including deadly force) to back them up.
We're not talking to private citizens here. We're talking about people in power. Wouldn't you like to see your FBI file? Shouldn't you be able to? I'd say yes. What right does the FBI -- even though it is composed of citizens like us -- have to spy on you in secrecy, and carry out covert operations that affect your life using that information, with impunity?
It's not at all about "misery loving company" as you said. It's about accountability. The U.S. government is supposed to be "of the people, for the people". Power ultimately rests with the people, not the government. If we're the bosses, why can't we check up on our employees?
I'm all in favor of giving law enforcement all the tools they say they need and they say they want under one condition: The more they get, the more light shines into them. I would be in favor of drafting random groups of citizens, 12 at a time, juries, and giving them a pass that lets them walk through any door in FBI headquarters at any time and listen to any conversation they want. If the FBI wants to be able to listen to us, then we should have people who we trust, members who've married our kids, members of our civilization and not part of the old-boy network, who will go in and verify - who will watch the watchman? If they are being watched then we'll be free, and I don't give a darn what the FBI knows about me, if I know what brand of toothpaste the head of the FBI uses. That's the fundamental thing: Can we shine light on the mighty?
JM: Some privacy groups have suggested a privacy commission to sort of oversee this sort of thing.
DB: Oh, big government agencies become powers unto themselves. I prefer the ad hoc jury. I prefer that several hundred little ad hoc juries of Americans be cut loose with little red passes that let them walk through any door in our government and see anything. And before they get co-opted the pass expires, it only lasts for six months. And as much as possible, let us see. As I said in my City A and City B, the difference between those two cities is not the numbers of cameras. Cameras are coming. There's no avoiding it, there will be cameras outdoors everywhere we go. The question is, will we as a citizen be able to use them. That guy who almost knocked you off the freeway, who almost killed you the other day by running you off and then gave you the finger and laughed driving away. Wouldn't it be great if your car automatically recorded the episode and you dialed in and showed the scene to his mother?
Have you actually set an X resource in your life? Motif can be *made* to look nice. Simply because it isn't by default, like GTK+ is, doesn't mean that it is crap.
Bloatif IS inferior. Take one look at a list box with more than a screenful of options. It certainly DOES capture the "visual elegance" of Windows 3.0, though... Motif is bloated, difficult to program for, expensive, and ugly.
No myth. X renders all fonts into BITMAPS, and programs use the BITMAPS. That makes, among other things, printing pretty screwed up.
---- ----
Re:Someone obviously doesn't understand X ...
on
X Windows Must Die!
·
· Score: 2
X has shortcomings. Its only real strength is remote display. Nearly everything else -- drawing model, font support, speed, complexity/bloat/instability -- is NOT good.
VNC is faster than X over a slow modem. I regularly use Xvnc and a remote VNX client, because it works better. It's faster, platform-independant, and I can reconnect without losing work. If my modem hangs up, a true remote-X session kills all of may apps. Crufty.
Yes, X IS bullcrap. I'd like a system than can support modern display and media technologies, not a 20 year old bloat-o-vision that still forces use of bitmapped fonts and doesn't allow any sort of compositing, etc. X sucks!
The GOOD things about X can be provided for in other display systems. The main good thing about X is remote display. So Berlin uses GGI which can rener to the VNC protocol. Done.
Ah, but "temporary inclusion of the *@!#^* ->read_inode2()" is different than changing read_inode() itself, and actually providing decent functionality in the VFS rather than just including hacks. For instance, why not read_inode() with NULL as the second argument rather than read_inode2?
Granted Hans can be a little incendiary. Often the manner of presentation can overwhelm what is said, as with Hans calling Viro an asshole and Viro calling everyone whiners/wankers/etc.
What paranoid conspiracy theories? HANS has said that there's a "RedHat Conspiracy." I've said no such thing, because I don't think there is. WTF?
So you're saying that if Reiser re-submitted that same code outside the rest of the fs driver, it might be accepted? Oh, and removed the "hack comment?"
It's because the VFS function isn't capable, and isn't being fixed, that he had to add a second function to do the same thing,
Granted, Reiser has some problems with presentation... but it's not like ideas and even actual, working code have not been supplied.
Lots of empties. But anyway, why should the VFS know about specific details of other filesystems? Does it provide an advantage to those filesystems? Give us your thoughts, please. I.e., answer the questions. In case you haven't noticed, people aren't just harshing on poor Viro -- we actually want to know the answers to some questions! I.e., we're willing to engage in constructive dialogue. Why is there a big, ugly union in the VFS rather than having all filesystems use the generic pointer? Why is not not silly to require the VFS to understand FS-specific data? For control? Or is there a valid technical reason that it's better, at the expense of making otehr filesystems do ugly hacks?
Why do you think soft-updates are better then journaling? I really want to know. Someone else said that the "generic journaling" is really just going to be a way to deal with making sure inodes and transactions play nice. Is that true? Or what? You still haven't answered the question. Will the generic journaling turn out to be Ext3 journaling, or not? If not, what will it be?
Heh. Erez Zadoklike a friend of mine named Cyrus. His FiST stuff looks interesting; I looked it over several months ago. But back to my question, Why can't the VFS be made stackable and extensible? Or to phrase it taking your reply into account, why must an add-on kit be used? Do you not want to do it in the VFS itself? Why? Why not? Can you please answer the question?
You patch filesystems when you patch the VFS, was my understanding. So if you change the VFS to remove the union, as you said in your answer to #1, then what would you do? If someone wrote that patch for you, and went ahead and patched all the other filesystems to make it easier to deal with, what would you do? It has everything to do with the VFS, if you remove the union. You still didn't answer the question.
yeah, you're not Linus. But what percentage of your patches do get accepted, and how much debate and review do they go through before hand? Open question to Linus: so, what "technical merits" must a patch exhibit before you will include it? And is there any plan to provide open future-design docs?
Yeah. A little. So little as to almost not matter. Your attitude is still "read Ext2." Which pretty much clashes with your answer to #4. If you don't patch filesystems yourself, then why do you always tell people that Ext2 is the reference documentation for the VFS? Presumably you're keeping it up to date with your VFS changes.
The VFS is being used in more places -- shared memory, for instance. As it becomes more important to more kernel systems, should it not be made more flexible and documented better? Next year, each of your VFS patches VFS will break even more stuff. If the VFS had a cleaner interface, and better design docs and roadmaps, then VFS changes would not be so much of a problem. Do you agree that the VFS needs a cleaner, more capable, less frequently changed, better documented interface? Or not? Why in either case?
On 2: that would be good. There's problems with clsoed inodes in open transactions. If that's all that's meant by a "generic journaling layer," great.
Not cross-purpose. As the VFS spreads throughout the kernel, more things will have to interface with it. To avoid repeatedly hammering square pegs in round holes, the VFS needs to be made easier to work with.
The 'extensions' can be as flaky as they want to be, but they wouldn't be part of the VFS. That's the whole idea.
I'm not talking about modifiying VFS semantics on a whim. I'm talking about making it possible for users of the VFS to implement their systems without kludging around limitations in the vfs.
Documentation: yeah, a good thing. Documentation in advance is a good thing, too, even in "bleeding edge development." How about a little planning?
Agenda? I want Linux to be a good OS. The preferred, default Unix. I want it to have a journaling filesystem. I want it to be neutral and not favor some systems over others -- and as long as the VFS is Virtual Ext2, it will favor some over others. The whole idea of open-source an Linux is that we have freedom - a choice. When choice is artificially limited by poor design choices and stonewalling, then we've lost some freedom.
I wasn't trying to be venemous, but I was a little irked by Yet Another Viro Post to the effect of "shut up, read the code, and leave me alone."
You can learn the kernel and start submitting patches that would be acceptable to Linus on their technical merits. That's how it works. I would be glad to see anyone joining the VFS/fs work.
Umm... bullshit. That's not how it works. In reality, you do whatever you want, while criticizing everyone else for not being able to work inside your VFS. Address the real issues, Viro! Stop complaining and trying to change the topic!
Why is there a big, ugly union in the VFS rather than having all filesystems use the generic pointer? Why is not not silly to require the VFS to understand FS-specific data? For control? Of is there a valid technical reason that it's better, at the expense of making otehr filesystems do more ugly hacks (HFS as well as Reiser)?
Why do you think that "generic journalin" is a good idea? Will the generic journaling turn out to be Ext3 journaling, or not? If not, what will it be?
Why can't the VFS be made stackable and extensible?
If someone submitted a patch for all current filesystems to make them use the generic pointer, and did away with the union, would you take it? Why or why not?
What kind of technical merits make a patch acceptible to Linus? If it really Linus that's the bottleneck here?
what evidence is there that you actually would be glad to see anyone joining the VFS/fs work? Your behavior so far has been defensive, hostile and arrogant. I'm not discounting all the work that you've done -- thank you -- but why do you have to make it so hard to work with you? If you provided a few design documents, people could leave you alone a lot more. With your "read the code, whiner" attitude, everyone has to plow through your latest breaks-everything undocumented patch to figure out how to conform again. If people had ANY inkling where you were going beforehand, they could be a little less reactive (and reactionary).
The VFS is becoming more and more important to the Linux kernel, with shmfs, devfs, etc. It's turning into the Plan9-ing of Linux, which is a good thing. So why shouldn't it be more capable and extensible?
Answer our questions and provide design documents/criteria/roadmaps/etc or keep wanking - nobody can deprive you of that right.
All good and well for a single userspace program designed to meet specific, limited needs, but the kernel msut support all programs. If the kernel limits something, there's no way around it, w/o forking Linux.
The kernel is like a common carrier. It shouldn't mandate only certain types of development, but seek to be as extensible and flexible as it can.
Incidentally, the suggested changes to the VFS won't prevent existing filesystems from working. it'll just make it easier to develop new ones, and make non-Ext2 filesystems more efficient (because less kludging will have to be done).
If Linux development becomes limited and closed off, people will go somewhere else. I can't wait for the Hurd ot come out and provide a little competition in the GNU space... competition good... regis bad... heh
A "common journaling api" is not a good idea. It will force all journaling filesystems to look like whatever journaling is chosen to add to the vfs. It'll be the same situation we have now, taken to the next level. Currently, for filesystems to work well in the kernel, they have to either be Ext2, or be made to look like Ext2, because the VFS in its current state is really a "Virtual Ext2 Filesystem". If a common journaling framework were to be added, as Viro has suggested, than I imagine all filesystems would then need to look and work like Ext3 to operate properly. Plus, FSes that don't need or want journaling would still have the bloat. Journaled ISO9660? Journaled Fat? WTF?
So if there is a problem with ReiserFS conforming to the current VFS layer then ReiserFS should be adapted
Problem is, ReiserFS cannot "adapt." There's fundamental limitations in the VFS, like in read_inode() for example, that prevent filesystems more complicated the Ext2 (i.e., any filesystem designed more recently than 1975) from working well, or at all, without patching the VFS.
I imagine XFS, JFS, and other more advanced filesystems are having to work around the same problems, because they cannot be made to look like Ext2. HFS -- a filesystem in the kernel already -- has to do a lot of workarounds. I can't imagine doing a full NTFS is possible with the current VFS, because the VFS makes it difficult to impossible to pass a context around with inode requests (for security, for example).
These aren't changes asked for "on a whim." They're changes that will benefit current filesystems and make it easier to add new filesystems. The VFS, if it were truely virtual, would not need to be patched to support new filesystems. As it is, there's a big union of filesystem-specific data in the VFS. It's silly to have specific filesystem info hardcoded in the VFS. Not very virtual, is it?
The VFS needs to provide a clean, extensible (stackable), implementation-neutral interface for filesystems.
Slashdot Mirror
As technology becomes more sophisticated, and as we grow more dependant on it, and people in power want to have their provacy while removing yours, then loss of privacy for individuals is inevitable. The best defense is not to fight it, but to turn it to your advantage. Turn the camera back on the cameramen. Don't give your DNA to the insurance company. Or if you do, demand that the officers of that corporation make available their DNA records to its customers.
It's always a good idea to include in any debate over privacy the idea of a bilateral loss of privacy. Debates are almost always make the assmption that those in power will retain their privacy, while those not in power will lose. It doesn't have to be that way.
---- ----
David Brin and you seem to make the assumption that the government can be made transparent and accountable only if the citizens' privacy is destroyed as well.
Umm... no. David Brin's premise, which I am also using, is that technology combined with power is and will erode personal privacy, and there's nothing we can do about that. You can't un-invent technology, and outlawing it creates the police state we want to avoid. Given that erosion of privacy is going to happen due to the technology existing and the will of those in power to use it, we need to re-think how to defend ourselves. The answer is, turn the cameras back on the cameramen.
---- ----
But the FBI, CIA, etc, are "voyeurs" with the power of the legal system (i.e., the ability to use force, including deadly force) to back them up.
We're not talking to private citizens here. We're talking about people in power. Wouldn't you like to see your FBI file? Shouldn't you be able to? I'd say yes. What right does the FBI -- even though it is composed of citizens like us -- have to spy on you in secrecy, and carry out covert operations that affect your life using that information, with impunity?
It's not at all about "misery loving company" as you said. It's about accountability. The U.S. government is supposed to be "of the people, for the people". Power ultimately rests with the people, not the government. If we're the bosses, why can't we check up on our employees?
---- ----
---- ----
---- ----
No myth. X renders all fonts into BITMAPS, and programs use the BITMAPS. That makes, among other things, printing pretty screwed up.
---- ----
X has shortcomings. Its only real strength is remote display. Nearly everything else -- drawing model, font support, speed, complexity/bloat/instability -- is NOT good.
VNC is faster than X over a slow modem. I regularly use Xvnc and a remote VNX client, because it works better. It's faster, platform-independant, and I can reconnect without losing work. If my modem hangs up, a true remote-X session kills all of may apps. Crufty.
---- ----
No, we don't want windows. You can have themes without X.
---- ----
Motif is beautiful
Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha!
---- ----
Yes, X IS bullcrap. I'd like a system than can support modern display and media technologies, not a 20 year old bloat-o-vision that still forces use of bitmapped fonts and doesn't allow any sort of compositing, etc. X sucks!
The GOOD things about X can be provided for in other display systems. The main good thing about X is remote display. So Berlin uses GGI which can rener to the VNC protocol. Done.
---- ----
Who are you?
t h+threat%22&num=10&meta=hl%3Den%26lr%3D&sa fe=off&btnG=Google+Search
Talk about attitude...
http://www.google.com/search?q=coca+cola+%22dea
77 hits... lol
Lol!
+ %22death+threat%22&num=10&meta=hl%3Den%26l r%3D&safe=off&btnG=Google+Search
http://www.google.com/search?q=anonymous+coward
.. 13 hits
blah. He's probably the right person, for the very reasons you say he's the wrong person.
RMS, as far a business is concerned, is a nut job. ESR shows them that GNU is not a communist conspiracy and can be a good thing.
1. So? It's still ugly. Viro's the maintainer. And I'm sure there will be patches submitted.
2. Yuk. Let's end "transactions" randomly! Whee!
1b,2b,3-5+7. Well, I felt free before, but thanks. Who are you, anyway? I'll try to answer your points? That's answering?
6. Who cares about ReiserFS and whether you like it? I'm talking about making the VFS more useful. Reiser's just an example of a FS with VFS problems.
Thanks, Viro. Cola's misguided ranting aside, I want to see Linux improve because I like it.
Out of curiousity, why does Linus not want to use CVS?
Are You Hans's stooge?
Hahaha! Why? Are you Viro's?
Sheesh.
Because there seems to be a lot of trouble, attitude and stonewalling in the vicinity of A. Viro.
Great! Zappe might be doing that as well. Perhaps you two can talk...
Ah, but "temporary inclusion of the *@!#^* ->read_inode2()" is different than changing read_inode() itself, and actually providing decent functionality in the VFS rather than just including hacks. For instance, why not read_inode() with NULL as the second argument rather than read_inode2?
Granted Hans can be a little incendiary. Often the manner of presentation can overwhelm what is said, as with Hans calling Viro an asshole and Viro calling everyone whiners/wankers/etc.
What paranoid conspiracy theories? HANS has said that there's a "RedHat Conspiracy." I've said no such thing, because I don't think there is. WTF?
So you're saying that if Reiser re-submitted that same code outside the rest of the fs driver, it might be accepted? Oh, and removed the "hack comment?"
It's because the VFS function isn't capable, and isn't being fixed, that he had to add a second function to do the same thing,
Granted, Reiser has some problems with presentation... but it's not like ideas and even actual, working code have not been supplied.
On 2: that would be good. There's problems with clsoed inodes in open transactions. If that's all that's meant by a "generic journaling layer," great.
Not cross-purpose. As the VFS spreads throughout the kernel, more things will have to interface with it. To avoid repeatedly hammering square pegs in round holes, the VFS needs to be made easier to work with.
The 'extensions' can be as flaky as they want to be, but they wouldn't be part of the VFS. That's the whole idea.
I'm not talking about modifiying VFS semantics on a whim. I'm talking about making it possible for users of the VFS to implement their systems without kludging around limitations in the vfs.
Documentation: yeah, a good thing. Documentation in advance is a good thing, too, even in "bleeding edge development." How about a little planning?
Agenda? I want Linux to be a good OS. The preferred, default Unix. I want it to have a journaling filesystem. I want it to be neutral and not favor some systems over others -- and as long as the VFS is Virtual Ext2, it will favor some over others. The whole idea of open-source an Linux is that we have freedom - a choice. When choice is artificially limited by poor design choices and stonewalling, then we've lost some freedom.
I wasn't trying to be venemous, but I was a little irked by Yet Another Viro Post to the effect of "shut up, read the code, and leave me alone."
Umm... bullshit. That's not how it works. In reality, you do whatever you want, while criticizing everyone else for not being able to work inside your VFS. Address the real issues, Viro! Stop complaining and trying to change the topic!
Answer our questions and provide design documents/criteria/roadmaps/etc or keep wanking - nobody can deprive you of that right.
All good and well for a single userspace program designed to meet specific, limited needs, but the kernel msut support all programs. If the kernel limits something, there's no way around it, w/o forking Linux.
The kernel is like a common carrier. It shouldn't mandate only certain types of development, but seek to be as extensible and flexible as it can.
Incidentally, the suggested changes to the VFS won't prevent existing filesystems from working. it'll just make it easier to develop new ones, and make non-Ext2 filesystems more efficient (because less kludging will have to be done).
If Linux development becomes limited and closed off, people will go somewhere else. I can't wait for the Hurd ot come out and provide a little competition in the GNU space... competition good... regis bad... heh
Problem is, ReiserFS cannot "adapt." There's fundamental limitations in the VFS, like in read_inode() for example, that prevent filesystems more complicated the Ext2 (i.e., any filesystem designed more recently than 1975) from working well, or at all, without patching the VFS.
I imagine XFS, JFS, and other more advanced filesystems are having to work around the same problems, because they cannot be made to look like Ext2. HFS -- a filesystem in the kernel already -- has to do a lot of workarounds. I can't imagine doing a full NTFS is possible with the current VFS, because the VFS makes it difficult to impossible to pass a context around with inode requests (for security, for example).
These aren't changes asked for "on a whim." They're changes that will benefit current filesystems and make it easier to add new filesystems. The VFS, if it were truely virtual, would not need to be patched to support new filesystems. As it is, there's a big union of filesystem-specific data in the VFS. It's silly to have specific filesystem info hardcoded in the VFS. Not very virtual, is it?
The VFS needs to provide a clean, extensible (stackable), implementation-neutral interface for filesystems.