We don't have flying cars but we do have this. In color, high definition and in multichannel theater sound. Interactive and affordable. $1700 at Walmart.
Not everyone -- or even everyone in middle-class America -- can afford to spend $1700 on a piece of equipment targeted strictly at entertainment.
If I had $1700, I could pay off some of my wife's outstanding medical bills. Hire someone to bring the ventilation of my bathrooms up to code. Fix the doors to my garage. Pay down the line of credit I used to pay my self-employment taxes on a few years ago. Buy a little more equity in my house. Start setting up a buffer to live off of if something happens to my job. Each and every one of these things is easier for me to justify than buying a new television.
Now, granted, my employer is a startup, and so the cash component of my pay isn't what it would be elsewhere -- but even if I were making $25,000 more than I am right now, I'd still have a huge laundry list of More Worthwhile Things which would take a year or two to pay off, by which time there'd probably be still more of them.
Spending $100-200 on a piece of entertainment equipment which will see extended use (like a low-end console)? Justifyable, so long as other entertainment expenses are kept to a minimum. A $500 console which requires a $1700 television to fully take advantage of it? Not whatsoever.
My point? The Revolution has a market, one that the higher-end next-gen consoles are foresaking.
Actually, multi-card authentication is already the norm: you carry around at least one card form every institution, and people understand what "could you please also show me your driver's license" means. A multi-smartcard approach would not increase the number of cards, it would simply get rid of the paper and make the identification card itself more secure than it is now.
Wait a moment here -- I thought we were talking about legally mandated, government-issued IDs. If we're talking about changing the behaviour of privately-issued cards (health insurance, banking, etc), that's a different topic.
Global identifiers are here and they are unavoidable. All we can do is make them work better.
Having them not work better allows one a practical, widely accepted argument to curb their abuse: The fact that they really and frequently do fail. The TSA may not have stopped what they're doing, but they have gotten some less-than-happy inquiries from Congresscritters -- inquires they wouldn't have otherwise received -- and perhaps some level of oversight may follow. Eliminate even that argument, and the extent of abuse will only increase.
that's great, but when i want to go hack up my bookmarks, i don't want to download the latest sqllite bindings for perl...i just want to write some regexes to hack the file.
Well, it's not like you *need* the Perl bindings -- you can use the SQLite command-line tool to dump the database contents to stdout and then use awk or something to filter through that. Same thing works for reading through your bookmarks from home. Sure, it's an extra tool you need -- but it's one that your modern distros will have already packaged.
you're not going to beat the accessibility of a text file, and there is not a speed/transaction/etc issue that needed to be solved.
With the text file, load time is going to vary linearly with number of entries. With SQLite, it may not be constant time (I don't know), but it's *much* more flat.
Anyhow, why not go track down the Bugzilla entry associated with the feature and find out what the reasoning behind implementing it was, rather than just blindly calling it needless?
This will also almost certainly kill any chance of reusage of bookmark data by other programs
Not at all. SQLite is extremely easy to use -- it has bindings for major scripting languages, and trivial queries can be run on the command line. I use the Python bindings in a number of my minor scripts, and it has frequently resulted in a massive performance improvement (as opposed to using flatfiles and writing the data-munging and analysis code myself).
I think putting everything into a single card is a bad idea; the safest way of keeping information apart is to keep it in separate cards.
The public won't like carrying around several cards, the costs incurred in issuing them and keeping them up to date would be higher, and the divisions of information (with regard to who needs what) aren't necessarily clear and well-defined enough that a small set of cards could contain every frequently-required combination. I don't see the multi-card approach happening.
A mechanism by which individuals can review which specific information they allow to be read from their card before permitting the read would perhaps be more reasonable -- though this would require either additional logic in the reader (in which case it would be subvertable by an unscrupulous operator to retrieve and store more data than it claims) or more hardware to be carried around by the user (such that it's their own hardware which reviews and approves the read); hardware capable of running a read without the user's consent would be available to law enforcement for use only where sufficient cause to demand ID exists (which I understand to be pretty much universal these days -- unfortunate). While this would better safeguard individuals' personal security, I doubt that the extra cost and complexity would be considered justified.
I believe all you can do is create a system that reduces the need for centralized databases, while at the same time creating strong legislation that limits and in many cases outlaws the creation of such centralized databases.
In principal, I agree with you. In practice, I think the law enforcement communities (particularly those involved in recent "anti-terrorism" infrastructure buildouts) would succesfully oppose any law regulating the creation or use of central databases lacking broad-reaching exemptions for their own use, or would subvert any such system after the fact by passing legislation granting them additional powers later. Having a global identifier becomes a temptation to use that identifier to have a single clearinghouse of information even on individuals not suspected (far less convicted) of any crime; having the correlations which could be made by such a system be reliable (as opposed to the system which has resulted in the TSA's publicly visible goofs) makes such abuse that much more inviting.
I don't have answers to the other elements of this thread, but the national ID topic (and particularly, your assertion that such a system could be implemented in such a manner as to enhance privacy) continues to be interesting.
I don't see why a national ID system needs to result in centralization. In fact, quite to the contrary, a good national ID system could be used to enforce de-centralization, for example through the use of smartcards.
This assertion strikes me as handwaving -- without a good implementation available which supports decentralization, and realistic political support for such an implementation as opposed to a more centralized alternative, I just don't see it. Perhaps this is a lack of imagination on my part.
What are you proposing, specifically? A smart card containing information about an individual (digitally signed to prevent forgeries) but without a common identifier usable for correlating between databases? A card with an identifier, but with support for selective reads (such that the minimum necessary information -- and only that information -- can be retrieved)? Laws preventing the smart card's full contents (as opposed to minimum necessary information) from being stored in a centralized database? If it's one of the "minimum necessary information" approaches, who determines what that set of information is? Or perhaps what you foresee is something else entirely; if so, I'd be interested to hear it.
The primary effect that is relevant here is that, as a retiree, you will consume scarce resources without being productive, and the more money you saved during your working years, the more scarce resources you will consume for your leisure activities.
Granted, folks who are no longer working in retirement consume scarce resources even when living off personal savings. However, I submit that the positive economic impact of the effort such people put into the system to accrue such resources as to be able to enjoy a reasonable standard of living in retirement outweighs the later drag. Economics is, after all, not a zero-sum game.
Admittedly, this is an unsupported assertion. Admittedly, some study is needed to determine the truth of the matter. Admittedly, similar reasoning has been used to justify less paletable conclusions (ie. the retroactive effects of the DMCA), and analysis is thus valuable in such cases.
I fully support privacy and a firmly limited government. That is precisely why I think a good national ID card system is needed: it improves privacy and lets us limit what government can do with our data. Contrast that with the current system, with its patchwork of regulations and insecure identifiers and tokens.
I don't see centralization as being an improvement on the patchwork. Yes, it allows for more effective regulation and limitation should such be implemented -- but it also allows more room for abuse, and it's been recently demonstrated that a substantial subset of the American populace is willing to give up privacy rights and permit more expansive government powers in return for percieved security.
Your single minded approach amounts to little more than "social Darwinism", and it was popular in the early 20th century, along with lots of other ineffective and amoral political theories.
Whether something is moral or otherwise obviously depends on the perspective of the viewer -- members of the religious right have one perspective; you have another; and I have yet another. Raw assertions regarding moral principals aren't necessarily useful in a discussion along these lines, simply because in many cases they can't be effectively or objectively argued to an individual working from different base principals. Practicality, on the other hand -- that's a different and more reasonable approach, and I'll admit that some of the policies I argue for are not in practice implementable within the US as it stands.
Your kids will pay for your retirement--it doesn't matter how you dress it up: privat retirement accounts, social security, whatever. Even if you stuff money under a mattress, when you use it to buy services once you're retired, you're still depriving your kids of the same amount of goods and services. It's not a "Ponzi scheme", it's a simple economic truth.
Spoken like someone who hasn't taken a macroeconomics class. Stuffing money under a mattress keeps it out of the economy and deprives others of its use. Keeping it in a savings account; investing it (traditionally in stocks, bonds or some mix thereof); and eventually spending it all makes it available for others to use: The bank holding the savings account loans it out to others; the bonds are used to finance government projects; the stocks are used to finance means of production; and expendatures mean that it falls into someone else's hands such that *they* can invest or spend it, all of which helps the economy.
So -- folks who have enough savings to retire off of benefit the economy their kids are working in while those savings are invested, and benefit their kids' economy when the funds are spent. Failing to save and leeching off the future economy via taxes, on the other hand, is an entirely different matter.
If right wing nuts didn't keep interfering in the deployment of a secure national ID system, you wouldn't have to worry about that.
Erm. That's not just "right wing nuts", there. Privacy is a pretty darned effectively-entrenched American value -- as is having a firmly limited government. Folks don't need to be Christian fundies, oppose reproductive rights or want to legislate their moral views to appreciate those principals. Indeed, most of the folks I know who tend towards the traditional "left" haven't identified themselves to me as staunch supporters of the national ID thing, and I'd submit that it's only the staunchest left wing nuts (and neo-cons, who are more authoritarian than conservative) who support it.
The only difference between SSI and other plans is that SSI makes sure everybody is forced to create a minimal income they can live on, and that's good thing.
If SSI were actually run as originally intended, it would be one thing (though still coercive, and thus morally corrupt if my Libertarian hat is on today). However, when the government starts paying back those who are cashing out from income supposedly going into the private accounts of those coming in, it is indeed nothing more than a legalized and legislated Ponzi scheme -- and those always fall over, sooner or later.
[nuttiness]Personally, I'd rather take the risk of starving. If I've been of sufficient value to society to be worth the cost of my upkeep, I'll either have accrued sufficient assets to live off of, or have third parties willing to voluntarily pay said costs. If I haven't, the extent to which I am a detriment to society obviously outweighs my benefit. Isn't making such optimal decisions precisely what the free market is best at?[/nuttiness]
You don't need IAX, SIP extensions using a cheap Grandstream ATA will do faxes.
See, we did that in-house for a while (with SPA-2100 IIRC), and it never worked passably: We had upwards of a 50% failure rate. Granted, our network is less-than-ideal, but frankly I'll be happy to be rid of the hardware components anyhow. (My employer has a very limited hardware budget and our one fax machine is an ancient Brother POS; I've been suggesting that it be replaced for quite some time now, to no avail).
Fax machines are the cheapest way to get a scanner that has an automatic document feeder, that's why this solution will usually end up the lowest cost.
Right, but we already have a $900 full-duplex, color scanner with an ADF. (We wouldn't have forked out the cash generally -- but it's the same hardware we recommend to our customers, so we needed to have one in-house for testing and such). That'll cover everything from the faxes to the high-quality stuff -- for any more specialized purposes one can use the flatbed scanners in the artists' area.
saned will allow remoting for any scanner supported by SANE, not just USB ones -- and it makes advanced scripting and such very easy. (Further, the SANE API is dirt simple to code for, so if there isn't already a tool that does what you're looking for it's easy to write or adopt one).
They cost around $900 each, but the fi-5120C2 my company recommends to our customers are very nice scanners -- auto document feed (just throw stuff in the hopper), full-duplex full-color scanning at up to 25 pages per minute. (Mind you, you need a faster connection than USB1 for that full speed if you're going to be doing more than 200DPI black-and-white images. They support both USB2 and SCSI, but we've only tested USB2 -- but even with that you need to cut down the quality if you need the full 25 pages per minute).
See, TWAIN integrates the GUI into the scanner driver -- so you can't have a shell script that kicks off a scan without the driver having specific support; ugh! The single-button scan solutions which are presently available for Windows are pretty much all proprietary to the individual scanner (far as I know), and not inherently pluggable.
This is why SANE is so damn useful even on Windows -- it provides an API for scanner access which is completely frontend-agnostic.
This is also why the folks talking about WSH are off-base -- even if WSH is extremely flexible, it doesn't get you away from the scanner-manufacturer-provided GUI which needs to be clicked through to start a scan, or (in the alternate) the proprietary mechanism used for kicking off the single-button-press scan mechanism.
There's no reason to buy something off-the-shelf for this -- SANE's scanadf (with one of the drivers which can detect the scanner's start button press -- I just hacked up a solution for this with a slightly modified version of SANE's Fujitsu drivers and a less slightly modified version of the buttonpress detection tool out of SANE's "experimental" CVS module yesterday), in conjunction with a script for doing the upload, will do the trick. (Alternately, you could use NFS, SMBFS, DAVFS, etc. in place of FTP and just do a simple filesystem mount; I'd consider that more straightforward). I typically call scanadf with a filename based on the current timestamp -- so push the button and all the papers in your hopper come out as files named on the date/time the scan was started and the page# (based on ordering within the ADF). This means you need to have reasonable defaults for your scanning settings if you're going to do the single-button-press thing -- but for my purposes, 300DPI black-and-white works for just 'bout everything.
As an aside: One of my personal projects is building an setup that uses SANE, HylaFAX+iaxphone+asterisk and CUPS to scan items to a network drive (either shared space or, if they log in, password-protected space; this latter functionality is important for HR and other folks handling confidential documents); scan items to an outgoing fax; allow folks to print incoming faxes queued in their name and all that other nifty jazz. Don't know when I'll actually have something ready for release, though -- might be a bit, particularly as taking something I threw together as a once-off (which this will be, at first) and packaging it up for redistribution and reuse takes time.
The ballot boxes should be under the control of neutral (or as neutral as possible) observers, not members of a political sect
I'd argue that having each ballot box accessible only when members of multiple competing political sects are present would be more effective. Honest, genuinely neutral "neutral observers" who are willing to sign up to help in an election are harder to find than dyed-in-the-wool factionists with an interest in keeping an eye out to make sure the opposing factions don't get away with anything.
Nontechnical users should use proper package management for everything. When it comes to production machines, technical users should as well.
Yup. And at my employer, we use proper package management for everything -- but the distro-provided packages aren't always good enough (or just plain don't include packages we need), so we often build, test [though our QA department] and deploy our own. Using package management for everything doesn't mean having no need for a compiler -- and rebuilding a src.rpm into a binary is an easy enough operation that it's a reasonable thing for nontechnical users to do.
I *am* having a bit of trouble justifying keeping a compiler as part of the install on the production servers (as opposed to the dev ones where we do the packaging) -- but keeping one as an available-by-default part of any distro is just good policy: Folks should be able to rebuild source packages when need be.
Firefox is only on workstations -- headless servers typically won't have a web browser; my company's certainly don't. I was thinking gcc would be a better candidate: Not only is it installed on a strong majority of Linux-based systems, but also on a large number of traditional Unix systems elsewhere.
Let me get this right -- two instance of the base class's variables within a single instance of a class which has inherited from two subclasses... and you *want* this behaviour? I'll grant that there may be cases where it's useful, but I just don't see them off the top of my head -- especially when using something like super() for calling one's superclasses' constructors in MRO order such that a given constructor never gets called more than once.
For an example of why I consider Python's multiple inheritance implementation to be superior, see the MRO algorithm used in modern interpreters (for new-style objects only, to prevent backwards compatibility issues).
That said, I've never much liked C++ -- for low-level work I've always tended towards C, and for high-level work I prefer powerful languages that didn't have the kitchen sink thrown into the syntax (read: not Perl either) -- so I probably don't know C++ as well as you do. That said, I do use Python on a regular basis, including some code that makes heavy use of some of its more obscure features. ("Obscure features" is relative, of course -- there's no syntax specifically for most of them [take swapping out an object's class with another dynamically constructed class inheriting from a dynamically generated list of bases as an example], and they work pretty naturally with the language, but they're things most folks not used to Python wouldn't expect to be able to do). (And wrt the dynamic-class-generation thing -- yes, I have a real-world use for that).
Granted, it's not the most useful implementation in the world, but python supports multiple inheritance.
Python's multiple inheritance implementation (using post-2.2 new-style objects) is pretty darned good; I'm curious as to what limitations you see in it.
And people actually like that as a feature of the language?!
Perhaps it's telling as to the value of the feature that folks who've used Python for a while do come to consider the use of significant whitespace to be a feature: If folks who actually use it come to like it quickly, is it likely to really be as bad as folks who haven't used it tend to think?
In other languages, whitespace provides an opportunity for confusion if the whitespace doesn't match the actual flow control; in Python, the whitespace always matches the flow control. Moreover, Python code simply looks clean. (There are some post-2.x language features which allow for funky-looking code if abused, but "funky-looking code" by Pythonic standards is much, much cleaner than what almost any other group would call "funky-looking").
Scheme has status as a traditional teaching language in some circles, and there are good materials for it. Python tends to be quite good in my experience as well -- I once held a programming class for interested middle school students using Python, and none of them had difficulties with the language (though algorithmic thinking was more of an issue; next time, I'm waiting 'till after they've passed algebra).
Python certainly comes with enough of a standard library to be immediately useful; it has far less gotchas than C (my personal favorite for low-level work), C++ (its never-should-have-been-born evil sibling) and kin; it's an OO language but can be used procedurally; and if one is the sort to want to entertain rather than focus on teaching the core stuff, there are toolkits for doing fun/entertaining things trivially (see VPython for an example). Along those same lines, CMU's ALICE is also interesting -- I think that at one time they were using or porting to Python, though I haven't been up on it for quite some time.
All that said, unlike Scheme, Python is a language that gets quite a bit of real-world commercial use in places that aren't "scheme shops". It's easy to learn, powerful, and not only the general skills but the specific language knowledge will be applicable later -- what's not to like?
There are other options, you know -- taxes that don't require invasion into personal privacy; this is just one more reason why the personal income tax is broken. See the FairTax for one example.
Just because something is established doesn't mean it's good.
Slashdot Mirror
And neither does having received orders under the same high authority that had you released from captivity?
$35 each, or $35? In the latter case, you got a decent deal.
I typically pay about $7-$9 per (not always used) title at Half Price Books.
If I had $1700, I could pay off some of my wife's outstanding medical bills. Hire someone to bring the ventilation of my bathrooms up to code. Fix the doors to my garage. Pay down the line of credit I used to pay my self-employment taxes on a few years ago. Buy a little more equity in my house. Start setting up a buffer to live off of if something happens to my job. Each and every one of these things is easier for me to justify than buying a new television.
Now, granted, my employer is a startup, and so the cash component of my pay isn't what it would be elsewhere -- but even if I were making $25,000 more than I am right now, I'd still have a huge laundry list of More Worthwhile Things which would take a year or two to pay off, by which time there'd probably be still more of them.
Spending $100-200 on a piece of entertainment equipment which will see extended use (like a low-end console)? Justifyable, so long as other entertainment expenses are kept to a minimum. A $500 console which requires a $1700 television to fully take advantage of it? Not whatsoever.
My point? The Revolution has a market, one that the higher-end next-gen consoles are foresaking.
Actually, multi-card authentication is already the norm: you carry around at least one card form every institution, and people understand what "could you please also show me your driver's license" means. A multi-smartcard approach would not increase the number of cards, it would simply get rid of the paper and make the identification card itself more secure than it is now.
Wait a moment here -- I thought we were talking about legally mandated, government-issued IDs. If we're talking about changing the behaviour of privately-issued cards (health insurance, banking, etc), that's a different topic.
Global identifiers are here and they are unavoidable. All we can do is make them work better.
Having them not work better allows one a practical, widely accepted argument to curb their abuse: The fact that they really and frequently do fail. The TSA may not have stopped what they're doing, but they have gotten some less-than-happy inquiries from Congresscritters -- inquires they wouldn't have otherwise received -- and perhaps some level of oversight may follow. Eliminate even that argument, and the extent of abuse will only increase.
that's great, but when i want to go hack up my bookmarks, i don't want to download the latest sqllite bindings for perl...i just want to write some regexes to hack the file.
Well, it's not like you *need* the Perl bindings -- you can use the SQLite command-line tool to dump the database contents to stdout and then use awk or something to filter through that. Same thing works for reading through your bookmarks from home. Sure, it's an extra tool you need -- but it's one that your modern distros will have already packaged.
you're not going to beat the accessibility of a text file, and there is not a speed/transaction/etc issue that needed to be solved.
With the text file, load time is going to vary linearly with number of entries. With SQLite, it may not be constant time (I don't know), but it's *much* more flat.
Anyhow, why not go track down the Bugzilla entry associated with the feature and find out what the reasoning behind implementing it was, rather than just blindly calling it needless?
This will also almost certainly kill any chance of reusage of bookmark data by other programs
Not at all. SQLite is extremely easy to use -- it has bindings for major scripting languages, and trivial queries can be run on the command line. I use the Python bindings in a number of my minor scripts, and it has frequently resulted in a massive performance improvement (as opposed to using flatfiles and writing the data-munging and analysis code myself).
I think putting everything into a single card is a bad idea; the safest way of keeping information apart is to keep it in separate cards.
The public won't like carrying around several cards, the costs incurred in issuing them and keeping them up to date would be higher, and the divisions of information (with regard to who needs what) aren't necessarily clear and well-defined enough that a small set of cards could contain every frequently-required combination. I don't see the multi-card approach happening.
A mechanism by which individuals can review which specific information they allow to be read from their card before permitting the read would perhaps be more reasonable -- though this would require either additional logic in the reader (in which case it would be subvertable by an unscrupulous operator to retrieve and store more data than it claims) or more hardware to be carried around by the user (such that it's their own hardware which reviews and approves the read); hardware capable of running a read without the user's consent would be available to law enforcement for use only where sufficient cause to demand ID exists (which I understand to be pretty much universal these days -- unfortunate). While this would better safeguard individuals' personal security, I doubt that the extra cost and complexity would be considered justified.
I believe all you can do is create a system that reduces the need for centralized databases, while at the same time creating strong legislation that limits and in many cases outlaws the creation of such centralized databases.
In principal, I agree with you. In practice, I think the law enforcement communities (particularly those involved in recent "anti-terrorism" infrastructure buildouts) would succesfully oppose any law regulating the creation or use of central databases lacking broad-reaching exemptions for their own use, or would subvert any such system after the fact by passing legislation granting them additional powers later. Having a global identifier becomes a temptation to use that identifier to have a single clearinghouse of information even on individuals not suspected (far less convicted) of any crime; having the correlations which could be made by such a system be reliable (as opposed to the system which has resulted in the TSA's publicly visible goofs) makes such abuse that much more inviting.
I don't have answers to the other elements of this thread, but the national ID topic (and particularly, your assertion that such a system could be implemented in such a manner as to enhance privacy) continues to be interesting.
I don't see why a national ID system needs to result in centralization. In fact, quite to the contrary, a good national ID system could be used to enforce de-centralization, for example through the use of smartcards.
This assertion strikes me as handwaving -- without a good implementation available which supports decentralization, and realistic political support for such an implementation as opposed to a more centralized alternative, I just don't see it. Perhaps this is a lack of imagination on my part.
What are you proposing, specifically? A smart card containing information about an individual (digitally signed to prevent forgeries) but without a common identifier usable for correlating between databases? A card with an identifier, but with support for selective reads (such that the minimum necessary information -- and only that information -- can be retrieved)? Laws preventing the smart card's full contents (as opposed to minimum necessary information) from being stored in a centralized database? If it's one of the "minimum necessary information" approaches, who determines what that set of information is? Or perhaps what you foresee is something else entirely; if so, I'd be interested to hear it.
Just an initial word: You make good points.
The primary effect that is relevant here is that, as a retiree, you will consume scarce resources without being productive, and the more money you saved during your working years, the more scarce resources you will consume for your leisure activities.
Granted, folks who are no longer working in retirement consume scarce resources even when living off personal savings. However, I submit that the positive economic impact of the effort such people put into the system to accrue such resources as to be able to enjoy a reasonable standard of living in retirement outweighs the later drag. Economics is, after all, not a zero-sum game.
Admittedly, this is an unsupported assertion. Admittedly, some study is needed to determine the truth of the matter. Admittedly, similar reasoning has been used to justify less paletable conclusions (ie. the retroactive effects of the DMCA), and analysis is thus valuable in such cases.
I fully support privacy and a firmly limited government. That is precisely why I think a good national ID card system is needed: it improves privacy and lets us limit what government can do with our data. Contrast that with the current system, with its patchwork of regulations and insecure identifiers and tokens.
I don't see centralization as being an improvement on the patchwork. Yes, it allows for more effective regulation and limitation should such be implemented -- but it also allows more room for abuse, and it's been recently demonstrated that a substantial subset of the American populace is willing to give up privacy rights and permit more expansive government powers in return for percieved security.
Your single minded approach amounts to little more than "social Darwinism", and it was popular in the early 20th century, along with lots of other ineffective and amoral political theories.
Whether something is moral or otherwise obviously depends on the perspective of the viewer -- members of the religious right have one perspective; you have another; and I have yet another. Raw assertions regarding moral principals aren't necessarily useful in a discussion along these lines, simply because in many cases they can't be effectively or objectively argued to an individual working from different base principals. Practicality, on the other hand -- that's a different and more reasonable approach, and I'll admit that some of the policies I argue for are not in practice implementable within the US as it stands.
Your kids will pay for your retirement--it doesn't matter how you dress it up: privat retirement accounts, social security, whatever. Even if you stuff money under a mattress, when you use it to buy services once you're retired, you're still depriving your kids of the same amount of goods and services. It's not a "Ponzi scheme", it's a simple economic truth.
Spoken like someone who hasn't taken a macroeconomics class. Stuffing money under a mattress keeps it out of the economy and deprives others of its use. Keeping it in a savings account; investing it (traditionally in stocks, bonds or some mix thereof); and eventually spending it all makes it available for others to use: The bank holding the savings account loans it out to others; the bonds are used to finance government projects; the stocks are used to finance means of production; and expendatures mean that it falls into someone else's hands such that *they* can invest or spend it, all of which helps the economy.
So -- folks who have enough savings to retire off of benefit the economy their kids are working in while those savings are invested, and benefit their kids' economy when the funds are spent. Failing to save and leeching off the future economy via taxes, on the other hand, is an entirely different matter.
If right wing nuts didn't keep interfering in the deployment of a secure national ID system, you wouldn't have to worry about that.
Erm. That's not just "right wing nuts", there. Privacy is a pretty darned effectively-entrenched American value -- as is having a firmly limited government. Folks don't need to be Christian fundies, oppose reproductive rights or want to legislate their moral views to appreciate those principals. Indeed, most of the folks I know who tend towards the traditional "left" haven't identified themselves to me as staunch supporters of the national ID thing, and I'd submit that it's only the staunchest left wing nuts (and neo-cons, who are more authoritarian than conservative) who support it.
The only difference between SSI and other plans is that SSI makes sure everybody is forced to create a minimal income they can live on, and that's good thing.
If SSI were actually run as originally intended, it would be one thing (though still coercive, and thus morally corrupt if my Libertarian hat is on today). However, when the government starts paying back those who are cashing out from income supposedly going into the private accounts of those coming in, it is indeed nothing more than a legalized and legislated Ponzi scheme -- and those always fall over, sooner or later.
[nuttiness]Personally, I'd rather take the risk of starving. If I've been of sufficient value to society to be worth the cost of my upkeep, I'll either have accrued sufficient assets to live off of, or have third parties willing to voluntarily pay said costs. If I haven't, the extent to which I am a detriment to society obviously outweighs my benefit. Isn't making such optimal decisions precisely what the free market is best at?[/nuttiness]
We already have small-form-factor diskless hardware sitting around, but that's an interesting device to know about; thanks!
You don't need IAX, SIP extensions using a cheap Grandstream ATA will do faxes.
See, we did that in-house for a while (with SPA-2100 IIRC), and it never worked passably: We had upwards of a 50% failure rate. Granted, our network is less-than-ideal, but frankly I'll be happy to be rid of the hardware components anyhow. (My employer has a very limited hardware budget and our one fax machine is an ancient Brother POS; I've been suggesting that it be replaced for quite some time now, to no avail).
Fax machines are the cheapest way to get a scanner that has an automatic document feeder, that's why this solution will usually end up the lowest cost.
Right, but we already have a $900 full-duplex, color scanner with an ADF. (We wouldn't have forked out the cash generally -- but it's the same hardware we recommend to our customers, so we needed to have one in-house for testing and such). That'll cover everything from the faxes to the high-quality stuff -- for any more specialized purposes one can use the flatbed scanners in the artists' area.
saned will allow remoting for any scanner supported by SANE, not just USB ones -- and it makes advanced scripting and such very easy. (Further, the SANE API is dirt simple to code for, so if there isn't already a tool that does what you're looking for it's easy to write or adopt one).
They cost around $900 each, but the fi-5120C2 my company recommends to our customers are very nice scanners -- auto document feed (just throw stuff in the hopper), full-duplex full-color scanning at up to 25 pages per minute. (Mind you, you need a faster connection than USB1 for that full speed if you're going to be doing more than 200DPI black-and-white images. They support both USB2 and SCSI, but we've only tested USB2 -- but even with that you need to cut down the quality if you need the full 25 pages per minute).
See, TWAIN integrates the GUI into the scanner driver -- so you can't have a shell script that kicks off a scan without the driver having specific support; ugh! The single-button scan solutions which are presently available for Windows are pretty much all proprietary to the individual scanner (far as I know), and not inherently pluggable.
This is why SANE is so damn useful even on Windows -- it provides an API for scanner access which is completely frontend-agnostic.
This is also why the folks talking about WSH are off-base -- even if WSH is extremely flexible, it doesn't get you away from the scanner-manufacturer-provided GUI which needs to be clicked through to start a scan, or (in the alternate) the proprietary mechanism used for kicking off the single-button-press scan mechanism.
There's no reason to buy something off-the-shelf for this -- SANE's scanadf (with one of the drivers which can detect the scanner's start button press -- I just hacked up a solution for this with a slightly modified version of SANE's Fujitsu drivers and a less slightly modified version of the buttonpress detection tool out of SANE's "experimental" CVS module yesterday), in conjunction with a script for doing the upload, will do the trick. (Alternately, you could use NFS, SMBFS, DAVFS, etc. in place of FTP and just do a simple filesystem mount; I'd consider that more straightforward). I typically call scanadf with a filename based on the current timestamp -- so push the button and all the papers in your hopper come out as files named on the date/time the scan was started and the page# (based on ordering within the ADF). This means you need to have reasonable defaults for your scanning settings if you're going to do the single-button-press thing -- but for my purposes, 300DPI black-and-white works for just 'bout everything.
As an aside: One of my personal projects is building an setup that uses SANE, HylaFAX+iaxphone+asterisk and CUPS to scan items to a network drive (either shared space or, if they log in, password-protected space; this latter functionality is important for HR and other folks handling confidential documents); scan items to an outgoing fax; allow folks to print incoming faxes queued in their name and all that other nifty jazz. Don't know when I'll actually have something ready for release, though -- might be a bit, particularly as taking something I threw together as a once-off (which this will be, at first) and packaging it up for redistribution and reuse takes time.
I'd argue that having each ballot box accessible only when members of multiple competing political sects are present would be more effective. Honest, genuinely neutral "neutral observers" who are willing to sign up to help in an election are harder to find than dyed-in-the-wool factionists with an interest in keeping an eye out to make sure the opposing factions don't get away with anything.
Nontechnical users should use proper package management for everything. When it comes to production machines, technical users should as well.
Yup. And at my employer, we use proper package management for everything -- but the distro-provided packages aren't always good enough (or just plain don't include packages we need), so we often build, test [though our QA department] and deploy our own. Using package management for everything doesn't mean having no need for a compiler -- and rebuilding a src.rpm into a binary is an easy enough operation that it's a reasonable thing for nontechnical users to do.
I *am* having a bit of trouble justifying keeping a compiler as part of the install on the production servers (as opposed to the dev ones where we do the packaging) -- but keeping one as an available-by-default part of any distro is just good policy: Folks should be able to rebuild source packages when need be.
Firefox is only on workstations -- headless servers typically won't have a web browser; my company's certainly don't. I was thinking gcc would be a better candidate: Not only is it installed on a strong majority of Linux-based systems, but also on a large number of traditional Unix systems elsewhere.
Let me get this right -- two instance of the base class's variables within a single instance of a class which has inherited from two subclasses... and you *want* this behaviour? I'll grant that there may be cases where it's useful, but I just don't see them off the top of my head -- especially when using something like super() for calling one's superclasses' constructors in MRO order such that a given constructor never gets called more than once.
For an example of why I consider Python's multiple inheritance implementation to be superior, see the MRO algorithm used in modern interpreters (for new-style objects only, to prevent backwards compatibility issues).
That said, I've never much liked C++ -- for low-level work I've always tended towards C, and for high-level work I prefer powerful languages that didn't have the kitchen sink thrown into the syntax (read: not Perl either) -- so I probably don't know C++ as well as you do. That said, I do use Python on a regular basis, including some code that makes heavy use of some of its more obscure features. ("Obscure features" is relative, of course -- there's no syntax specifically for most of them [take swapping out an object's class with another dynamically constructed class inheriting from a dynamically generated list of bases as an example], and they work pretty naturally with the language, but they're things most folks not used to Python wouldn't expect to be able to do). (And wrt the dynamic-class-generation thing -- yes, I have a real-world use for that).
Indeed, I just ran and the only output was "bar".
Granted, it's not the most useful implementation in the world, but python supports multiple inheritance.
Python's multiple inheritance implementation (using post-2.2 new-style objects) is pretty darned good; I'm curious as to what limitations you see in it.
Perhaps it's telling as to the value of the feature that folks who've used Python for a while do come to consider the use of significant whitespace to be a feature: If folks who actually use it come to like it quickly, is it likely to really be as bad as folks who haven't used it tend to think?
In other languages, whitespace provides an opportunity for confusion if the whitespace doesn't match the actual flow control; in Python, the whitespace always matches the flow control. Moreover, Python code simply looks clean. (There are some post-2.x language features which allow for funky-looking code if abused, but "funky-looking code" by Pythonic standards is much, much cleaner than what almost any other group would call "funky-looking").
Scheme has status as a traditional teaching language in some circles, and there are good materials for it. Python tends to be quite good in my experience as well -- I once held a programming class for interested middle school students using Python, and none of them had difficulties with the language (though algorithmic thinking was more of an issue; next time, I'm waiting 'till after they've passed algebra).
Python certainly comes with enough of a standard library to be immediately useful; it has far less gotchas than C (my personal favorite for low-level work), C++ (its never-should-have-been-born evil sibling) and kin; it's an OO language but can be used procedurally; and if one is the sort to want to entertain rather than focus on teaching the core stuff, there are toolkits for doing fun/entertaining things trivially (see VPython for an example). Along those same lines, CMU's ALICE is also interesting -- I think that at one time they were using or porting to Python, though I haven't been up on it for quite some time.
All that said, unlike Scheme, Python is a language that gets quite a bit of real-world commercial use in places that aren't "scheme shops". It's easy to learn, powerful, and not only the general skills but the specific language knowledge will be applicable later -- what's not to like?
There are other options, you know -- taxes that don't require invasion into personal privacy; this is just one more reason why the personal income tax is broken. See the FairTax for one example.
Just because something is established doesn't mean it's good.