Although scammers are nasty creatures, shouldn't people know better than to send money to pay for something they supposedly won? This isn't a troll; I'm totally serious. Are people not taught common sense and critical thinking skills?
Well yeah, in an ideal world.
There are lots of people who are just a bit thick, but to be fair there are also a lot of people out there who are incredibly desperate, probably beyond what the majority of slashdot users could conceive of, and simply aren't quite thinking straight.
From what I understand (I'm not an expert but I've read a little), the people who these scammers appeal to often aren't the people who are simply greedy. They're the people who've been told that they need a $100,000 payment on their home within a month or they and their kids will be kicked out of the home that's been in their family for generations.
Maybe they've been trying to save money and they're malnourished, or perhaps they're getting over an illness that cost a lot of money to treat. (Perhaps they desperately need money to treat it.) It's the same sort of thing as the loner or widower who's sitting at home feeling lonely, and after three months of happiness through online chit-chat, decides to send thousands of dollars to an internet "girlfriend" in another country so she can fly there to say hello, only to have "her" never contact him again.
It's easy to turn around and say that people were stupid to not be careful and give away their life savings to a stranger. But at the end of the day there are still victims and the scammar's still a con artist who defrauded people and often wrecked their lives many times more than they might've been already. If you really feel as if you have have nowhere else to go and the world seems to be falling down around you, it can sometimes illogically seem reasonable to take up an offer like this against any real common sense.
I'm not trying to suggest that everyone who responds to these things is in the same position. Some, perhaps many, probably are just greedy and/or silly, although without meeting them I wouldn't want to pinpoint who. I do think it's short-sighted to simply say that all of these people are obviously stupid, without actually looking at the situation. This is nothing against you personally, but that tends to be the general tone on slashdot and I don't think it's very fair.
Ever since I started buying music on iTunes, I have yet to buy an entire album. What does that suggest? There are too many junky tracks on every CD.
I don't know what sort of music you listen to, but I like a lot of albums as a whole, as they've been produced by the artists and the producers. The promoted singles sometimes get my attention, but I usually prefer to play the album completely.
After all, would you be satisfied watching a 10 minute slot out of a movie or half an act in a play? Those scenes aren't pointless or worthless just because they're not complete. More often than not, if it's well directed, they're developing context for the surrounding material that makes the whole even better.
I'm sure there are exceptions. I don't imagine that most teeny-bop music is much more sophisticated than throwing a collection of songs onto a CD when it comes to album arrangement. (I don't listen to it, so I couldn't say for sure.)
MSIE and Firefox are both written in C/C++, therefore:
MSIE and Firefox both have lots of buffer overflow related bugs.
MSIE suffers more because it's more popular and more homogeneous, allowing worms to spread more easily.
People can flock to Firefox, but if this happens then Firefox will become more popular and more homogeneous. Consequently,
There's no point flocking to Firefox. Give in to software monoculture, and wait for an answer that he already admits probably hasn't been invented yet.
Personally I find this argument to be quite baseless, and I'll believe it when I see it. Even if he is correct and Firefox might have as many bugs (because hey, it's written in C/C++), he doesn't seem to've provided any logical reasoning for people who are about to move to change their mind.
Even Jeff Duntemann admits that MSIE supposedly has at least as many bugs are Firefox. Given this reasoning, there's the choice between deploying MSIE (which is proven over and over again to be unsafe and full of security holes), and Firefox (for which nothing is proven).
It seems very shallow --- he's pitting something proven versus something unproven, and essentially claiming that we should assume they're both identically bad. I'll take my chances with Firefox, thank you very much. If everyone flocks to Firefox and it suddenly becomes a big security risk, I'll deal with it at the time.
A better option is to give everyone lots of GUID's. This way, you know your real one, but when someone's looking over your shoulder, you can use an alternate one that shows what your boss wants, but not what you did.
Doesn't that defeat the purpose of having such a receipt in the first place? If there's no visible evidence as to which of your GUID's is the active one, how can you be certain that your intended vote is the one that's been counted?
Perhaps there's a way, but I can't see what it is....better to avoid a receipt that can be matched to the voter after the election at all, I think.
The problem with not having an anonymous election is that there's always the possibility of coercion. eg.
"If you don't give me your GUID after the election and prove to me that you voted for candidate X, I'll make sure that you'll regret it."
Is there any way you can ensure there's no coercion? I'm not convinced. Furthermore, if you mail a unique ID to people (as you've suggested), you have no guarantee that someone's not going to run around mail boxes collecting them, or that everyone who's had their ID stolen will care enough to report that it wasn't received.
Personally I think the only safe way to allow voter confirmation is for voting machines to print a paper receipt without any voter ID, and that the voter is not allowed to take away with them. Have the voter confirm that it matches their vote, and then the machine drops it in a box which should be accepted as more authoritative than the machine's electronic count. This way the backup system for the electronic count becomes a regular paper ballot, and we have centuries of experience dealing fairly with those.
That's a fair enough point. I guess the main advantage with using a database would be the ability to query your email a little more flexibly than what might be available in a mail client.
Storing email in a database would be an interesting way to do things, but it sounds a bit overly complex for most mail readers out there... most of which (rightly, I think) spend the bulk of their effort focusing on the front end and actually reading the mail. Also, the word "export" seems to imply that you don't want to keep the database up-to-date with your email in real time.
I think it'd be very interesting to see an IMAP server that would manage mail folders in a database, though. That'd take a lot of stress off the folder managing complexity away from the mail reading client.
Someone else who replied mentioned that databases suck for handling free text. In my experience, they're at least as good as any other format, and they tend to have a much more established way of organising text indexes for any searching that's needed. The headers on emails can easily be separated for separate indexing and searching away from the body text, and even the body text can be indexed with real full-text indexes. (I'm not sure how well MySql supports that, but there's at least one contributed extension to PostgreSQL (tsearch2) that does full text indexing nicely.
Just because it's older doesn't mean it's more natural. Personally, I much prefer mice and keyboards to pens for almost everything I do on the computer... and most of it is graphics related.
Well yeah, but it's still thinking of a computer as a box that has to be specifically interacted with... with information that has to be input and other information that has to be extracted from it somehow. That's what lots of HCI tends to concentrate on at the moment: How to tell a machine what you want, and how to get what you want back from it.
Much of HCI focuses on the optimal way of using a small rectangular window, a modified typewriter, a small box that turns a complex and capable hand into a one-thumbed pushing and dragging machine, and possibly some sound, as the primary methods of interaction for a generic machine that does about a million things.
It's fine as long as there are technological restrictions, because there's not much choice. But I think that the sooner we can get rid of the technological stereotype of computers being machines that sit in a box, and just build exactly what we want for each task, the better.
It doesn't have to be a pen instead of a mouse, or vice versa. I'd rather not even have to think about what I have to use to select or push something around on a desktop. I guess my point about the pen was that it's a more direct and slightly more intuitive way to directly manipulate something. (There's a layer of abstraction with a mouse that has to be learned.) But then, I'd also like to be able to pick up some of the things I'm doing (applications at the moment) and stash them in a pile somewhere. This can't be done at the moment, because they're all stored on the virtual desktop displayed on the screen in front of me, and I'm not allowed to reach in and lift them out.
...you fanboy KDE, so I was having a hard time swallowing that post anyway.:)
Yeah.:) I've just switched to it from WindowMaker for the first time in a couple of years, and I'm noticing a lot of the neat things it has that WindowMaker too minimalist for. There are a few things I find annoying, though, and it takes ages to start up. With respect to what I've just said though, a window manager still can't fix all of the inherent problems that computers still have because of what they are. Oh well.:)
To be honest, I really don't know what an ideal interface would be from this perspective. I'm trying to think less about the actual technology involved and more about what I'd want. I'd like to be surrounded by intelligent objects that integrate and communicate nicely with each other, yet not have to care about how they're integrating.
My point about pens, more than anything, is that using them to manipulate things is slightly more natural and direct than manupulating a mouse (or a keyboard) that adjusts what's displaying on a screen that represents something somewhere else. That said, there are lots of reasons why pens suck. I wouldn't want to have to write hundreds of pages of text with a pen, but there are better tools for that.
Really though, I'd like to be able to move things around with my finger, or lift them up and push them around with a pen or some other device, just like real life and not involving a fake digital world encapsulated behind a screen. (Why stop at metaphor unless there's a technological reason to do so?)
I guess the point about paper is more to do with it being part of a much more integrated system where computers are effectively part of everything. Just because paper happened to have digital elements wouldn't necessarily mean it should be thought of or used as a computer or something that was different from regular paper. What would be cool though, is if the paper was sensitive to what you used it for, and could (seamlessly) communicate that use to surrounding objects in some way at times when it was actually needed. And why stop at paper when there are all sorts of things that could be just as sensitive?
I want the actual surface of my desk to be the desktop, one very lage touch sensitive screen.
I've been thinking about this for a couple of years now. (I'm in an HCI-related research group, although not one that really focuses on this particular problem.) To me it seems that there's something fundamentally unsuitable about taking a desktop metaphor and trying to crunch it into a tiny screen that really looks and acts very unlike a desktop.
IMHO it's not really enough to just put the existing screen on the desk, though. Ideally, in my world, computers would be mostly invisible except for when it was convenient to have them around. Things like "clicking" are remnants of using a mouse to indicate things, but it's not absolutely necessary. A more natural way to deal with a display on a desk would use something like a pen.
But why stop there when you could integrate the computer into the paper or writing materials? You can pile it up, throw it where you want, keep it organised or disorganised. Everyone used to use paper, after all, but now it might be a pen and paper that helps you to write more efficiently if and when you want that help. Perhaps the paper works as an interface to some data storage somewhere. These are just ideas, of course.
Obviously it's necessary to try and get the best out of what's available and I like the progress that environments like KDE are making, but I think a lot of people tend to assume that tommorrow's technology has to be just like today's but with minor tweaks to make it different. It's not necessarily true. Oh well.
Did you consider installing your critical packages from unstable?
I run testing on my home PC and it's perfectly okay for me. There are several packages (mostly front applications that I use a lot such as firefox, emacs, and others) that I run from unstable. The occasional library that these apps have needed out of unstable is also on my system, but they're mostly happy with the library versions in testing. Really it's not much of an issue if they break on occasion, because I use them enough that I can spend a few minutes fixing them when it happens anyway.
Remote administration, perhaps? Although I administer my own system reasonably confidently, the best systems I've used are ones that are locked down and administered by people who know exactly what they're doing.
Maybe not tommorrow, but I wouldn't be too surprised if that's the way things eventually go. Fast connections are becoming more common in many places these days. The main problem would be figuring out a protocol and a secure and standard-enough system so that administration companies can administer large numbers of workstations remotely. If that's figured out reliably enough, I don't think it'd take long for a lot of people I know to be quite happy to pay a trusted other person a subscription charge to remotely keep their system stable, and provide whatever services and applications they want without the risk of it spluttering and breaking.
Most geeks probably wouldn't go for this --- at least not in today's world --- but a lot of people would. This is just one possibility, of course.
I have always been extremely happy with Nvidia and at this point I see no reason to buy any other make of card.
The main thing that really annoys me though, is that in an otherwised fast and streamlined boot process, Nvidia forces me stare at a massive NVIDIA!!!!!! spash screen for about five seconds every time I run X on my laptop.
I really don't understand why this is necessary. It's not as if the Windows drivers that Nvidia provides force the same irritation on Windows users.
On the assumption that they'll make an effort to keep their closed source linux drivers up to date and efficient, I'd probably be willing to tolerate their policy considering everything that you've just stated. (In principle I still dislike that I can only use a very limited set of operating systems that they choose to support themselves.) I just can't understand the need for nVidia to incorporate that splash screen.
Back in the late 80's and early 90's, I remember that Pascal was a very popular language for certain DOS applications... in particular there were several popular BBS door game toolkits available for Pascal that dealt with a lot of the more complicated communications routines for talking to the fossil driver and what-not.
Door games spend a lot of time reading and writing input and output from and to users without needing to do much low level stuff. These days you'd probably use a scripting language as most CGI applications do these days, even though it'd be likely to run much more slowly. Pascal's good at that sort of stuff, though, and although it's not as flexible as a typical scripting language it can cope with some of the same tasks (and is native code). Consequently there were a lot of BBS door games written in Pascal using these toolkits. One of the first programs that I wrote and actually released as a teenager was a simple trivia door game that was built on one of these toolkits. It sucked and almost nobody played it, but it worked.
Yes, you have to init the strings explicitly as mystr, but so what
This is what I do at the moment for my compromise in Python, but it's really not good enough.
I don't want to have to dramatically change it. I want to add a method and add a property to the string meta-class so that I can treat every string the same way, and probably augment some of the operators to deal with my adjusted string more appropriately. I'm fully aware that fundamentally changing how it acts could potentially break other modules -- that's what you get when you meddle with nearly any meta class. But I'm satisfied that the particular change I want to make isn't going to create serious problems for existing code.
It's for some string-safety research that I'm doing. Having to explicitly declare any given string to be a safe string simply isn't good enough, because it defeats the purpose of a string being "safe" if the programmer has to remember every time a string is used. I want every string that the program generates from anywhere to act my way --- not just the strings I remember to update.
I can do it in Ruby.
Anyway, my point was that Python tends to have these inconsistencies and they pop up and make themselves apparent at what usually seem to be the most annoying times... which isn't really unusual considering they're inconsistencies. It's not a bad language, but there are clearly aspects of Ruby that beat it as far as consistency is concerned.
Is Ruby really "more powerful than Perl and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?
I've never bothered to learn Perl, although from what I understand you're likely to miss being able to do some things in one line that might take a few extra lines in either Python or Ruby.
Python has been by far my favourite scripting language for several years now. It's structured, it forces relatively consistent syntax, and it has a huge amount of support. The (online) documentation has room for improvement, although I might have been spoiled somewhat by the online Java documentation. (That said, I've hardly used Java at all for three or four years.)
About a year ago I took my first proper look at Ruby. Ruby is a nicer language. It's more consistent and feels a bit more natural once you get to more in-depth language-related things.
For instance, one thing I'd really like to do in Python is to modify a few things about the built-in string class. I'd like to just be able to import a module into my program, and have the string class work differently from then on.
Python simply doesn't let you do this, short of something drastic like hacking the interpreter. Although a large part of the standard libraries are very flexible, the string class is something that's just built in. It can't be touched, because the string implementation is built into the interpreter. I spent a month trying to get my idea to work before I was able to find out that the string class is inconsistent with other classes, and what I wanted really wasn't possible.
Python's a great language and it's wonderful for prototyping and scripting, but it's this type of thing, where the occasional part of the language is still inconsistent that still lets it down on occasion. For me, at least. My experience with Ruby so far has been that everything just acts the way that you'd expect it to act based on how everything else acts. I'm still not an expert Ruby programmer and there are parts of the language that I'm still working to get my head around, but I haven't yet encountered anything that seems painfully inconsistent.
Putting all of that aside, I'd recommend definitely learning Python if you want to be productive, and learning Ruby as a side project for the future. The reason I say this is that Python just has so much more support and more depth. eg. Ruby doesn't yet have great support for a lot of often-needed things like Unicode, and you're likely to find a lot more Python support for parsing routines, too.
Ruby is certainly likely to be useful in a production environment and on a later day may be superior to many other scripting languages. It's worth becoming familiar with it just for that, but I wouldn't want to base everything on Ruby (yet) without backup plans.
The company that I used to work at fell into this trap completely, specifically because nearly all of the MSDN example code at the time was written using the MSIE-specific "()". MSDN is both a great resource that's more convenient than much of what's out there, and a horrible cesspool of mis-information, depending on the setting.
Eventually, during a week when there was less work for me to do, I managed to convince my co-workers to let me go through and standardise it properly. Until then, even the possibility of supporting another browser had been unimaginable because there were silly problems like round brackets throughout the code that made an overhaul seem tremendous. And as time went on it became even worse.
There was really no advantage to anyone but Microsoft for the MSDN example code to use this syntax. It didn't gain anything or add anything to the code quality or usefulness. All it did was to lock companies in to supporting nothing but MSIE.
Well I wasn't necessarily referring to this particular language -- I've only glanced over the paper myself. Besides, just because another language is supported probably wouldn't mean you'd have to give up SQL. It'd increase your options, though.
In general, I think it's great that researchers are constantly looking for new and better ways to do things in database languages rather than just listening to those who say SQL is the only language that's useful and needed for databases... and that is an opinion that seems to do the rounds quite a lot, although I don't think it's very justified.
If a few alternatives could be implemented in the major databases some time just to increase the choices available for developers who use databases, I think it'd work out better overall.
For those interested, the paper describing this language (linked to from the article) is available here. There's a link to the grammar of the language at the end of that paper.
I use SQL quite a lot. It's certainly great for a lot of things, but it does have some limitations here and there. For instance, trying to deal with things like hierarchical structures, or joining on having identical/similar children, is a nightmare in SQL. Even if the query doesn't need to be efficient to run, it can still be extremely complicated to write and test. SQL simply wasn't designed or intended to deal with those sorts of structures.
Unfortunately, short of using external code outside the database, it's so often a choice between using SQL or nothing else for writing a query in a particular database rather than an option between SQL and another language. In some ways it's like being forced to write every program in C or every program in Java or every program in Lisp, where realistically one or another might be better suited to a particular task.
I suppose one of the reasons for only supporting SQL is that a predictible query language makes it easier to arrange data structures so they can be queried most efficiently. Still, it'd be nice to see an alternative front-end language or two supported in one or more of the major databases. Not every query needs to be ultra-efficient, and there have been many times where I would've liked to trade an efficient query execution for a language where what I wanted was more writeable.
Which is why if you don't want your content being taken down, you shouldn't use a free hosting provider.
I don't think that being free really has much to do with it, although there could perhaps be a correlation. Probably what matters is the terms of service that you agree to. Even if you pay for the service, virtually all terms of service will contain a clause that states the provider can yank your access or hosting or whatever they provide on a whim at their own discretion.
Clearly it might not hold up in court, and it's perhaps even less likely to hold up if you're paying for a service and they don't have reasonable grounds for not providing it... regardless of what's in the terms of service. But they could still potentially get away with claiming that they don't have time or resources to follow up complaints and have to protect their liability, and it still means going through the court system. The latter is a huge disincentive when it's normally much easier to just find a different provider.
If you watched Al Jazeera, you'd see the numerous Iraq reporters showing the Kurdish civilians being led into the square _with_ coalition troops and tanks, as the US soliders assisted in draping the Stars and Stripes flag over Saddams head.
If Al Jazeera's not directly available, there's a great documentary film called Control Room that follows around the Al Jazeera journalists during the US invasion. It has a great summary of their complaints about how the people tearing down the statue were practically US puppets.
Assuming he is telling the truth, I think it's more likely that some kind of scanning software is involved. It'd seem very difficult to either develop sufficiently intelligent software, or to hire people to simply search manually. Even in the latter case, it's unlikely that someone might "accidentally" wander into an open source repository and accidentally assume that a file in the middle of all those other legitimate files happens to be a ripped off movie.
But the intermediate possibility seems much more realistic. My guess is that they have software to do the bulk of the searching and spidering. It probably presents a big list of filenames and perhaps contextual information to a few humans. These people most likely scan down a list checking boxes or clicking buttons on any entry that appears at a glance to be a movie copyright violation, and the pattern-matching system, having received confirmation of the infringement, generates a notice and does the rest.
The human error to which he refers to could quite conceivably be someone simply clicking an incorrect item, or some-such mistake. Just because humans don't run the entire process doesn't mean they can't play a part in it.
I'm not trying to suggest that it should be excused. Chances are that there were a lot more mis-sent notices before this one went wrong. But on objective grounds, it seems premature to write it off on the by claiming that it's impossible for a human error to be involved just because of the sheer volume of infringement notices.
Sure they do. The subject's been studied for decades; there's been loads of work (some of it quite good) done on it. The problem is the commercial software producers never pay any attention to any of it. "There's never time to do it right, but there's always time to do it over."
No they don't. It's been studied for decades, but in all that time we've still not settled on anything that's actually demonstrated over long periods of time to be good. Hardware, materials and other available resources are continuously evolving and changing, meaning that software design research has nothing to reliably settle on before things change again.
We don't even have consistent and proven programming languages. Today it's Java, C#, VB and a variety of imperative scripting languages. Yesterday it was C and C++, before that it was Fortran, and before that there have been variants of assembler. And as we use these languages, we're constantly discovering more and more about language design and developing new languages.
HCI is still in very early stages of development, and that's a major part of software engineering. (If people can't use software then what's the point?) The vast majority of software development shops -- particularly smaller ones -- don't even employ HCI experts, and substantial proportions of developers still don't respect them or understand what the point is.
Something like bridge building, for instance, has been studied for centuries (if not millenia). It relies on consistent physics, consistent tools and well understood environments. Organisations that build bridges have well established experience, procedures and regulations that are put in place throughout their organisation. Software development's been studied for a few decades with the existing materials, resources and expectations constantly changed from underneath it.
Organisations that build software still don't have any reasonable idea of how to arrange themselves, or what procedures they should be using. There have certainly been some pretty good ideas from relatively recent ongoing studies, but the fact that managers and developers and marketers and whoever else frequently don't gel together very well with usually bad results is just an ongoing consequence of the fact that it's a very new field.
Just because software engineering has been studied for a few decades doesn't mean we know what we're talking about, or even that we know what we're studying.
Slashdot Mirror
Hmmm.. sorry about that -- it wasn't intentional.
Well yeah, in an ideal world.
There are lots of people who are just a bit thick, but to be fair there are also a lot of people out there who are incredibly desperate, probably beyond what the majority of slashdot users could conceive of, and simply aren't quite thinking straight.
From what I understand (I'm not an expert but I've read a little), the people who these scammers appeal to often aren't the people who are simply greedy. They're the people who've been told that they need a $100,000 payment on their home within a month or they and their kids will be kicked out of the home that's been in their family for generations.
Maybe they've been trying to save money and they're malnourished, or perhaps they're getting over an illness that cost a lot of money to treat. (Perhaps they desperately need money to treat it.) It's the same sort of thing as the loner or widower who's sitting at home feeling lonely, and after three months of happiness through online chit-chat, decides to send thousands of dollars to an internet "girlfriend" in another country so she can fly there to say hello, only to have "her" never contact him again.
It's easy to turn around and say that people were stupid to not be careful and give away their life savings to a stranger. But at the end of the day there are still victims and the scammar's still a con artist who defrauded people and often wrecked their lives many times more than they might've been already. If you really feel as if you have have nowhere else to go and the world seems to be falling down around you, it can sometimes illogically seem reasonable to take up an offer like this against any real common sense.
I'm not trying to suggest that everyone who responds to these things is in the same position. Some, perhaps many, probably are just greedy and/or silly, although without meeting them I wouldn't want to pinpoint who. I do think it's short-sighted to simply say that all of these people are obviously stupid, without actually looking at the situation. This is nothing against you personally, but that tends to be the general tone on slashdot and I don't think it's very fair.
I don't know what sort of music you listen to, but I like a lot of albums as a whole, as they've been produced by the artists and the producers. The promoted singles sometimes get my attention, but I usually prefer to play the album completely.
After all, would you be satisfied watching a 10 minute slot out of a movie or half an act in a play? Those scenes aren't pointless or worthless just because they're not complete. More often than not, if it's well directed, they're developing context for the surrounding material that makes the whole even better.
I'm sure there are exceptions. I don't imagine that most teeny-bop music is much more sophisticated than throwing a collection of songs onto a CD when it comes to album arrangement. (I don't listen to it, so I couldn't say for sure.)
His argument, spelled out, seems to be:
Personally I find this argument to be quite baseless, and I'll believe it when I see it. Even if he is correct and Firefox might have as many bugs (because hey, it's written in C/C++), he doesn't seem to've provided any logical reasoning for people who are about to move to change their mind.
Even Jeff Duntemann admits that MSIE supposedly has at least as many bugs are Firefox. Given this reasoning, there's the choice between deploying MSIE (which is proven over and over again to be unsafe and full of security holes), and Firefox (for which nothing is proven).
It seems very shallow --- he's pitting something proven versus something unproven, and essentially claiming that we should assume they're both identically bad. I'll take my chances with Firefox, thank you very much. If everyone flocks to Firefox and it suddenly becomes a big security risk, I'll deal with it at the time.
Doesn't that defeat the purpose of having such a receipt in the first place? If there's no visible evidence as to which of your GUID's is the active one, how can you be certain that your intended vote is the one that's been counted?
Perhaps there's a way, but I can't see what it is. ...better to avoid a receipt that can be matched to the voter after the election at all, I think.
The problem with not having an anonymous election is that there's always the possibility of coercion. eg.
Is there any way you can ensure there's no coercion? I'm not convinced. Furthermore, if you mail a unique ID to people (as you've suggested), you have no guarantee that someone's not going to run around mail boxes collecting them, or that everyone who's had their ID stolen will care enough to report that it wasn't received.
Personally I think the only safe way to allow voter confirmation is for voting machines to print a paper receipt without any voter ID, and that the voter is not allowed to take away with them. Have the voter confirm that it matches their vote, and then the machine drops it in a box which should be accepted as more authoritative than the machine's electronic count. This way the backup system for the electronic count becomes a regular paper ballot, and we have centuries of experience dealing fairly with those.
That's a fair enough point. I guess the main advantage with using a database would be the ability to query your email a little more flexibly than what might be available in a mail client.
Storing email in a database would be an interesting way to do things, but it sounds a bit overly complex for most mail readers out there... most of which (rightly, I think) spend the bulk of their effort focusing on the front end and actually reading the mail. Also, the word "export" seems to imply that you don't want to keep the database up-to-date with your email in real time.
I think it'd be very interesting to see an IMAP server that would manage mail folders in a database, though. That'd take a lot of stress off the folder managing complexity away from the mail reading client.
Someone else who replied mentioned that databases suck for handling free text. In my experience, they're at least as good as any other format, and they tend to have a much more established way of organising text indexes for any searching that's needed. The headers on emails can easily be separated for separate indexing and searching away from the body text, and even the body text can be indexed with real full-text indexes. (I'm not sure how well MySql supports that, but there's at least one contributed extension to PostgreSQL (tsearch2) that does full text indexing nicely.
Well yeah, but it's still thinking of a computer as a box that has to be specifically interacted with... with information that has to be input and other information that has to be extracted from it somehow. That's what lots of HCI tends to concentrate on at the moment: How to tell a machine what you want, and how to get what you want back from it.
Much of HCI focuses on the optimal way of using a small rectangular window, a modified typewriter, a small box that turns a complex and capable hand into a one-thumbed pushing and dragging machine, and possibly some sound, as the primary methods of interaction for a generic machine that does about a million things.
It's fine as long as there are technological restrictions, because there's not much choice. But I think that the sooner we can get rid of the technological stereotype of computers being machines that sit in a box, and just build exactly what we want for each task, the better.
It doesn't have to be a pen instead of a mouse, or vice versa. I'd rather not even have to think about what I have to use to select or push something around on a desktop. I guess my point about the pen was that it's a more direct and slightly more intuitive way to directly manipulate something. (There's a layer of abstraction with a mouse that has to be learned.) But then, I'd also like to be able to pick up some of the things I'm doing (applications at the moment) and stash them in a pile somewhere. This can't be done at the moment, because they're all stored on the virtual desktop displayed on the screen in front of me, and I'm not allowed to reach in and lift them out.
Yeah. :) I've just switched to it from WindowMaker for the first time in a couple of years, and I'm noticing a lot of the neat things it has that WindowMaker too minimalist for. There are a few things I find annoying, though, and it takes ages to start up. With respect to what I've just said though, a window manager still can't fix all of the inherent problems that computers still have because of what they are. Oh well. :)
To be honest, I really don't know what an ideal interface would be from this perspective. I'm trying to think less about the actual technology involved and more about what I'd want. I'd like to be surrounded by intelligent objects that integrate and communicate nicely with each other, yet not have to care about how they're integrating.
My point about pens, more than anything, is that using them to manipulate things is slightly more natural and direct than manupulating a mouse (or a keyboard) that adjusts what's displaying on a screen that represents something somewhere else. That said, there are lots of reasons why pens suck. I wouldn't want to have to write hundreds of pages of text with a pen, but there are better tools for that.
Really though, I'd like to be able to move things around with my finger, or lift them up and push them around with a pen or some other device, just like real life and not involving a fake digital world encapsulated behind a screen. (Why stop at metaphor unless there's a technological reason to do so?)
I guess the point about paper is more to do with it being part of a much more integrated system where computers are effectively part of everything. Just because paper happened to have digital elements wouldn't necessarily mean it should be thought of or used as a computer or something that was different from regular paper. What would be cool though, is if the paper was sensitive to what you used it for, and could (seamlessly) communicate that use to surrounding objects in some way at times when it was actually needed. And why stop at paper when there are all sorts of things that could be just as sensitive?
I've been thinking about this for a couple of years now. (I'm in an HCI-related research group, although not one that really focuses on this particular problem.) To me it seems that there's something fundamentally unsuitable about taking a desktop metaphor and trying to crunch it into a tiny screen that really looks and acts very unlike a desktop.
IMHO it's not really enough to just put the existing screen on the desk, though. Ideally, in my world, computers would be mostly invisible except for when it was convenient to have them around. Things like "clicking" are remnants of using a mouse to indicate things, but it's not absolutely necessary. A more natural way to deal with a display on a desk would use something like a pen.
But why stop there when you could integrate the computer into the paper or writing materials? You can pile it up, throw it where you want, keep it organised or disorganised. Everyone used to use paper, after all, but now it might be a pen and paper that helps you to write more efficiently if and when you want that help. Perhaps the paper works as an interface to some data storage somewhere. These are just ideas, of course.
Obviously it's necessary to try and get the best out of what's available and I like the progress that environments like KDE are making, but I think a lot of people tend to assume that tommorrow's technology has to be just like today's but with minor tweaks to make it different. It's not necessarily true. Oh well.
Out of interest, how did you respond?
Did you consider installing your critical packages from unstable?
I run testing on my home PC and it's perfectly okay for me. There are several packages (mostly front applications that I use a lot such as firefox, emacs, and others) that I run from unstable. The occasional library that these apps have needed out of unstable is also on my system, but they're mostly happy with the library versions in testing. Really it's not much of an issue if they break on occasion, because I use them enough that I can spend a few minutes fixing them when it happens anyway.
Remote administration, perhaps? Although I administer my own system reasonably confidently, the best systems I've used are ones that are locked down and administered by people who know exactly what they're doing.
Maybe not tommorrow, but I wouldn't be too surprised if that's the way things eventually go. Fast connections are becoming more common in many places these days. The main problem would be figuring out a protocol and a secure and standard-enough system so that administration companies can administer large numbers of workstations remotely. If that's figured out reliably enough, I don't think it'd take long for a lot of people I know to be quite happy to pay a trusted other person a subscription charge to remotely keep their system stable, and provide whatever services and applications they want without the risk of it spluttering and breaking.
Most geeks probably wouldn't go for this --- at least not in today's world --- but a lot of people would. This is just one possibility, of course.
The main thing that really annoys me though, is that in an otherwised fast and streamlined boot process, Nvidia forces me stare at a massive NVIDIA!!!!!! spash screen for about five seconds every time I run X on my laptop.
I really don't understand why this is necessary. It's not as if the Windows drivers that Nvidia provides force the same irritation on Windows users.
On the assumption that they'll make an effort to keep their closed source linux drivers up to date and efficient, I'd probably be willing to tolerate their policy considering everything that you've just stated. (In principle I still dislike that I can only use a very limited set of operating systems that they choose to support themselves.) I just can't understand the need for nVidia to incorporate that splash screen.
Back in the late 80's and early 90's, I remember that Pascal was a very popular language for certain DOS applications... in particular there were several popular BBS door game toolkits available for Pascal that dealt with a lot of the more complicated communications routines for talking to the fossil driver and what-not.
Door games spend a lot of time reading and writing input and output from and to users without needing to do much low level stuff. These days you'd probably use a scripting language as most CGI applications do these days, even though it'd be likely to run much more slowly. Pascal's good at that sort of stuff, though, and although it's not as flexible as a typical scripting language it can cope with some of the same tasks (and is native code). Consequently there were a lot of BBS door games written in Pascal using these toolkits. One of the first programs that I wrote and actually released as a teenager was a simple trivia door game that was built on one of these toolkits. It sucked and almost nobody played it, but it worked.
This is what I do at the moment for my compromise in Python, but it's really not good enough.
I don't want to have to dramatically change it. I want to add a method and add a property to the string meta-class so that I can treat every string the same way, and probably augment some of the operators to deal with my adjusted string more appropriately. I'm fully aware that fundamentally changing how it acts could potentially break other modules -- that's what you get when you meddle with nearly any meta class. But I'm satisfied that the particular change I want to make isn't going to create serious problems for existing code.
It's for some string-safety research that I'm doing. Having to explicitly declare any given string to be a safe string simply isn't good enough, because it defeats the purpose of a string being "safe" if the programmer has to remember every time a string is used. I want every string that the program generates from anywhere to act my way --- not just the strings I remember to update.
I can do it in Ruby.
Anyway, my point was that Python tends to have these inconsistencies and they pop up and make themselves apparent at what usually seem to be the most annoying times... which isn't really unusual considering they're inconsistencies. It's not a bad language, but there are clearly aspects of Ruby that beat it as far as consistency is concerned.
I've never bothered to learn Perl, although from what I understand you're likely to miss being able to do some things in one line that might take a few extra lines in either Python or Ruby.
Python has been by far my favourite scripting language for several years now. It's structured, it forces relatively consistent syntax, and it has a huge amount of support. The (online) documentation has room for improvement, although I might have been spoiled somewhat by the online Java documentation. (That said, I've hardly used Java at all for three or four years.)
About a year ago I took my first proper look at Ruby. Ruby is a nicer language. It's more consistent and feels a bit more natural once you get to more in-depth language-related things.
For instance, one thing I'd really like to do in Python is to modify a few things about the built-in string class. I'd like to just be able to import a module into my program, and have the string class work differently from then on.
Python simply doesn't let you do this, short of something drastic like hacking the interpreter. Although a large part of the standard libraries are very flexible, the string class is something that's just built in. It can't be touched, because the string implementation is built into the interpreter. I spent a month trying to get my idea to work before I was able to find out that the string class is inconsistent with other classes, and what I wanted really wasn't possible.
Python's a great language and it's wonderful for prototyping and scripting, but it's this type of thing, where the occasional part of the language is still inconsistent that still lets it down on occasion. For me, at least. My experience with Ruby so far has been that everything just acts the way that you'd expect it to act based on how everything else acts. I'm still not an expert Ruby programmer and there are parts of the language that I'm still working to get my head around, but I haven't yet encountered anything that seems painfully inconsistent.
Putting all of that aside, I'd recommend definitely learning Python if you want to be productive, and learning Ruby as a side project for the future. The reason I say this is that Python just has so much more support and more depth. eg. Ruby doesn't yet have great support for a lot of often-needed things like Unicode, and you're likely to find a lot more Python support for parsing routines, too.
Ruby is certainly likely to be useful in a production environment and on a later day may be superior to many other scripting languages. It's worth becoming familiar with it just for that, but I wouldn't want to base everything on Ruby (yet) without backup plans.
The company that I used to work at fell into this trap completely, specifically because nearly all of the MSDN example code at the time was written using the MSIE-specific "()". MSDN is both a great resource that's more convenient than much of what's out there, and a horrible cesspool of mis-information, depending on the setting.
Eventually, during a week when there was less work for me to do, I managed to convince my co-workers to let me go through and standardise it properly. Until then, even the possibility of supporting another browser had been unimaginable because there were silly problems like round brackets throughout the code that made an overhaul seem tremendous. And as time went on it became even worse.
There was really no advantage to anyone but Microsoft for the MSDN example code to use this syntax. It didn't gain anything or add anything to the code quality or usefulness. All it did was to lock companies in to supporting nothing but MSIE.
Well I wasn't necessarily referring to this particular language -- I've only glanced over the paper myself. Besides, just because another language is supported probably wouldn't mean you'd have to give up SQL. It'd increase your options, though.
In general, I think it's great that researchers are constantly looking for new and better ways to do things in database languages rather than just listening to those who say SQL is the only language that's useful and needed for databases... and that is an opinion that seems to do the rounds quite a lot, although I don't think it's very justified.
If a few alternatives could be implemented in the major databases some time just to increase the choices available for developers who use databases, I think it'd work out better overall.
For those interested, the paper describing this language (linked to from the article) is available here. There's a link to the grammar of the language at the end of that paper.
I use SQL quite a lot. It's certainly great for a lot of things, but it does have some limitations here and there. For instance, trying to deal with things like hierarchical structures, or joining on having identical/similar children, is a nightmare in SQL. Even if the query doesn't need to be efficient to run, it can still be extremely complicated to write and test. SQL simply wasn't designed or intended to deal with those sorts of structures.
Unfortunately, short of using external code outside the database, it's so often a choice between using SQL or nothing else for writing a query in a particular database rather than an option between SQL and another language. In some ways it's like being forced to write every program in C or every program in Java or every program in Lisp, where realistically one or another might be better suited to a particular task.
I suppose one of the reasons for only supporting SQL is that a predictible query language makes it easier to arrange data structures so they can be queried most efficiently. Still, it'd be nice to see an alternative front-end language or two supported in one or more of the major databases. Not every query needs to be ultra-efficient, and there have been many times where I would've liked to trade an efficient query execution for a language where what I wanted was more writeable.
I don't think that being free really has much to do with it, although there could perhaps be a correlation. Probably what matters is the terms of service that you agree to. Even if you pay for the service, virtually all terms of service will contain a clause that states the provider can yank your access or hosting or whatever they provide on a whim at their own discretion.
Clearly it might not hold up in court, and it's perhaps even less likely to hold up if you're paying for a service and they don't have reasonable grounds for not providing it... regardless of what's in the terms of service. But they could still potentially get away with claiming that they don't have time or resources to follow up complaints and have to protect their liability, and it still means going through the court system. The latter is a huge disincentive when it's normally much easier to just find a different provider.
If Al Jazeera's not directly available, there's a great documentary film called Control Room that follows around the Al Jazeera journalists during the US invasion. It has a great summary of their complaints about how the people tearing down the statue were practically US puppets.
Assuming he is telling the truth, I think it's more likely that some kind of scanning software is involved. It'd seem very difficult to either develop sufficiently intelligent software, or to hire people to simply search manually. Even in the latter case, it's unlikely that someone might "accidentally" wander into an open source repository and accidentally assume that a file in the middle of all those other legitimate files happens to be a ripped off movie.
But the intermediate possibility seems much more realistic. My guess is that they have software to do the bulk of the searching and spidering. It probably presents a big list of filenames and perhaps contextual information to a few humans. These people most likely scan down a list checking boxes or clicking buttons on any entry that appears at a glance to be a movie copyright violation, and the pattern-matching system, having received confirmation of the infringement, generates a notice and does the rest.
The human error to which he refers to could quite conceivably be someone simply clicking an incorrect item, or some-such mistake. Just because humans don't run the entire process doesn't mean they can't play a part in it.
I'm not trying to suggest that it should be excused. Chances are that there were a lot more mis-sent notices before this one went wrong. But on objective grounds, it seems premature to write it off on the by claiming that it's impossible for a human error to be involved just because of the sheer volume of infringement notices.
No they don't. It's been studied for decades, but in all that time we've still not settled on anything that's actually demonstrated over long periods of time to be good. Hardware, materials and other available resources are continuously evolving and changing, meaning that software design research has nothing to reliably settle on before things change again.
We don't even have consistent and proven programming languages. Today it's Java, C#, VB and a variety of imperative scripting languages. Yesterday it was C and C++, before that it was Fortran, and before that there have been variants of assembler. And as we use these languages, we're constantly discovering more and more about language design and developing new languages.
HCI is still in very early stages of development, and that's a major part of software engineering. (If people can't use software then what's the point?) The vast majority of software development shops -- particularly smaller ones -- don't even employ HCI experts, and substantial proportions of developers still don't respect them or understand what the point is.
Something like bridge building, for instance, has been studied for centuries (if not millenia). It relies on consistent physics, consistent tools and well understood environments. Organisations that build bridges have well established experience, procedures and regulations that are put in place throughout their organisation. Software development's been studied for a few decades with the existing materials, resources and expectations constantly changed from underneath it.
Organisations that build software still don't have any reasonable idea of how to arrange themselves, or what procedures they should be using. There have certainly been some pretty good ideas from relatively recent ongoing studies, but the fact that managers and developers and marketers and whoever else frequently don't gel together very well with usually bad results is just an ongoing consequence of the fact that it's a very new field.
Just because software engineering has been studied for a few decades doesn't mean we know what we're talking about, or even that we know what we're studying.