mydb.execute("insert into contacts values('Spooky','Monster','spook@spammity.spam')") Couldn't you have at least done an example that doesn't promote bad practices with quoting? My experience with sqlite (admittedly using the Tcl binding) is that it gets this stuff far more correct and easy to use in practice than any other database API that I've seen. I don't know if the python bindings are of that same quality; if they are, they're top notch. The code I would have written? Like this:
set first "Spooky" set last "Monster" set email "spook@spammity.spam" # In practice it's really easy to put values into variables mydb eval {insert into contacts values (:first,:last,:email)}
The advantage? That code is now totally armour-plated against SQL injection attacks as well as being fast. Which is nice, really really nice.
On linux you rarely, if ever, get problems like this because the updates are handled centrally. The problem with a central repository is that it only works well for applications that are blessed by the Central Committee. Guess what? That doesn't cover everything that people want; they need extra stuff, and for all sorts of reasons. Supporting ways of distributing software without having to go through the One True Central Repository is a good thing, since not everyone (other than a former Gentoo developer) wants to do their own distro!
Indeed, I've seen a lot of software over the years that comes perilously close to requiring its own distro, and everyone has always hated it. What people want is to be able to run the software on their existing installations; they want RH+X, SuSE+Y, Ubuntu+Z. They're right to want such things, but that leads you straight back into the territory of problems with updating, where we started.
Bah! Sometimes you can't really win. You can just not suck too much...
you mustn't encourage [the grammar nazis], that's like throwing chum to a shark. I'd quite like to skip that step and move on by throwing the grammar nazis to the shark...
Sometimes I wonder whether open-source software should also recieve public funds, though I have to admit I can't think of any good way that could possibly be arranged... It happens already with some open-source software packages. Typically, when this is happening, it is because that software is also serving other purposes than being open-source (e.g. providing some key piece of software infrastructure that a government needs and which commercial providers don't offer yet). On the other hand, I'd hate for taxes to be the only way that OSS gets funded; if there's something I want doing a lot, I should be allowed to pay for it to be written. A mixed funding ecology (what we have now to a first approximation) is probably best.
Multitouch is a nice new addition to touch technology, but you know what? I hardly ever use it on my iPhone. I rarely zoom in or out. I click and drag a lot, and double-tap to zoom in and out, but this is nothing that couldn't have been done on a mid-90s Palm. Multitouch works really nicely on laptops; scrolling by using two fingers together rather than one just feels so natural. In fact, it reminds me of how the scrollwheel felt like a big advance in practical HCI before it; "You mean I don't have to search for the scrollbar or the paging keys in order to move up and down? Lovely!"
For me, the probable next step forward is when we get better haptics integrated with touch. For example, though the iPhone is decidedly neat, it's tricky (by comparison with a normal mobile phone) to use without looking at it since you can't feel where the buttons are. And I don't know about you, but I don't want to have to look at what my fingers are doing in order to use a device (yes, I can touch type)...
Does Yahoo have a plan to increase their share price by 73% in the [next 5 years]? If not, [the Yahoo board] failed at their responsiblity to maximize shareholder wealth. I think if you look more carefully, the board has a responsibility to increase shareholder wealth by pursuing a line of business. If you think they shouldn't be in that business at all, you're a damn fool for investing in them. (Now, if they changed to a new line of business in backing monoline insurers or something else that's now known to be stupidly risky right now, you might have a reasonable claim on the fiduciary responsibility front.) The board doesn't have a responsibility to ensure that you personally maximize your own profit on a short-term investment; people who think they do are Wall Street scumbag leeches of the worst sort as they don't know the real difference between money and wealth.
If I had to guess (and I would have to) I would think the Fifth Amendment is probably more applicable. Its final clause is "nor shall private property be taken for public use, without just compensation". Hacking your system and using CPU cycles and bandwidth without permission would seem to constitute at least a form of taking of my property. They may not physically take it but they take control of it and even though I get it back later the clause doesn't say it's ok for them to take property as long as they bring it back. So... would that mean that they'd have to exempt you from income tax or something like that? I can think of a fair number of people who could consider that to be a good trade.
And no one is walking around naked! That's the problem right there! A severe shortage of people walking around naked (preferably attractive, and of a gender preferred by the viewer).
Mind you, if there were enough of such folks, perhaps we wouldn't be so worried about blurring faces...
One of the biggest problems with this "standard" is that it specifically allows proprietary add-ons. A way of handling proprietary add-ons is pretty common for standards in the computing space (especially when they're based on XML). As long as those add-ons are used in a judicious way, they're not a big problem. (The "formatLikeWord95" stuff could be done in such a way, for example. Most people don't actually care to replicate such bugs in the formatting engine, just so long as they can read the text in the first place.) The problem comes when there are vendors who require these extensions to make sense of a document at all, and who won't produce documents without them.
Now, if you really want to complain about OOXML, what about the lack of a compliance test suite? Is there a way for an independent third-party to definitively determine whether an implementation meets the specification, and hence whether it is able to claim to be OOXML-compliant? That would do a lot towards ensuring that it is a real standard. Whether or not you actually like it or the method by which the spec was produced are a separate and lesser matter.
And supersonic air travel did not pay when oil was $20 a barrel, how can it ever pay at $120 ? The problem was that nobody ever built large supersonic planes that can fly supersonic on any route. Get the size and flexibility up, and you can make it pay (fuel costs aren't the only factor in running a plane, not by a long stretch). Getting rid of the sonic boom would help that a lot.
How about properties like homes? In case you hadn't noticed, homes aren't people and as such don't have rights. Imagine if they did! The right to have the roof kept in good repair, the right to be aired out on a regular basis, the right to remain silent (except in high winds).
Offline mode has never worked for me. I find this out everytime my DSL is down for whatever reason, and I actually want to play a single-player game. And then I can't... It used to cause problems for me too, but it seems that they've patched that to work (and quite a while back; I don't recall seeing trouble for ages now). Remember folks, sometimes bugs really do get fixed!
Slashdot's answer is to allow the mob (users) to moderate, but Brady, since he's from the more traditional media, is wary of the mob. The mob has all sorts of biases and tends to reinforce its beliefs. It may be interesting discourse, but it can be difficult to get a balanced discourse -- and this is something the Post is committed to, for better or/and worse. I respect the editor wanting to get balance, though he needs to be careful to not mistake it for fairness; if everyone and his dog are dumping on a message, it might just be because it's a pile of stupid rubbish. But still, fairness and balance are things that it is important to respect.
I suppose the easiest way to deal with this is for there to be a slashdot-like mechanism - it does work well most of the time - and for there to be some users (probably a small number of Post staffers) who can act as supermoderators to ensure that important dissent doesn't get lost. Of course, the moderations made by the supermods should be available for people to see so that people can decide for themselves if the supermods are being fair.
I'll take Fair and Open over Balanced; I can make my own mind up. (Not that there's anything wrong with Balanced as such.)
The easiest way is to authenticate by cell phone number. You're suggesting that internet fora be restricted to the country where they're hosted? (Actually, that's reasonable in some cases, but not for a major newspaper or Slashdot.) Or maybe you're suggesting that the site shoulder international SMS fees? (I really doubt that a cost as low as $0.05 per message is obtainable there...)
That is not to say it's not impossible for them to do so. Apple did provide a virtual machine to run old OS9 software with the first releases of OS X. They still do with Leopard, and in my experience it works really well. (There are some recoverable crashes, but I can't tell if that's in the VM or the applications themselves. Not really something I want to care about.)
I'm tired of reading replies to this article that evangelize some fancy-schmancy high-level solution. I wonder if these advocates have ever tried writing production code in such an environment. There are different sorts of production environment, you know. Some value stability over raw speed, others like to emphasize short time-to-market. (Yeah, yeah, I know everyone actually cares about speed, stability, quick development, maintainability, etc. but you have to pick which things you stress, since that determines what corners you cut...)
The truth is that threading is a professional power tool. Like any pro power tool, you have to be careful and know how to use it, or it will rip your arm off (well, metaphorically) but it does do what you tell it to and can lead to great results.
Shared memory threading is basically just having two (or more) CPUs let rip on the same piece of memory. It can do great stuff, but it can also go wrong horribly easily and it is infamous for heisenbugs. Message-passing threading, and while it has higher overheads for smaller configurations, it is easier to debug and it scales up much larger (since it's not hard to pass messages to other processes, other computers or even other clusters); indeed, the largest message-passing system in the world is massively parallel and goes by the name of The Internet. Shared memory systems simply can't scale up that large. (As a side note, the apotheosis of a shared memory system came in some of the supercomputers in the '90s, which had very complex memory management hardware to make the model work; these days, supercomputers use message passing because it's far easier to scale that up.)
Threads solve a number of programming problems much more elegantly than forked processes and sharing data through some IPC mechanisms. Anecdote time: a stock price system I worked on. The first generation used separate processes for a single writer and a large number of readers, with shared memory for interprocess communication. Out of curiosity, what other things were the readers and writers doing? Was the overall system IO-bound or CPU-bound? Threads only help for CPU-bound problems; for IO-bound stuff, you're better off using asynchronous processing.
Those features are not used frequently. They are more efficient and faster but at the cost of complexity. In most situations you're better off with clean, easily debugged, and more obviously correct code. In Linux, the performance hit from the simple approach isn't so bad. The rest is there because it's interesting to work on (frankly) and for that 1% or so cases where it can actually be justified. While I'm not 100% sure what you're talking about there, I'll assume it's asynch IO. The key to it is that the default API for it on both Unix and Windows is a bit low-level for most people; it really requires a higher-level abstraction on top so that you can work in terms of event-driven callbacks. At that point, asynch IO becomes much simpler since you can think in terms of "when there's data available, process it" which is (to my mind) easier than having to have loads of threads stamping on each others' toes.
The only real benefit of threads comes when you are CPU-bound, and when you can avoid locking lots of memory through intelligent algorithms. Get that right and you can get a lot of speedup from getting multiple cores going on the same problem. Alas, it remains a research-level problem for many tasks...
Right, select() was fine in the single-core days, but an application with a single process with a single thread won't utilize more than about one-fourth of a quad-core server. What do you plan to do with the other three cores, or with the time that the server process spends waiting for the disk? With the other cores, you can be doing processing relating to dynamic webpages (the main server can be handling other requests in the meantime) and the server process should be handling disk IO also in an asynchronous manner. Get that sort of stuff right (not too hard to do) and virtually all the processing is done in IO hardware with just the occasional bit of coordination by the CPU. Which is exactly how IO-bound processing is supposed to work!
Or would you rather have all four cores spinning on the spot waiting for IO?
On the other hand, you can always just go around to the back of your computer and flip the hard switch on your power supply. Never mind that, you can always cut the power cable with bolt cutters. (Make sure you're using insulated bolt cutters if doing this; frying yourself just to show your computer who's boss is a little extreme...)
Millions and millions of people driving over 2000 billion miles accident free every day. There are millions driving 0.34 light years each every day? Dang! That's fast, especially compared to those slow-coach photons who take nearly 18 weeks to do the same! Still, it seems that even Alpha Centauri is a bit too far for commuting (though great for a road trip).
It is the auto-resizing text input area that most people feel is silly and pointless.
If by "most people" you mean "a small handful of people" then yes.. "most people". FYI, users aren't too keen on things that automatically resize as they do things. I know this because I've experimented with this sort of thing back when I was doing heavy GUI development; I added the feature, and couldn't find a single person who liked it. I did have a good number of people who wanted the feature taken out of the software and, for preference, buried face down in a shallow grave. From this, I conclude that things shouldn't resize when they are showing on the screen unless the user is resizing them (when they should react perfectly to whatever crazy size is chosen) since otherwise users don't feel in control of their machines.
Actually, the main thing that would make for 21st-Century cred is accepting UTF-8 text. Agreed, even though I'm an English speaker.
I've had a couple of posts recently on topics where it would have been better to use Chinese or Japanese characters (though not very many of them). More to the point, those of us who are math and science geeks (I hear there are a few round here) will like being able to express basic things like greek letters, superscripts, assorted operators, etc. Browsers have got a lot better at their UTF-8 support over the past few years, and there are a good few decent fonts about too.
What are the reasons for holding back? Well, the main one is that the current database holds the data in ISO-8859-1 (probably) and would either need converting or at least to have some kind of migration strategy (extra column for the encoding?) which could be rather messy.
But it's not just a problem with the commercial software. I've never met a mail program I really liked. Mail software seems to be a vast wasteland of sucktude. I like to single out Notes and Exchange because if you work in IT you're pretty much forced to use them, but I've used and not liked pine, mutt, the emacs lisp based web client, the Apple mail client, Thunderbird and Evolution. I use Thunderbird these days (on the grounds that it then provides consistency across all the computers I use, and it's a reasonable sIMAP client) but there are a few things which drive me up the wall. For example, why is the Edit->Rewrap functionality never bound to a key? And why can't it make filtering easier? Apple Mail makes filtering really easy, but it doesn't seem to believe in priority tagging (which I need to handle my personal open-issue list, and which represents a personalized view across a lot of bug-tracker databases, and isn't something I can recreate easily) and it doesn't work nearly well when you also need to access your mailboxes from Linux and Windows. And it pretty much requires the use of the mouse for normal functionality; at least Thunderbird is largely drivable by keyboard.
Slashdot Mirror
set first "Spooky"
set last "Monster"
set email "spook@spammity.spam"
# In practice it's really easy to put values into variables
mydb eval {insert into contacts values (:first,:last,:email)}
The advantage? That code is now totally armour-plated against SQL injection attacks as well as being fast. Which is nice, really really nice.
Indeed, I've seen a lot of software over the years that comes perilously close to requiring its own distro, and everyone has always hated it. What people want is to be able to run the software on their existing installations; they want RH+X, SuSE+Y, Ubuntu+Z. They're right to want such things, but that leads you straight back into the territory of problems with updating, where we started.
Bah! Sometimes you can't really win. You can just not suck too much...
For me, the probable next step forward is when we get better haptics integrated with touch. For example, though the iPhone is decidedly neat, it's tricky (by comparison with a normal mobile phone) to use without looking at it since you can't feel where the buttons are. And I don't know about you, but I don't want to have to look at what my fingers are doing in order to use a device (yes, I can touch type)...
</rant>
Mind you, if there were enough of such folks, perhaps we wouldn't be so worried about blurring faces...
Now, if you really want to complain about OOXML, what about the lack of a compliance test suite? Is there a way for an independent third-party to definitively determine whether an implementation meets the specification, and hence whether it is able to claim to be OOXML-compliant? That would do a lot towards ensuring that it is a real standard. Whether or not you actually like it or the method by which the spec was produced are a separate and lesser matter.
I suppose the easiest way to deal with this is for there to be a slashdot-like mechanism - it does work well most of the time - and for there to be some users (probably a small number of Post staffers) who can act as supermoderators to ensure that important dissent doesn't get lost. Of course, the moderations made by the supermods should be available for people to see so that people can decide for themselves if the supermods are being fair.
I'll take Fair and Open over Balanced; I can make my own mind up. (Not that there's anything wrong with Balanced as such.)
The truth is that threading is a professional power tool. Like any pro power tool, you have to be careful and know how to use it, or it will rip your arm off (well, metaphorically) but it does do what you tell it to and can lead to great results.
Shared memory threading is basically just having two (or more) CPUs let rip on the same piece of memory. It can do great stuff, but it can also go wrong horribly easily and it is infamous for heisenbugs. Message-passing threading, and while it has higher overheads for smaller configurations, it is easier to debug and it scales up much larger (since it's not hard to pass messages to other processes, other computers or even other clusters); indeed, the largest message-passing system in the world is massively parallel and goes by the name of The Internet. Shared memory systems simply can't scale up that large. (As a side note, the apotheosis of a shared memory system came in some of the supercomputers in the '90s, which had very complex memory management hardware to make the model work; these days, supercomputers use message passing because it's far easier to scale that up.)
The only real benefit of threads comes when you are CPU-bound, and when you can avoid locking lots of memory through intelligent algorithms. Get that right and you can get a lot of speedup from getting multiple cores going on the same problem. Alas, it remains a research-level problem for many tasks...
Or would you rather have all four cores spinning on the spot waiting for IO?
What are the reasons for holding back? Well, the main one is that the current database holds the data in ISO-8859-1 (probably) and would either need converting or at least to have some kind of migration strategy (extra column for the encoding?) which could be rather messy.