Knitting is pretty easy to pick up, and kind of fascinating for a geek: knitting basically boils down to creating an enormous, intricate, single knot in such a way that kind of falls together into a garment of some kind. I found it right up a nerd's alley.
Now, the problem with knitting is that 99% (if not 6-nines or better) of knitters are women[1], so all the patterns are for women's clothes and such. Thus it's not something that's realistically a long-term hobby for a guy, but if you as a man walk into a yarn store with actual knowledge, I guarantee you will find all the female attention you want. The first time it happened I seriously was weirded out, because all I really wanted was some reasonably durable, 100% cotton, worsted weight yarn and a set of double-ended needles for some socks I wanted to make.
So, it's something that will get you attention. It's probably a hobby that'll only last you a year or two, but at least you'll get some socks out of it.
[1] - I have never met a fellow straight male knitter in person, and I am aware of exactly 3 online. So I'm not stereotyping, it's the God's Honest.
Yeah, me too -- though sounds like mine may not be as powerful as yours.
If I pay attention to it, it gets louder (like right now -- you got me thinking about it:), but if I am distracted it is much quieter.
I don't think it's (necessarily) nerve damage though. As far as I can tell (through various extensive Google sessions and a few Dr. Q&As) no one actually knows what it is or what causes it. The conventional wisdom is that there may be more than one cause. High blood pressure, for example, has a correllation with tinnitus, which might very well be what caused it in my case. Loud music obviously has a correllation as well, and stress can make it worse. High blood pressure and loud noise? Yeah, those are two very different causes, so something odd is going on in there.
What is more disturbing (to me at least) is that no one seems to care. The first ENT I asked about this just said, "Oh yeah, that's quite common. Just use white noise to mask it." That was it.
Apparently, though, it's quite common. Given that, you'd think there'd be a pharma company all over it (large potential market) but the pharma companies are all actually DRUG companies, and tinnitus does not smell like the kind of thing you can treat with a pill, so....
Eh well. Maybe someday they'll figure it out before we go all Beethoven.
Authentication process runs fine, right up until the end: "405: Not Allowed". So yeah, that is a full-on Jabber server.
Is there a difference between "Not Allowed" and "Bad password"? That message looks to me like it accepted my gmail username and password, but decided I'm not authorized to use the service.
A lot of people (including me) have been reporting that gmail is down -- 500 internal server error (whereupon gmail pithily suggests you cross your fingers. In the immortal words of Donald Rumsfeld, this is "not helpful.")
Anyway, if they truly ARE lauching an IM service, then it would almost certainly be linked to gmail, and hey, guess what -- gmail is having problems.
> But the point of models like the CMM are to better manage your projects.
No, it isn't, or at least not ultimately. Sorry, but I see this so much that I have to respond.
The dark secret of CMM and its peers is that it is intended *soley* to slow down the software development process. Sure, they say that you're just inserting checkpoints, milestones, "process", and all that. But why?
The simple fact is that under normal circumstances, software engineering is too fluid to monitor. Things change too fast. So, if you have a need to understand *exactly* what is going on *at all times,* what do you do?
You insert things to make it go slower so you can follow and monitor it. Whence, CMM. The degree to which you need to slow down your development process dictates the level of CMM that you strive for.
There are other related benefits too: reducing your dependency on key contributors. But there again, one developer is generally only "better" than another because she can produce the same product in a lesser amount of time. Thus, CMM slows down the development process so that *any* developer can do any task -- they have more time. Thus, CMM breaks dependence on key contributors.
This is why the only places where CMM and friends are truly successful over a long term are large software shops writing code that absolutely cannot go wrong. e.g. NASA (writing Space Shuttle code,) GE Aircraft Engines and Power Systems (writing public-safety-related code) and so on.
It's getting more and more popular for off-shore shops to get ISO or CMM certified, but even there it's not a "look how skilled/fast we are" play, it's a "look how reliable we are" play. They're just aiming to commoditize themselves, usually at the expense of performance.
If you want a technical analogy, it's this: when doing hard real-time programming (e.g. for a power distribution control system, or a medical scanner, or a data capture device) the important thing is (usually) not raw speed. The important thing is *predictability*. When it's mission critical, you don't care about how fast it is, you care about never, ever having something unexpected happen.
VxWorks' scheduler has a hard guarantee of always taking exactly the same amount of time to run, within some small tolerance (like 20 microseconds or something) and it is constant time. RTLinux's scheduler (last time I looked) simply ran as fast as it could, and scaled linearly. Thus, for most mission-critical hard real-time applications, VxWorks is suitable and RTLinux is not. OTOH as we know, normal Linux is great for almost everything else.
Similarly, for the most absolutely vital software development projects, CMM and friends are important; for almost everything else, they are not.
I am not commenting on the EA issue here (which I find deplorable, and which is what keeps me, an experienced, well-rounded, and reasonably talent engineer out of the gaming business.) I'm just nitpicking about CMM.
I WILL say that, given that CMM is intended to slow down software development, and that EA is interested in precisely the opposite (at the expense of their staff,) I believe that CMM is more an answer for the staff than for EA. Guess who wins that battle?
Oh, I certainly have no problem with people using WYSIWYG editors. I just mean that it would be nice if they had some inkling of what those things were DOING.
You use the examples of double declutching [yes I can], and fixing broken plug leads [if I understand you correctly, maybe I can.] I would use simpler analogies of "changing out a flat" or perhaps "changing the oil." Not that you necessarily SHOULD always do it yourself, but having a basic understanding goes a long way.
I can change my oil, but I don't; similarly, I can write HTML, but I don't. (Well, okay actually I do since I can't find a decent WYSIWYG open source editor and CSS makes it so easy, but you know what I mean.)
As for that potential urban legend, I have heard that twisted so many ways I don't know for sure anymore. You'd probably have to ask the guys directly, at this point.:)
That's an interesting point, and one that I have been having a hard time reaching an opinion on.
See, the hacker part of me demands that anyone who has a web page learn HTML: it's not that hard, and it's like having a driver's license -- it's a lowest common denominator of skill. I believe that if every dork with a GeoCities site actually knew HTML instead of exporting from MS Word, the Web would be a better place. So, from that perspective, XHTML is something I support -- though I support it from the sense of replacing HTML (which should die in the eternal fires of Hell) entirely. Making people learn XML would be nice, but it's too complex a thing to make "required reading" for GeoCities weenies.
That said, you are obviously correct in that XML is the way the world should be. In fact, I did some web pages in straight-up well-formed XML coupled with CSS stylesheets, and it worked just fine. The only problems are that with current browsers, you can't use inline embedded images (Mozilla and IE don't support this) or hyperlinks (basically XPath, which IE doesn't support.) So, it looks like the Promised Land is withheld from us, which forces us to use XHTML for a while yet.
So, as you can see, I am wishy-washy on whether I like XHTML, or if I do whether I like it better than XML.
Of course, now I feel like I just did an in-depth evaluation of whether N*Sync or Britney will be more successful in the long run.
Re:I'm so unfashionable, it hurts...
on
Software Fashion
·
· Score: 1
Gaah! God no, not another TBL groupie!:)
It's not so much that I have a problem with... uh... TBL's current research interest, as it is that I just think it's kind of... obvious. The namespace issues are the really hard part, so in the end it just comes down to a lot of grunt work in getting those squared away.
Of course, since we ARE talking about fads here, you're probably right.
Re:I'm so unfashionable, it hurts...
on
Software Fashion
·
· Score: 1
Hmm... I'm a bit of a language nut, so you have now piqued my curiosity. What's TBL?
A few seconds of Google found me this:
http://www.multicians.org/raf-tbl-definition.htm l
Is that what you're talking about? Looks a bit like Prolog, only with some interesting semantic variations on that theme.
In general, I like the idea of highly dynamic languages that provide deep access to the structures of the encompassing system. For example, coding on MUSHes has always been insanely fun, and some of the most interesting and elegant "code tricks" I've ever seen came from what were essentially scripts running embedded inside some larger system.
The big problem with these, of course, is security: when you have easy, deep access to a system's structures, it's easy to make far-reaching errors. Still, I think this is a technique whose time might be about to come again. I think such "mini-languages" will be crucial, as software systems become so complex that it's impossible to maintain them from "outside." Long live "read-eval-print" loops!
Or are you talking about something entirely different?:)
I don't know if I'd put it quite like that. Yes, everyone in the upper leadership came up through the ranks, but in general the military does a pretty good job of making sure that you're the best person for the job.
It's just that all the jobs are about killing people.
You have to remember that these are people who gamble under the highest possible stakes: their own and other people's lives. When the stakes are that high, you simply DO NOT change ANYTHING until someone comes in and damned well proves beyond a shadow of a doubt that their new way is better.
Hence, the military definitely has a culture that corporate we weenies would probably identify as "Not Invented Here Syndrome." However, I argue that if ANYONE has a legitimate right to that position, it's the military.
You know, I was thinking that, myself (that the article is very vague.) I want to know what exactly is going on here. Do you (or does anyone else) know WTF the actual problem is?
The "termination fee" the article mentions is apparently what "local line owner" charges another company to connect a call. e.g. if Sprint owns the physical copper wire to your house/business, then Sprint gets to charge AT&T for the privilege of connecting an AT&T user to you. This seems reasonable to me.
However, given the above, I don't see what the problem is. How does Sprint even know (or care) what AT&T is using on the other side of that boundary? Whether the call data came packet-switched or direct-line, it still has to go over Sprint's copper wires or your phone just isn't going to ring. I don't understand what difference it makes to Sprint, and thus why AT&T (and others) are so hell-bent on switching to VOIP, apparently to "exploit" this issue.
Are the relevant regulations here so mind-numbingly stupid that they specifically restrict Sprint's ability to charge AT&T to only direct-connect calls? Sidestepping the "you have to pay to cross my wires" requirement just by using TCP/IP is a loophole big enough to drive a Mac truck through. If that's actually the case I consider the authors of the regulation at fault, here.
As the author of Tuning and Customizing a Linux System, I can assure you that people are not going to be making "hella" money on a book. So far I have made roughly $5,000 in royalties on my book (which is amittedly below average due to releasing it in a rotten economy) and don't expect to make much more -- and I am the sole author. In the collaborative works, the royalties are divided.
So, no one is going to be getting filthy stinking rich off of your contributions. You only get filthy stinking rich off a single book if you are Stephen King or Danielle Steel. If you want to make a living writing technical books, you have to put out several a year and do it full-time.
Well, I don't think it's so much that, as it is the fact that (in the case of ink at least) you can't store it forever. Anyway, the governments aren't too concerned about the ink and paper or equipment costs, I think, as much as they are concerned about training the workers.
I mean, around here the poll workers are usually retirees, housewives, and so on -- interested people with time on their hands. Training these people to work with a new polling machine is bad enough, but you're basically doubling or tripling the training requirements as soon as you add in having to mess around with paper and ink and so on.
Also, the governments by law have to store those paper ballots for a certain amount of time. They may actually look at a paperless system and say, "Yes! Cheaper storage since we don't need a warehouse/basement for the ballots!"
So, it adds cost in a ton of ways, beyond just the initial cost for the goodies.
Just list the components: a printer; ink cartridges; paper. Note that the last two are consumables, and ink cartridges are even perishable, in a way. (If you let them sit around too long, they get dried out -- or at least non-laser cartridges do.)
Envision, then, what it would take to run an election, remembering that these happen maybe once a year at best. You have, say, 10 machines per polling station. On the days leading to the election, each machine must be installed, powered up, and tested. Then, you have to connect the printer, test the printer, and change any cartridges that might have dried out in the meantime.
During the election, you have to keep the printers fed with paper. The ink might run out on a system halfway through. The printer might jam. Because of this you have to keep spares on hand, from the ink to the paper to the print mechanisms themselves. You only get one shot at election day, after all.
Meanwhile, of course, the polling workers have to be trained and prepared to deal with all this.
In other words, it's a rather significant amount of cost and effort to add printing support to such a system. Even if you don't use standard printers but some other technology, you still have similar problems: e.g. a cash-register-style printer (which is all you'd need) might still jam, and needs to have its paper changed, etc.
So, that's why the manufacturers (and probably even municipalities) are opposed to paper. I don't agree with them -- I believe there SHOULD be paper verification.
I see their position, but it would be nice if they were thinking of something other than the almighty buck.
This is a classic computer science problem: the guy optimized space over time.
He came up with a solution that presents the fewest coins -- that is, the most "compact" solution in space, where space is number of coins. However, this solution comes at the cost of computational complexity -- the time required to figure out the math.
It's an interesting notion, and worth considering, but in practice it's not viable. I value my TIME far more than I value the SPACE in my change purse.:)
One of the things I do is that they'll hand me Yet Another Board(TM) and tell me to make it work. This basically means making the pretty LEDs blink, generate square waves on pins to view on the o-scope, etc. This is always fairly easy, and fun.
The next step up is useful things, like the recent colored globe thingy. That's mostly electronics, with a little bit of hardware thrown in for good measure. Replace the PIC with an FPGA or CPLD and away you go. I once wrote a framebuffer that talked to the RAMDAC -- so I basically built a very basic video card -- for copying video from a webcam to a monitor. That was very challenging, but it worked, and it was cool and all. The common link among all these is that your entire problem basically fits on the FPGA/CPLD.
However, when people say "FPGAs are going to change the world" they are talking about supercomputing applications, or killing the von Neumann model or something. This is where the shit hits the fan.
The reason is that in these cases the whole problem does NOT fit in a single FPGA. Imagine trying to take two CPLDs and make them talk to each other. Now imagine trying to make sure it works at 200MHz without hiccups. Now try making that interact with the PCI bus so you can do DMA busmastering to fetch memory from the host system hardware fast enough to keep the pipeline filled for your number crunching.
So, each individual part is pretty easy: I built the core of a calculation for example, and verified that it works in simulation. However, the "boundary effects" are a nightmare, and we still have to talk to memory, etc.
You make an analogy to software, but I bet what you're really seeing is that the software you've developed is more "complicated" than the hobbyist projects you've done, which is why it's harder.
But in the end you're right -- it's not really all that hard. In my experience software people underestimate their skills and assume they will never understand hardware. Hardware IS fun and I think more people can do it. All I'm saying is when you get into the realm of developing giant number crunching apps on it, it gets just as difficult (if not more so) than equivalently large software.
We have looked at StarBridge but were not impressed. Nallatech's hardware is at least as practical, and is far more real (since people actually use it today.) StarBridge is, as near as we can tell, horribly overselling their product, which is unfortunately not uncommon in this field.
I could go on, but I think to do so might be uncharitable so I'll stop here.:)
Slashdot Mirror
Nah. I like it where I am.
Let them use BSD were no loophole is required if that's what they want.
Eh... we do. Except that it's Apache 2.0, which is just like BSD but with an anti-patent-burn clause.
And BTW, parent post is spot-on.
- Dan
Why do you even bother, man? :)
Seriously.
Knitting is pretty easy to pick up, and kind of fascinating for a geek: knitting basically boils down to creating an enormous, intricate, single knot in such a way that kind of falls together into a garment of some kind. I found it right up a nerd's alley.
Now, the problem with knitting is that 99% (if not 6-nines or better) of knitters are women[1], so all the patterns are for women's clothes and such. Thus it's not something that's realistically a long-term hobby for a guy, but if you as a man walk into a yarn store with actual knowledge, I guarantee you will find all the female attention you want. The first time it happened I seriously was weirded out, because all I really wanted was some reasonably durable, 100% cotton, worsted weight yarn and a set of double-ended needles for some socks I wanted to make.
So, it's something that will get you attention. It's probably a hobby that'll only last you a year or two, but at least you'll get some socks out of it.
[1] - I have never met a fellow straight male knitter in person, and I am aware of exactly 3 online. So I'm not stereotyping, it's the God's Honest.
- Dan
Yeah, me too -- though sounds like mine may not be as powerful as yours.
:), but if I am distracted it is much quieter.
If I pay attention to it, it gets louder (like right now -- you got me thinking about it
I don't think it's (necessarily) nerve damage though. As far as I can tell (through various extensive Google sessions and a few Dr. Q&As) no one actually knows what it is or what causes it. The conventional wisdom is that there may be more than one cause. High blood pressure, for example, has a correllation with tinnitus, which might very well be what caused it in my case. Loud music obviously has a correllation as well, and stress can make it worse. High blood pressure and loud noise? Yeah, those are two very different causes, so something odd is going on in there.
What is more disturbing (to me at least) is that no one seems to care. The first ENT I asked about this just said, "Oh yeah, that's quite common. Just use white noise to mask it." That was it.
Apparently, though, it's quite common. Given that, you'd think there'd be a pharma company all over it (large potential market) but the pharma companies are all actually DRUG companies, and tinnitus does not smell like the kind of thing you can treat with a pill, so....
Eh well. Maybe someday they'll figure it out before we go all Beethoven.
Authentication process runs fine, right up until the end: "405: Not Allowed". So yeah, that is a full-on Jabber server.
Is there a difference between "Not Allowed" and "Bad password"? That message looks to me like it accepted my gmail username and password, but decided I'm not authorized to use the service.
NICE! Why didn't I think of trying that?
Hmm. Now I wonder if I can point GAIM at it and log in with my gmail address........
A lot of people (including me) have been reporting that gmail is down -- 500 internal server error (whereupon gmail pithily suggests you cross your fingers. In the immortal words of Donald Rumsfeld, this is "not helpful.")
Anyway, if they truly ARE lauching an IM service, then it would almost certainly be linked to gmail, and hey, guess what -- gmail is having problems.
Integration difficulties, maybe?
> But the point of models like the CMM are to better manage your projects.
No, it isn't, or at least not ultimately. Sorry, but I see this so much that I have to respond.
The dark secret of CMM and its peers is that it is intended *soley* to slow down the software development process. Sure, they say that you're just inserting checkpoints, milestones, "process", and all that. But why?
The simple fact is that under normal circumstances, software engineering is too fluid to monitor. Things change too fast. So, if you have a need to understand *exactly* what is going on *at all times,* what do you do?
You insert things to make it go slower so you can follow and monitor it. Whence, CMM. The degree to which you need to slow down your development process dictates the level of CMM that you strive for.
There are other related benefits too: reducing your dependency on key contributors. But there again, one developer is generally only "better" than another because she can produce the same product in a lesser amount of time. Thus, CMM slows down the development process so that *any* developer can do any task -- they have more time. Thus, CMM breaks dependence on key contributors.
This is why the only places where CMM and friends are truly successful over a long term are large software shops writing code that absolutely cannot go wrong. e.g. NASA (writing Space Shuttle code,) GE Aircraft Engines and Power Systems (writing public-safety-related code) and so on.
It's getting more and more popular for off-shore shops to get ISO or CMM certified, but even there it's not a "look how skilled/fast we are" play, it's a "look how reliable we are" play. They're just aiming to commoditize themselves, usually at the expense of performance.
If you want a technical analogy, it's this: when doing hard real-time programming (e.g. for a power distribution control system, or a medical scanner, or a data capture device) the important thing is (usually) not raw speed. The important thing is *predictability*. When it's mission critical, you don't care about how fast it is, you care about never, ever having something unexpected happen.
VxWorks' scheduler has a hard guarantee of always taking exactly the same amount of time to run, within some small tolerance (like 20 microseconds or something) and it is constant time. RTLinux's scheduler (last time I looked) simply ran as fast as it could, and scaled linearly. Thus, for most mission-critical hard real-time applications, VxWorks is suitable and RTLinux is not. OTOH as we know, normal Linux is great for almost everything else.
Similarly, for the most absolutely vital software development projects, CMM and friends are important; for almost everything else, they are not.
I am not commenting on the EA issue here (which I find deplorable, and which is what keeps me, an experienced, well-rounded, and reasonably talent engineer out of the gaming business.) I'm just nitpicking about CMM.
I WILL say that, given that CMM is intended to slow down software development, and that EA is interested in precisely the opposite (at the expense of their staff,) I believe that CMM is more an answer for the staff than for EA. Guess who wins that battle?
Oh, I certainly have no problem with people using WYSIWYG editors. I just mean that it would be nice if they had some inkling of what those things were DOING.
:)
You use the examples of double declutching [yes I can], and fixing broken plug leads [if I understand you correctly, maybe I can.] I would use simpler analogies of "changing out a flat" or perhaps "changing the oil." Not that you necessarily SHOULD always do it yourself, but having a basic understanding goes a long way.
I can change my oil, but I don't; similarly, I can write HTML, but I don't. (Well, okay actually I do since I can't find a decent WYSIWYG open source editor and CSS makes it so easy, but you know what I mean.)
As for that potential urban legend, I have heard that twisted so many ways I don't know for sure anymore. You'd probably have to ask the guys directly, at this point.
That's an interesting point, and one that I have been having a hard time reaching an opinion on.
See, the hacker part of me demands that anyone who has a web page learn HTML: it's not that hard, and it's like having a driver's license -- it's a lowest common denominator of skill. I believe that if every dork with a GeoCities site actually knew HTML instead of exporting from MS Word, the Web would be a better place. So, from that perspective, XHTML is something I support -- though I support it from the sense of replacing HTML (which should die in the eternal fires of Hell) entirely. Making people learn XML would be nice, but it's too complex a thing to make "required reading" for GeoCities weenies.
That said, you are obviously correct in that XML is the way the world should be. In fact, I did some web pages in straight-up well-formed XML coupled with CSS stylesheets, and it worked just fine. The only problems are that with current browsers, you can't use inline embedded images (Mozilla and IE don't support this) or hyperlinks (basically XPath, which IE doesn't support.) So, it looks like the Promised Land is withheld from us, which forces us to use XHTML for a while yet.
So, as you can see, I am wishy-washy on whether I like XHTML, or if I do whether I like it better than XML.
Of course, now I feel like I just did an in-depth evaluation of whether N*Sync or Britney will be more successful in the long run.
Gaah! God no, not another TBL groupie! :)
It's not so much that I have a problem with... uh... TBL's current research interest, as it is that I just think it's kind of... obvious. The namespace issues are the really hard part, so in the end it just comes down to a lot of grunt work in getting those squared away.
Of course, since we ARE talking about fads here, you're probably right.
Hmm... I'm a bit of a language nut, so you have now piqued my curiosity. What's TBL?
m l
:)
A few seconds of Google found me this:
http://www.multicians.org/raf-tbl-definition.ht
Is that what you're talking about? Looks a bit like Prolog, only with some interesting semantic variations on that theme.
In general, I like the idea of highly dynamic languages that provide deep access to the structures of the encompassing system. For example, coding on MUSHes has always been insanely fun, and some of the most interesting and elegant "code tricks" I've ever seen came from what were essentially scripts running embedded inside some larger system.
The big problem with these, of course, is security: when you have easy, deep access to a system's structures, it's easy to make far-reaching errors. Still, I think this is a technique whose time might be about to come again. I think such "mini-languages" will be crucial, as software systems become so complex that it's impossible to maintain them from "outside." Long live "read-eval-print" loops!
Or are you talking about something entirely different?
I don't know if I'd put it quite like that. Yes, everyone in the upper leadership came up through the ranks, but in general the military does a pretty good job of making sure that you're the best person for the job.
It's just that all the jobs are about killing people.
You have to remember that these are people who gamble under the highest possible stakes: their own and other people's lives. When the stakes are that high, you simply DO NOT change ANYTHING until someone comes in and damned well proves beyond a shadow of a doubt that their new way is better.
Hence, the military definitely has a culture that corporate we weenies would probably identify as "Not Invented Here Syndrome." However, I argue that if ANYONE has a legitimate right to that position, it's the military.
You know, I was thinking that, myself (that the article is very vague.) I want to know what exactly is going on here. Do you (or does anyone else) know WTF the actual problem is?
The "termination fee" the article mentions is apparently what "local line owner" charges another company to connect a call. e.g. if Sprint owns the physical copper wire to your house/business, then Sprint gets to charge AT&T for the privilege of connecting an AT&T user to you. This seems reasonable to me.
However, given the above, I don't see what the problem is. How does Sprint even know (or care) what AT&T is using on the other side of that boundary? Whether the call data came packet-switched or direct-line, it still has to go over Sprint's copper wires or your phone just isn't going to ring. I don't understand what difference it makes to Sprint, and thus why AT&T (and others) are so hell-bent on switching to VOIP, apparently to "exploit" this issue.
Are the relevant regulations here so mind-numbingly stupid that they specifically restrict Sprint's ability to charge AT&T to only direct-connect calls? Sidestepping the "you have to pay to cross my wires" requirement just by using TCP/IP is a loophole big enough to drive a Mac truck through. If that's actually the case I consider the authors of the regulation at fault, here.
Hmm... What kind of 'rigor' is that, again? Rigor mortis?
Well, I don't disagree with you. :) I'm not saying I'm happy about people getting a book out with... um... "extensive external assistance."
I'm just saying that no one is going to get truly RICH off it.
As the author of Tuning and Customizing a Linux System, I can assure you that people are not going to be making "hella" money on a book. So far I have made roughly $5,000 in royalties on my book (which is amittedly below average due to releasing it in a rotten economy) and don't expect to make much more -- and I am the sole author. In the collaborative works, the royalties are divided.
So, no one is going to be getting filthy stinking rich off of your contributions. You only get filthy stinking rich off a single book if you are Stephen King or Danielle Steel. If you want to make a living writing technical books, you have to put out several a year and do it full-time.
Just my perspective...
Well, I don't think it's so much that, as it is the fact that (in the case of ink at least) you can't store it forever. Anyway, the governments aren't too concerned about the ink and paper or equipment costs, I think, as much as they are concerned about training the workers.
I mean, around here the poll workers are usually retirees, housewives, and so on -- interested people with time on their hands. Training these people to work with a new polling machine is bad enough, but you're basically doubling or tripling the training requirements as soon as you add in having to mess around with paper and ink and so on.
Also, the governments by law have to store those paper ballots for a certain amount of time. They may actually look at a paperless system and say, "Yes! Cheaper storage since we don't need a warehouse/basement for the ballots!"
So, it adds cost in a ton of ways, beyond just the initial cost for the goodies.
It's quite simple: because it adds cost.
Just list the components: a printer; ink cartridges; paper. Note that the last two are consumables, and ink cartridges are even perishable, in a way. (If you let them sit around too long, they get dried out -- or at least non-laser cartridges do.)
Envision, then, what it would take to run an election, remembering that these happen maybe once a year at best. You have, say, 10 machines per polling station. On the days leading to the election, each machine must be installed, powered up, and tested. Then, you have to connect the printer, test the printer, and change any cartridges that might have dried out in the meantime.
During the election, you have to keep the printers fed with paper. The ink might run out on a system halfway through. The printer might jam. Because of this you have to keep spares on hand, from the ink to the paper to the print mechanisms themselves. You only get one shot at election day, after all.
Meanwhile, of course, the polling workers have to be trained and prepared to deal with all this.
In other words, it's a rather significant amount of cost and effort to add printing support to such a system. Even if you don't use standard printers but some other technology, you still have similar problems: e.g. a cash-register-style printer (which is all you'd need) might still jam, and needs to have its paper changed, etc.
So, that's why the manufacturers (and probably even municipalities) are opposed to paper. I don't agree with them -- I believe there SHOULD be paper verification.
I see their position, but it would be nice if they were thinking of something other than the almighty buck.
This is a classic computer science problem: the guy optimized space over time.
:)
He came up with a solution that presents the fewest coins -- that is, the most "compact" solution in space, where space is number of coins. However, this solution comes at the cost of computational complexity -- the time required to figure out the math.
It's an interesting notion, and worth considering, but in practice it's not viable. I value my TIME far more than I value the SPACE in my change purse.
One of the things I do is that they'll hand me Yet Another Board(TM) and tell me to make it work. This basically means making the pretty LEDs blink, generate square waves on pins to view on the o-scope, etc. This is always fairly easy, and fun.
The next step up is useful things, like the recent colored globe thingy. That's mostly electronics, with a little bit of hardware thrown in for good measure. Replace the PIC with an FPGA or CPLD and away you go. I once wrote a framebuffer that talked to the RAMDAC -- so I basically built a very basic video card -- for copying video from a webcam to a monitor. That was very challenging, but it worked, and it was cool and all. The common link among all these is that your entire problem basically fits on the FPGA/CPLD.
However, when people say "FPGAs are going to change the world" they are talking about supercomputing applications, or killing the von Neumann model or something. This is where the shit hits the fan.
The reason is that in these cases the whole problem does NOT fit in a single FPGA. Imagine trying to take two CPLDs and make them talk to each other. Now imagine trying to make sure it works at 200MHz without hiccups. Now try making that interact with the PCI bus so you can do DMA busmastering to fetch memory from the host system hardware fast enough to keep the pipeline filled for your number crunching.
So, each individual part is pretty easy: I built the core of a calculation for example, and verified that it works in simulation. However, the "boundary effects" are a nightmare, and we still have to talk to memory, etc.
You make an analogy to software, but I bet what you're really seeing is that the software you've developed is more "complicated" than the hobbyist projects you've done, which is why it's harder.
But in the end you're right -- it's not really all that hard. In my experience software people underestimate their skills and assume they will never understand hardware. Hardware IS fun and I think more people can do it. All I'm saying is when you get into the realm of developing giant number crunching apps on it, it gets just as difficult (if not more so) than equivalently large software.
We have looked at StarBridge but were not impressed. Nallatech's hardware is at least as practical, and is far more real (since people actually use it today.) StarBridge is, as near as we can tell, horribly overselling their product, which is unfortunately not uncommon in this field.
:)
I could go on, but I think to do so might be uncharitable so I'll stop here.