What an absurdity. You are talking about compact simple functions. What we are talking about are fundamental changes involving perhaps 10-15 million lines of code.
Okay, I call bullshit. At this point, you absolutely have to be either trolling or uninformed.
What on *Earth* are you talking about? What piece of software, what project, is hit by a 15 million LOC impact to add *any* feature, no matter how major? Every single project in Red Hat Linux added together has on the order of 30 million lines of code. Windows NT, the entire distribution, had about 10 million, and Windows 2k under 30 million, IIRC. The Windows kernel doesn't even begin to approach the kind of LOC count you're talking about. Let's look back at your first post:
So this is what is MS thinking: implement the things that FOSS world can't do thanks to its red-tape laden world-view. Implement a filesystem layer that provides nifty functions that while aren't new are new in this scale.
And you're talking about a lousy metadata-using filesystem taking that much? Man, a basic filesystem under Windows takes a lot more code than a basic filesystem under Linux, but Linux's ramdisk filesystem is 183 LOC. I doubt that WinFS breaks 100K LOC, much less 15 million LOC.
As for new filesystems, I suggest that you might want to reconsider Linux doing a poor job of competing with Windows. ls/usr/src/linux-2.6.8.1/fs|grep fs$|wc results in 29 filesystems. How many filesystems does a Windows box support? FAT, FAT/w/DOS-naming, NTFS, CIFS? And you're complaining about a lack of people adding new features?
I think that they might be the most *popular* vendor of a number of things, but still not the first to market No, you are not following me. I am talking about taking things that are mature, and making them accessible to the masses. FOSS hasn't done that widely, except perhaps FireFox, and a few P2P clients. What FOSS software is in daily use by millions of desktop users?
So basically, your reason for saying that FOSS is "red tape-laden" -- I just want to get this straight -- is because there is a minimal number of FOSS projects that:
*) Run on Windows.
*) Have a large installed base.
Your arguments for existing, installed base doesn't say a thing about maturity or ease of use which you've flipped to. Take, for instance, Rosegarden. Quite usable music composition software. Not used by "millions of desktop users, however."
Because that explains a lot. I was saying that you were talking about a large installed base, and it seems that you *were*. Don't get me wrong. I think that Microsoft is *very* talented when it comes to sales, marketing, and business relationships leveraging a monopoly. That can buy them a lot of desktops. The thing that I take issue with is that you're claiming that FOSS can't get new features out to users, which is patently absurd. Yes, when Microsoft bundles a new feature into the next release of Windows or Office, it will reach a lot of users -- because a lot of people use Windows or Office!
As a Linux software developer, can you claim that?
Nope. Let me bundle my software with Windows, have it installed on a vanilla box, bootstrapping off of an existing monopoly, and we can talk again.
Except that your cross-platform ideas involve the time-consuming and error-prone problems of cross-compiling.
Time consuming? I don't know what the internal Red Hat build procedure is, but I'm sure that it's automated. Gentoo *definitely* is automated -- it's easy for someone to just say "I'm PPC, suck down the latest binary packages built by Gentoo.
As for error-prone -- the kinds of errors that turn up when you move across platforms (generally when someone's using C), like shoving pointers into ints and relying on a certain form of packing, are the kind of problems that would turn up anyway on a single
I think the problem is that this guy took contributions for years to a piece of software that was GPLed, and then claimed that the people contributing didn't think that their patches were "GPL", as they didn't explicitly specify them. Instead, he is using their code unless they explicitly tell him to remove it.
I would be very, very angry if someone did this to my code. There is a very clear and well-understood principle that when you are contributing code to a single-license GPLed codebase, that you expect your patch to be GPL. You don't have to slap a license on each patch -- it would be a huge hassle otherwise.
Zed needs to go back to CVS, eliminate every line of code that he cannot personally verify that he wrote, and start from *there*. If he wanted to relicense, he needed to either (a) ask each new contributor to explicitly give him copyright and/or license their code under a non-GPL license, as the FSF does, or (b) ask *all* contributors *ahead of time* whether they would like to relicense.
Frankly, this is bullshit. It is an abuse of the work and effort that others put into that piece of software. If XChat wasn't going to be GPL, it would, quite frankly, not be the official GNOME IRC client and people would have spent time working on other clients.
Let me ask you a question. If you had something was truly revolutionary under your hat. You thought it up, coded some proof of concepts. Bamo. Brand new. Big time stuff, what would you do with it? How long would it take to go from your idea to the average user?
[shrug] I came up with an idea for a simple and peppy substring searching algorithm that's currently used in a popular piece of P2P software. The period of time between when I came up with the idea and when it shipped in SuSE? I dunno, it was whenever the next SuSE release came out.
I have never claimed they invented anything. I am saying they brings things *to the market* way before anyone else.
I don't even think that's the case. I think that they might be the most *popular* vendor of a number of things, but still not the first to market. I'll strengthen my initial claim to cover "first to the consumer". List a couple of major things that Microsoft was the first to get to the consumer.
What percentage of applications of Open Source applications are running on virtual machine. Sun promised the world this a decade ago.
The point of running on a VM is largely that it allows cross-architecture compatibility. This was a huge deal for Sun, because SPARC has been a minority architecture for a long time, and it eliminates a major barrier to use of their platform. However, in an open source world, it doesn't provide nearly as much a benefit, since most software can just be rebuilt -- Red Hat just sets the --target option and rebuilds for IA64, PPC, i386, or whatever. The main remaining benefit is that it lets you conduct some finely-grained sandboxing, and even so a lot of that can be done under Linux through use of chroot and other sandboxing mechanisms. The problem is that a VM means a lot more for closed-source vendors than it does open-source vendors. Software targetting VMs requires more memory and runs slower than native software.
Now, there are certainly FOSS VMs with bytecode that exist: rep, emacs, bochs, plex86, python, ocaml(in bytecode mode), and kaffe, off the top of my head. Some of these have been around for an awfully long time -- emacs is probably the oldest virtual machine still in active use, and has a hell of a lot of software written for it. My mail client for a long time, the confusingly-named vm, was emacs-based.
Here comes MS delivering binary compatibility via a VM. Wow. And they are poised to do it again, and completely nail Linux in the process.
Dan, I *already* have cross-architecture compatibility with native speed and memory use. The only piece of binary software I can think of that I have is the RealPlayer library. Heck, I've co-developed software with a buddy who did his work on a PowerPC laptop. There's no need to resort to an emulation-based system.
When Longhorn and its technology hits in the next two years, developers will be drinking the cool-aid full-on. It's the ultimate in lockin: make developing apps so much more effective and efficent that you don't want to switch platforms.
Dan, in my day-to-day use, I simply write software as I work, as I use perl one-liners and zsh constantly. How can it be as easy and simple as that?
The only area that I've found MS's dev tools to be really nicer than Linux has been in RAD GUI tools for C++-targeting platforms -- and I *haven't used* the big popular Linux RAD GUI Qt Designer, just glade targetting gtk--.
Avalon/XAML
Hell, I just mentioned that I did GUI building with XML on glade on Linux, and have been for some time. It's nice that MS is modernizing their APIs, but Apple's already done so, and glib/gtk/gnome and qt/kde have been around for quite some time now. And I agree that having a modern layout engine with data-based layout descriptions is nice, but Microsoft is the last to the party on each of these.
WinFS
WinFS isn't shipping, and metadata-based storage is nothing particularly new. A num
Again, I see these as privacy issues. They should be corrected before and long term solution is approved.
I agree. My problem is that I am quite comfortable in the belief that this sort of thing *will* be okayed without the problems being fixed. I was not happy with the revelations in the Diebold fiasco, and I'm not thrilled in letting anything similar happen any time soon.
I also believe that our troops should not be denied the right to vote if they (like myself) were not really concern over who saw the ballot.
I don't understand why people keep talking about denying soldiers their vote. Cycle them through a poll booth at their base over a weeklong period. I can't believe that it's not possible to manage to get every soldier to go through a base at that rate. Set up a polling booth remotely if it's absolutely necessary if there's a large concentration of soldiers out-of-base.
I'm not selling my vote and I don't fear retibution. Soldiers who share these feels could be denied the right to vote inspite of it.
The problem I have is (a) If you're right that the alternative may be not voting, soldiers may lose their vote if they choose not to use a secure system. (b) There is obviously going to be some pressure to use such a system. People tend to underestimate risks -- for example, I doubt that someone is going to swap out my ballot, but that sort of thing has happened many times in the past to other people. (c) If a less secure but cheaper system can be made to operate for a few years, and nothing breaks, there is a tendancy to want to move to that system. It's the same thing that makes high school kids drive with a couple of beers in them. I'd *much* rather be safe than sorry.
And someone could have had a gun to my head when I was filling out my absentee ballot in '96. So based on this reasoning, we really can't do any absentee ballots. All citizens in remote locatations are automatically disenfranchized.
You're right, of course, but I also don't know of any mass groups of people that fill out absentee ballots in one place. A vote here and a vote there isn't all that useful. And a gun to someone's head is kinda hyperbole -- remember the Deep South in Jim Crow days, where voting took place on an open platform, and there were just a bunch of toughs that would stand and watch you vote.
Florida says your wrong. I'll forgo the debate about whether people do verify the hole or care enough to read the directions about how to use ballots. I can verify the card at least has the hole I intended, but that doesn't stop someone from later invalidating my vote by creating more holes. That wouldn't create a vote, it would simply takes my vote away.
You're right that physical voting isn't perfect, but I'll also say (and this is coming from someone with a significant reason for wanting to justify computer voting, as I work with computer security) that it's a lot more difficult to punch extra holes in 10K ballots without anyone noticing than it is to modify 10K ballots in the processing on a mail server somewhere.
When we can provide all the guarantees, we should provide them. If we can, unlike some, I lean towards letting them decide if they are concerned with the guarantees that cannot be provided, rather than just saying "Sorry, no vote for you. Back to the front with you."
I'd promote the alternate route -- if we have to negotiate a week-long ceasefire to do voting, I'd go for it. I'd rather just cycle soldiers through -- how likely is it, on a modern battlefield, that someone will be pinned in place for an *entire week*? Heck, if you have to, just equip a Huey or something with a voting booth and fly it around from location to location, and just arrange to pull troops out long enough to vote. Fighting is important, but no country is going to crush the United States because a platoon of soldiers was swapped out for a day to take part in voting.
It doesn't eliminate anonymity other than to say "this (faxed) vote comes from a soldier, and this does not".
It could *theoretically* eliminate voter verifiability, but that would require producing modified fax machines at an image-processing level capable of recognizing a voting card, modifying the image, and transmitting it. While not impossible (and I prefer the physical cards be used), this is still difficult enough that I don't worry about people doing it. It would take much more than two lines of code inserted by a malicious programmer that would allow compromise of an email-voting or similar system.
Anonymity is missing because the remote computer *must* know who you are to verify your encryption key (and to route your recipit back). Our current system is specifically designed to prevent authorities in the voting process from being able to determine who voted for who.
Voter verification is missing because the remote machine that you are talking to may tell the people taking the final tally "your vote is Republican" when you really tried to vote Democrat. There's nowhere, short of physical theft and replacement with new ballot cards, which can be reasonably well defended against, that you can pull this off with traditional ballot cards.
What I want to know is why posts that criticise commercial software are classed as Interesting or Insightful
[sarcasm]This is because most people on Slashdot hate and have avoided open source software, and having their eyes opened is enlightening.[/sarcasm]
I do wonder what's wrong with the parent though. I mean it really is a right royal pain in the ass whenever you try to connect a device to Linux machine. Will it work or won't it work? Can I get the drivers? Or has Linux improved in this regard?
The *only* device I have that isn't supported out-of-box on Fedora is my SmartHome X10 USB transciever. SmartHome doesn't give out any technical specs, and the thing had to be reverse-engineered by the author, and the driver's never been included in the mainstream kernel. Frankly, I suspect that the controller isn't supported out of box on Windows either, though I could be wrong.
It would be a very bad idea to incorporate updatedb into the filesystem. This would make db functionality filesystem dependent, and make filesystems much more complicated. Unnecessary complexity in the filesystem is as bad as unnecessary complexity in the kernel -- you screw up, your data goes away. It also makes it harder to do things like upgrade your indexing system then.
It is pretty much unacceptable to run updatedb in sync with file changes. If you do this, it means that all disk writes take a performance hit. Linux is about fast, fast, fast serving.
The best solution, and the one that I've poked at, is the idea of running updatedb asynchronously with partial database updates triggered by change. This means that when you write to a file, it doesn't *immediately* update the database, but it schedules that file to be updated in the database. Unfortunately, Linux currently lacks important functionality to do this. Currently, you need to open and call the Linux syscall dnotify() on every directory in a filesystem to receive updates when a file changes. This uses massive amounts of file descriptors -- the dnotify() model is simply not designed for monitoring an entire filesystem. Fam and other utilities that sit on dnotify() implement recursive behavior using either polling (inefficient as well) or a massive number of monitored directories. If Linus would merge this patch (which may require additional testing and hacking, not sure), dnotify() could handle filesystem-wide recursive directory monitoring *and* inform as to which file is actually changed -- currently, this always requires polling (extremely expensive when many files are in a directory) because the monitoring application only gets a notification for the directory containing the modified file.
Then, the updatedb daemon can simply log a copy of the fact that the file is changed, and either start updating immediately (but in an asynchronous fashion) or wait until the load drops a bit. If you do things like folding (if I have ten thousand entries starting with/usr/shared/gcc-support/sbin/", I just fold all these into one entry and scan the entire hierarchy below that point), you don't really have to worry about backlogging.
I am curious as to what happens when the signal queue is fully backlogged in Linux -- whether dnotify() events are dropped, or whether the file-changing application simply blocks on its operation.
So this is what is MS thinking: implement the things that FOSS world can't do thanks to its red-tape laden world-view.
I don't know what FOSS projects *you've* been working on, but most that I can think of move *much* more quickly than closed source projects. Linux has pretty much become the standard for advancement in the *IX world and has generally surpassed Windows from a kernel-level performance standpoint. P2P software is one of the fastest-moving areas around, and it's largely FOSS. When I want to add a feature, I do a patch and send it to a mailing list. It's pretty easy.
And you're using Microsoft as an example of technical innovation? Come on...there are closed source vendors that come up with new ideas, but I'd like to hear you name five original Microsoft *technical* (not business) ideas. Microsoft hasn't ever been a technical leader -- just a business leader.
If something like this is done, it should absolutely not be done at the filesystem level, but by something that hooks in directly above (if Linux ever gets the enhanced recursive dnotify() patch added to the mainstream kernel, it could have such functionality). It's ridiculous to try to tie it to a particular filesystem when there's no reason to do so.
The good thing about Linux is that when all this stupid cruft and dumb design overwhelms the filesystem, the 90% of people that promptly realize that "replace the filesystem with a database" is a bad idea can simply use another filesystem. Those on Windows may not have that luxury.
The problem with email voting is not that someone might sniff and read your email on the way, or even falsify votes. Those are pretty easy to fix. The problems are those of:
* Loss of anonymity. This is an important characteristic that prevents vote-buying or reprisals against people who vote "incorrectly" (since there's no way for a political party to find out who voted which way). If you're sending via an email system, and the system is secure, it's a pretty damn good bet that you're exposing your identity (via signed, encrypted email or whatnot).
* Loss of the local privacy guarantee. Voting booths are secured. Who might be looking over your shoulder when you vote?
* Loss of the non-coercion guarantee. If I can just fire off an email, someone can have a *gun* to my head forcing me to vote a particular way.
* Loss of a controlled voting environment. How many Outlook worms does it take to convince people that email clients and desktop systems just aren't all that locked down?
* Loss of voter verifiability. With a paper ballot, I can verify that the card contains the hole that I punched in it. Short of physically substituting cards (something that's a hard to do and much easier to guard against), someone can't attack your vote data. With e-voting, there are a huge number of places to allow a different vote to be submitted than what you wanted -- in the client OS, in the client email system, in the vote-counting system, etc, etc, etc. There are a *lot* of programmers that can be bought off or act in a partisian manner -- and any one can compromise the entire system.
I do think that the men and women dying for our country should have the right to vote. But they also deserve the same guarantees on their voting process that they and the rest of us have enjoyed for a long, long time. If we can't pull them off the front lines long enough to vote...what is it, exactly, that they're fighting for?
(A) The Libertarian Party is not going to win this election, no way, no how. That's just cold truth.
(B) Our voting system is set up in such a manner as to eliminate the possibility of third parties becoming influential.
(C) People who tell you to vote third party want you to spend your vote on someone that will not win, thus weakening your political power WRT who *will* win the Presidency. They are most likely politically opposed to you.
There is a way, a legitimate way, for Libertarians and Greens and the like to get a candidate in, and that is to push through vote reform, be it preferential or some other improvement, so that third parties have a chance of becoming a player. Until vote reform happens, though, third party voters are, even in the best light, nothing more than a lobbyist group.
Each of these are an important characteristic of our voting system.
If we can't manage to pull the men and women fighting and dying for their country off the front line long enough to get a single vote in, then what the hell are we asking them to die for?
And forgetting about all that, encouraging *anyone* to take part in an insecure voting process is a really, really bad idea. If you can't pull your soldiers off of the front line long enough to pull out a voting card, then what exactly are those soldiers fighting and dying for, anyway?
It's incredibly frusterating, how I see computer security expert after security expert condemn e-voting, see Slashdot (largely a mass of IT people) come down hard on it, and then watch politicians brightly think "Now *this* must be a *good* idea because the vendor told me so!"
* Anonymity goes away with your scheme (at least without additional modification). Anonymity is an important characteristic of our voting systems. It means that votes cannot be bought, because there is no way to check to see whether someone really voted the way they said they would. It means that there can be no reprisals against people for voting one way or another.
* Voter verification goes away with your system. This is also a problem with e-voting. The machine can record anything it (or a programmer paid off at the company, or someone tampering with the machines) wants.
Believe me, if the only characteristic that needed to be done was authentication and privacy against wire snoopers, it would have been done a long time ago.
From the corporate funding of our two[sic]-party system (to the extent that the corporate lobbyists actually write some laws!), to the undemocratic way the media supports the duopoly and excludes other parties, it's a nasty, rotten system that is long overdue for major, serious reforms.
The problem is the one-shot voting, where you can't express a list of preferences in order. Whether or not you like Michael Moore, his support for preferential voting is pretty much spot-on. Of course, preferential voting hurts both Demms and Republicans, so it will never go through, but it's really the root of what's wrong with the US party system.
This is political free speech, in water-soluable chalk. You could post big "Bush is an Iraqi Killer" posters all over, but the chalk (which produces *less* of a mess) isn't okay? Come on. If somebody chalked "Bush is Defending us Against Evil, You Wimpy Hippies" on a sidewalk, I'd be fine with that (though I'd probably add a comment of my own). It's not the partisian content that matters. Its that this is a form of political expression that can reach a large number of people, is accessable to the average guy, causes no destruction of property, and so forth.
This is *not* comparable to the IBM spraypainting case, where physical damage was caused -- the paint is *permanent*. No property is being destroyed in this case. Hell, when you were a little kid, didn't you chalk up the sidewalk in front of and around your house, and in front of the neighbor's house? I know that I certainly did.
Oh, Demms screw with elections as much as possible as well. "Gerrymandering" was named for a Democrat (well, the party had a different name back then, but still).
The whole system is just *ripe* with potential for abuses.
Instead of the US trying to forcibly apply "democracy" to other countries, wouldn't it be interesting if it just tried demonstrating how well it could work, and let people institute it themselves?
Slashdot Mirror
What an absurdity. You are talking about compact simple functions. What we are talking about are fundamental changes involving perhaps 10-15 million lines of code.
/usr/src/linux-2.6.8.1/fs|grep fs$|wc results in 29 filesystems. How many filesystems does a Windows box support? FAT, FAT/w/DOS-naming, NTFS, CIFS? And you're complaining about a lack of people adding new features?
Okay, I call bullshit. At this point, you absolutely have to be either trolling or uninformed.
What on *Earth* are you talking about? What piece of software, what project, is hit by a 15 million LOC impact to add *any* feature, no matter how major? Every single project in Red Hat Linux added together has on the order of 30 million lines of code. Windows NT, the entire distribution, had about 10 million, and Windows 2k under 30 million, IIRC. The Windows kernel doesn't even begin to approach the kind of LOC count you're talking about. Let's look back at your first post:
So this is what is MS thinking: implement the things that FOSS world can't do thanks to its red-tape laden world-view. Implement a filesystem layer that provides nifty functions that while aren't new are new in this scale.
And you're talking about a lousy metadata-using filesystem taking that much? Man, a basic filesystem under Windows takes a lot more code than a basic filesystem under Linux, but Linux's ramdisk filesystem is 183 LOC. I doubt that WinFS breaks 100K LOC, much less 15 million LOC.
As for new filesystems, I suggest that you might want to reconsider Linux doing a poor job of competing with Windows. ls
I think that they might be the most *popular* vendor of a number of things, but still not the first to market
No, you are not following me. I am talking about taking things that are mature, and making them accessible to the masses. FOSS hasn't done that widely, except perhaps FireFox, and a few P2P clients. What FOSS software is in daily use by millions of desktop users?
So basically, your reason for saying that FOSS is "red tape-laden" -- I just want to get this straight -- is because there is a minimal number of FOSS projects that:
*) Run on Windows.
*) Have a large installed base.
Your arguments for existing, installed base doesn't say a thing about maturity or ease of use which you've flipped to. Take, for instance, Rosegarden. Quite usable music composition software. Not used by "millions of desktop users, however."
Because that explains a lot. I was saying that you were talking about a large installed base, and it seems that you *were*. Don't get me wrong. I think that Microsoft is *very* talented when it comes to sales, marketing, and business relationships leveraging a monopoly. That can buy them a lot of desktops. The thing that I take issue with is that you're claiming that FOSS can't get new features out to users, which is patently absurd. Yes, when Microsoft bundles a new feature into the next release of Windows or Office, it will reach a lot of users -- because a lot of people use Windows or Office!
As a Linux software developer, can you claim that?
Nope. Let me bundle my software with Windows, have it installed on a vanilla box, bootstrapping off of an existing monopoly, and we can talk again.
Except that your cross-platform ideas involve the time-consuming and error-prone problems of cross-compiling.
Time consuming? I don't know what the internal Red Hat build procedure is, but I'm sure that it's automated. Gentoo *definitely* is automated -- it's easy for someone to just say "I'm PPC, suck down the latest binary packages built by Gentoo.
As for error-prone -- the kinds of errors that turn up when you move across platforms (generally when someone's using C), like shoving pointers into ints and relying on a certain form of packing, are the kind of problems that would turn up anyway on a single
He's not astroturfing. He spent almost no time praising Apple, just bashing one competitor in a crowded field.
But he isn't releasing the source code to the *Windows* version, which *is* a requirement of the GPL, if he's going to sell that version.
I think the problem is that this guy took contributions for years to a piece of software that was GPLed, and then claimed that the people contributing didn't think that their patches were "GPL", as they didn't explicitly specify them. Instead, he is using their code unless they explicitly tell him to remove it.
I would be very, very angry if someone did this to my code. There is a very clear and well-understood principle that when you are contributing code to a single-license GPLed codebase, that you expect your patch to be GPL. You don't have to slap a license on each patch -- it would be a huge hassle otherwise.
Zed needs to go back to CVS, eliminate every line of code that he cannot personally verify that he wrote, and start from *there*. If he wanted to relicense, he needed to either (a) ask each new contributor to explicitly give him copyright and/or license their code under a non-GPL license, as the FSF does, or (b) ask *all* contributors *ahead of time* whether they would like to relicense.
Frankly, this is bullshit. It is an abuse of the work and effort that others put into that piece of software. If XChat wasn't going to be GPL, it would, quite frankly, not be the official GNOME IRC client and people would have spent time working on other clients.
Or did you think the sanctions and no-fly zones were supposed to be permanent measures?
We never set a time limit on them.
Let me ask you a question. If you had something was truly revolutionary under your hat. You thought it up, coded some proof of concepts. Bamo. Brand new. Big time stuff, what would you do with it? How long would it take to go from your idea to the average user?
[shrug] I came up with an idea for a simple and peppy substring searching algorithm that's currently used in a popular piece of P2P software. The period of time between when I came up with the idea and when it shipped in SuSE? I dunno, it was whenever the next SuSE release came out.
I have never claimed they invented anything. I am saying they brings things *to the market* way before anyone else.
I don't even think that's the case. I think that they might be the most *popular* vendor of a number of things, but still not the first to market. I'll strengthen my initial claim to cover "first to the consumer". List a couple of major things that Microsoft was the first to get to the consumer.
What percentage of applications of Open Source applications are running on virtual machine. Sun promised the world this a decade ago.
The point of running on a VM is largely that it allows cross-architecture compatibility. This was a huge deal for Sun, because SPARC has been a minority architecture for a long time, and it eliminates a major barrier to use of their platform. However, in an open source world, it doesn't provide nearly as much a benefit, since most software can just be rebuilt -- Red Hat just sets the --target option and rebuilds for IA64, PPC, i386, or whatever. The main remaining benefit is that it lets you conduct some finely-grained sandboxing, and even so a lot of that can be done under Linux through use of chroot and other sandboxing mechanisms. The problem is that a VM means a lot more for closed-source vendors than it does open-source vendors. Software targetting VMs requires more memory and runs slower than native software.
Now, there are certainly FOSS VMs with bytecode that exist: rep, emacs, bochs, plex86, python, ocaml(in bytecode mode), and kaffe, off the top of my head. Some of these have been around for an awfully long time -- emacs is probably the oldest virtual machine still in active use, and has a hell of a lot of software written for it. My mail client for a long time, the confusingly-named vm, was emacs-based.
Here comes MS delivering binary compatibility via a VM. Wow. And they are poised to do it again, and completely nail Linux in the process.
Dan, I *already* have cross-architecture compatibility with native speed and memory use. The only piece of binary software I can think of that I have is the RealPlayer library. Heck, I've co-developed software with a buddy who did his work on a PowerPC laptop. There's no need to resort to an emulation-based system.
When Longhorn and its technology hits in the next two years, developers will be drinking the cool-aid full-on. It's the ultimate in lockin: make developing apps so much more effective and efficent that you don't want to switch platforms.
Dan, in my day-to-day use, I simply write software as I work, as I use perl one-liners and zsh constantly. How can it be as easy and simple as that?
The only area that I've found MS's dev tools to be really nicer than Linux has been in RAD GUI tools for C++-targeting platforms -- and I *haven't used* the big popular Linux RAD GUI Qt Designer, just glade targetting gtk--.
Avalon/XAML
Hell, I just mentioned that I did GUI building with XML on glade on Linux, and have been for some time. It's nice that MS is modernizing their APIs, but Apple's already done so, and glib/gtk/gnome and qt/kde have been around for quite some time now. And I agree that having a modern layout engine with data-based layout descriptions is nice, but Microsoft is the last to the party on each of these.
WinFS
WinFS isn't shipping, and metadata-based storage is nothing particularly new. A num
Again, I see these as privacy issues. They should be corrected before and long term solution is approved.
I agree. My problem is that I am quite comfortable in the belief that this sort of thing *will* be okayed without the problems being fixed. I was not happy with the revelations in the Diebold fiasco, and I'm not thrilled in letting anything similar happen any time soon.
I also believe that our troops should not be denied the right to vote if they (like myself) were not really concern over who saw the ballot.
I don't understand why people keep talking about denying soldiers their vote. Cycle them through a poll booth at their base over a weeklong period. I can't believe that it's not possible to manage to get every soldier to go through a base at that rate. Set up a polling booth remotely if it's absolutely necessary if there's a large concentration of soldiers out-of-base.
I'm not selling my vote and I don't fear retibution. Soldiers who share these feels could be denied the right to vote inspite of it.
The problem I have is (a) If you're right that the alternative may be not voting, soldiers may lose their vote if they choose not to use a secure system. (b) There is obviously going to be some pressure to use such a system. People tend to underestimate risks -- for example, I doubt that someone is going to swap out my ballot, but that sort of thing has happened many times in the past to other people. (c) If a less secure but cheaper system can be made to operate for a few years, and nothing breaks, there is a tendancy to want to move to that system. It's the same thing that makes high school kids drive with a couple of beers in them. I'd *much* rather be safe than sorry.
And someone could have had a gun to my head when I was filling out my absentee ballot in '96. So based on this reasoning, we really can't do any absentee ballots. All citizens in remote locatations are automatically disenfranchized.
You're right, of course, but I also don't know of any mass groups of people that fill out absentee ballots in one place. A vote here and a vote there isn't all that useful. And a gun to someone's head is kinda hyperbole -- remember the Deep South in Jim Crow days, where voting took place on an open platform, and there were just a bunch of toughs that would stand and watch you vote.
Florida says your wrong. I'll forgo the debate about whether people do verify the hole or care enough to read the directions about how to use ballots. I can verify the card at least has the hole I intended, but that doesn't stop someone from later invalidating my vote by creating more holes. That wouldn't create a vote, it would simply takes my vote away.
You're right that physical voting isn't perfect, but I'll also say (and this is coming from someone with a significant reason for wanting to justify computer voting, as I work with computer security) that it's a lot more difficult to punch extra holes in 10K ballots without anyone noticing than it is to modify 10K ballots in the processing on a mail server somewhere.
When we can provide all the guarantees, we should provide them. If we can, unlike some, I lean towards letting them decide if they are concerned with the guarantees that cannot be provided, rather than just saying "Sorry, no vote for you. Back to the front with you."
I'd promote the alternate route -- if we have to negotiate a week-long ceasefire to do voting, I'd go for it. I'd rather just cycle soldiers through -- how likely is it, on a modern battlefield, that someone will be pinned in place for an *entire week*? Heck, if you have to, just equip a Huey or something with a voting booth and fly it around from location to location, and just arrange to pull troops out long enough to vote. Fighting is important, but no country is going to crush the United States because a platoon of soldiers was swapped out for a day to take part in voting.
I'm serious about this -- to
It doesn't eliminate anonymity other than to say "this (faxed) vote comes from a soldier, and this does not".
It could *theoretically* eliminate voter verifiability, but that would require producing modified fax machines at an image-processing level capable of recognizing a voting card, modifying the image, and transmitting it. While not impossible (and I prefer the physical cards be used), this is still difficult enough that I don't worry about people doing it. It would take much more than two lines of code inserted by a malicious programmer that would allow compromise of an email-voting or similar system.
No.
Anonymity is missing because the remote computer *must* know who you are to verify your encryption key (and to route your recipit back). Our current system is specifically designed to prevent authorities in the voting process from being able to determine who voted for who.
Voter verification is missing because the remote machine that you are talking to may tell the people taking the final tally "your vote is Republican" when you really tried to vote Democrat. There's nowhere, short of physical theft and replacement with new ballot cards, which can be reasonably well defended against, that you can pull this off with traditional ballot cards.
What I want to know is why posts that criticise commercial software are classed as Interesting or Insightful
[sarcasm]This is because most people on Slashdot hate and have avoided open source software, and having their eyes opened is enlightening.[/sarcasm]
I do wonder what's wrong with the parent though. I mean it really is a right royal pain in the ass whenever you try to connect a device to Linux machine. Will it work or won't it work? Can I get the drivers? Or has Linux improved in this regard?
The *only* device I have that isn't supported out-of-box on Fedora is my SmartHome X10 USB transciever. SmartHome doesn't give out any technical specs, and the thing had to be reverse-engineered by the author, and the driver's never been included in the mainstream kernel. Frankly, I suspect that the controller isn't supported out of box on Windows either, though I could be wrong.
I have been working on exactly this problem.
/usr/shared/gcc-support/sbin/", I just fold all these into one entry and scan the entire hierarchy below that point), you don't really have to worry about backlogging.
Let me put the basics on the table for you.
It would be a very bad idea to incorporate updatedb into the filesystem. This would make db functionality filesystem dependent, and make filesystems much more complicated. Unnecessary complexity in the filesystem is as bad as unnecessary complexity in the kernel -- you screw up, your data goes away. It also makes it harder to do things like upgrade your indexing system then.
It is pretty much unacceptable to run updatedb in sync with file changes. If you do this, it means that all disk writes take a performance hit. Linux is about fast, fast, fast serving.
The best solution, and the one that I've poked at, is the idea of running updatedb asynchronously with partial database updates triggered by change. This means that when you write to a file, it doesn't *immediately* update the database, but it schedules that file to be updated in the database. Unfortunately, Linux currently lacks important functionality to do this. Currently, you need to open and call the Linux syscall dnotify() on every directory in a filesystem to receive updates when a file changes. This uses massive amounts of file descriptors -- the dnotify() model is simply not designed for monitoring an entire filesystem. Fam and other utilities that sit on dnotify() implement recursive behavior using either polling (inefficient as well) or a massive number of monitored directories. If Linus would merge this patch (which may require additional testing and hacking, not sure), dnotify() could handle filesystem-wide recursive directory monitoring *and* inform as to which file is actually changed -- currently, this always requires polling (extremely expensive when many files are in a directory) because the monitoring application only gets a notification for the directory containing the modified file.
Then, the updatedb daemon can simply log a copy of the fact that the file is changed, and either start updating immediately (but in an asynchronous fashion) or wait until the load drops a bit. If you do things like folding (if I have ten thousand entries starting with
I am curious as to what happens when the signal queue is fully backlogged in Linux -- whether dnotify() events are dropped, or whether the file-changing application simply blocks on its operation.
The Microsoft of the ancient Solitaire implementation? Riiight.
So this is what is MS thinking: implement the things that FOSS world can't do thanks to its red-tape laden world-view.
I don't know what FOSS projects *you've* been working on, but most that I can think of move *much* more quickly than closed source projects. Linux has pretty much become the standard for advancement in the *IX world and has generally surpassed Windows from a kernel-level performance standpoint. P2P software is one of the fastest-moving areas around, and it's largely FOSS. When I want to add a feature, I do a patch and send it to a mailing list. It's pretty easy.
And you're using Microsoft as an example of technical innovation? Come on...there are closed source vendors that come up with new ideas, but I'd like to hear you name five original Microsoft *technical* (not business) ideas. Microsoft hasn't ever been a technical leader -- just a business leader.
Yes.
You're right.
If something like this is done, it should absolutely not be done at the filesystem level, but by something that hooks in directly above (if Linux ever gets the enhanced recursive dnotify() patch added to the mainstream kernel, it could have such functionality). It's ridiculous to try to tie it to a particular filesystem when there's no reason to do so.
The good thing about Linux is that when all this stupid cruft and dumb design overwhelms the filesystem, the 90% of people that promptly realize that "replace the filesystem with a database" is a bad idea can simply use another filesystem. Those on Windows may not have that luxury.
A soldier is only happy when he is complaining. It's when they stop complaining that you have to be suspicious.
I can only imagine *my* boss having that philosophy. Ugh.
The problem with email voting is not that someone might sniff and read your email on the way, or even falsify votes. Those are pretty easy to fix. The problems are those of:
* Loss of anonymity. This is an important characteristic that prevents vote-buying or reprisals against people who vote "incorrectly" (since there's no way for a political party to find out who voted which way). If you're sending via an email system, and the system is secure, it's a pretty damn good bet that you're exposing your identity (via signed, encrypted email or whatnot).
* Loss of the local privacy guarantee. Voting booths are secured. Who might be looking over your shoulder when you vote?
* Loss of the non-coercion guarantee. If I can just fire off an email, someone can have a *gun* to my head forcing me to vote a particular way.
* Loss of a controlled voting environment. How many Outlook worms does it take to convince people that email clients and desktop systems just aren't all that locked down?
* Loss of voter verifiability. With a paper ballot, I can verify that the card contains the hole that I punched in it. Short of physically substituting cards (something that's a hard to do and much easier to guard against), someone can't attack your vote data. With e-voting, there are a huge number of places to allow a different vote to be submitted than what you wanted -- in the client OS, in the client email system, in the vote-counting system, etc, etc, etc. There are a *lot* of programmers that can be bought off or act in a partisian manner -- and any one can compromise the entire system.
I do think that the men and women dying for our country should have the right to vote. But they also deserve the same guarantees on their voting process that they and the rest of us have enjoyed for a long, long time. If we can't pull them off the front lines long enough to vote...what is it, exactly, that they're fighting for?
(A) The Libertarian Party is not going to win this election, no way, no how. That's just cold truth.
(B) Our voting system is set up in such a manner as to eliminate the possibility of third parties becoming influential.
(C) People who tell you to vote third party want you to spend your vote on someone that will not win, thus weakening your political power WRT who *will* win the Presidency. They are most likely politically opposed to you.
There is a way, a legitimate way, for Libertarians and Greens and the like to get a candidate in, and that is to push through vote reform, be it preferential or some other improvement, so that third parties have a chance of becoming a player. Until vote reform happens, though, third party voters are, even in the best light, nothing more than a lobbyist group.
Voting by email:
* Eliminates anonyminity
* Eliminates voter verifiability
Each of these are an important characteristic of our voting system.
If we can't manage to pull the men and women fighting and dying for their country off the front line long enough to get a single vote in, then what the hell are we asking them to die for?
And forgetting about all that, encouraging *anyone* to take part in an insecure voting process is a really, really bad idea. If you can't pull your soldiers off of the front line long enough to pull out a voting card, then what exactly are those soldiers fighting and dying for, anyway?
It's incredibly frusterating, how I see computer security expert after security expert condemn e-voting, see Slashdot (largely a mass of IT people) come down hard on it, and then watch politicians brightly think "Now *this* must be a *good* idea because the vendor told me so!"
No anonymity.
No voter verifiability.
Two crucial linchpins of our voting system.
Problems:
* Anonymity goes away with your scheme (at least without additional modification). Anonymity is an important characteristic of our voting systems. It means that votes cannot be bought, because there is no way to check to see whether someone really voted the way they said they would. It means that there can be no reprisals against people for voting one way or another.
* Voter verification goes away with your system. This is also a problem with e-voting. The machine can record anything it (or a programmer paid off at the company, or someone tampering with the machines) wants.
Believe me, if the only characteristic that needed to be done was authentication and privacy against wire snoopers, it would have been done a long time ago.
From the corporate funding of our two[sic]-party system (to the extent that the corporate lobbyists actually write some laws!), to the undemocratic way the media supports the duopoly and excludes other parties, it's a nasty, rotten system that is long overdue for major, serious reforms.
The problem is the one-shot voting, where you can't express a list of preferences in order. Whether or not you like Michael Moore, his support for preferential voting is pretty much spot-on. Of course, preferential voting hurts both Demms and Republicans, so it will never go through, but it's really the root of what's wrong with the US party system.
Nothing wrong with a little vandalism is there?
This is political free speech, in water-soluable chalk. You could post big "Bush is an Iraqi Killer" posters all over, but the chalk (which produces *less* of a mess) isn't okay? Come on. If somebody chalked "Bush is Defending us Against Evil, You Wimpy Hippies" on a sidewalk, I'd be fine with that (though I'd probably add a comment of my own). It's not the partisian content that matters. Its that this is a form of political expression that can reach a large number of people, is accessable to the average guy, causes no destruction of property, and so forth.
This is *not* comparable to the IBM spraypainting case, where physical damage was caused -- the paint is *permanent*. No property is being destroyed in this case. Hell, when you were a little kid, didn't you chalk up the sidewalk in front of and around your house, and in front of the neighbor's house? I know that I certainly did.
Some tech heads I know even want to see voting over the internet!
This would provide significant pragmatic benefits, unlike e-voting. E-voting has no significant benefits to even out the problems with it.
Oh, Demms screw with elections as much as possible as well. "Gerrymandering" was named for a Democrat (well, the party had a different name back then, but still).
The whole system is just *ripe* with potential for abuses.
Instead of the US trying to forcibly apply "democracy" to other countries, wouldn't it be interesting if it just tried demonstrating how well it could work, and let people institute it themselves?