"Antibacterial" household products contain something different than soap. What thing that is, varies.
I'm not a chemist or a doctor. And I assume that if this is mistaken in any way, someone will correct me, since this is/. after all.
For household use you don't need antibacterial agents to effectively wash your hands - because the act of actual abrasion with the surface-tension eliminating properties of soap removes most things from your skin. For the most part, your hands don't harbor a lot of problems IN the surface, because your body is busy killing that.
In my opinion, there are also two major classes of these antibacterial agents - which I'll classify as "simple" and "complex" To my knowledge, it's extremely difficult and rare for bacteria to become resist to "simple" antibacterial agents.
Simple antibacterial agents are things that kill everything. Like bleach (e.g. Chlorox), or high concentrations of alcohol (e.g. Glass Plus). To a lesser extent vinegar, ammonia, salt... These things are not necessarily good for people, but people are really big and can avoid drinking them in really high doses... but they're still really bad for bacteria etc to swim completely in and they get annihilated, because these things basically just melt cell walls.
For the most part these are quite safe to clean with... they don't especially build up in your system, so as long as you never get a super high dose, usually by breathing or drinking it, you're safe. But I don't recommend you swim in bleach, get it in your eyes, and drink it either. Those example cleaners are relatively harmless in most controlled cleaning situations - but there are plenty of options in this category that aren't - like strong acids - we just don't usually put them in consumer cleaners in high doses.
So I have no objection to, say, a little bleach being added to surface cleaners.
The antibiotics you take orally are wildly different, and must be complex. They can't be TOO bad for you, or they'd be rat poison and not a drug. So they try to attack something bacteria-cell specific that human cells are immune to. But bacteria operate in a range of ways, so often this only works on some bacteria. And they mutate... so the more specific and narrow the antibiotic is, the easier it is for the bacteria to become immune. The broader it is, the more likely it hurts you.
Some companies - because it's what the uneducated consuming public wants - are putting vaguely these kind of agents in household cleaning products. Not EXACTLY the same drugs we're taking orally. But chemicals that have narrow, complex effects on bacteria, which probably encourage mutation. Those mutations may or may not impact the effectiveness of current or future drugs.
HOWEVER, as much as I think antibacterial hand soap is pretty high on the list of evils, it's not NEARLY as bad as the number of people who merely don't finish the antibiotics they were prescribed. Those people are ruining the world.
As a rule, this idea is usually backwards. In order to gather significant power from this, you're basically increasing the amount of energy the vehicles expend - because for this to work, you have to keep the pavement bouncy enough to generate the power. (Put another way, the vehicle is most efficient if the pavement is very flat and very rigid)
So you're usually sucking energy FROM poorly maintained oil driven vehicles and putting it TO a grid that at least hypothetically could be powered by nuclear or wind at much lower cost and environmental impact.
The major kinds of places this sort of technique is useful: a) because the main problem is that you NEED to be far away and disconnected from the grid... b) where the bounce energy you're trying to capture is orders of magnitude smaller than the actual bouncing action c) where the initial energy is biomechanical, which is both pretty efficient and otherwise hard to optimize further.
Using this to power small road sensors that didn't need to be wired up would be fine. Using it to power an efficient laptop would be fine - if you're actively looking for a way to easily get more exercise. Using it to power a watch is pretty much ideal, which is why this has been around a long time.
I've heard that about Exchange's monolithic mail stores, which are obviously a huge problem for any kind of size or traffic. But obviously, it doesn't have to be that way... use maildir. I used to agree with your "get it all off the mailserver" philosophy, but now I think it should be "use a better mailserver"
In more details:
I think email is a clearly inferior file _transfer_ mechanism to, say, Subversion, which is what we use to share files we're collaborating on. But if you _don't_ have something like SVN/CVS to use for this, email is perhaps the most accessible system that has offline viewing for all participants, redundant local backups on everyone's machine, and most importantly versioning.
But there's no better way to archive and index email than to keep it as email. If that's how someone DID send you the file, you should be able to look it up there and retrieve it... even if you're going to move old mail to some kind of read-only storage. Moving it all locally onto a not-necessarily-backed-up workstation... and making it difficult to sync to a new workstation - just is not as good as a serverbased solution.
In the early days of 3.5" floppies being common, my floppy broke one more step...
I had spent a couple weeks on a programming project - basically a lame, wildly feature-incomplete clone of lynx in assembly. I had a backup of the couple weeks of programming... but not the last 36 solid hours or so of last minute push. And then the disk stopped working.
So suspecting a filesystem corruption, I brought it to a couple ubergeeks, one of them ran a raw sector read on it... there was just nothing there, no filesystem, no sectors. I was actually in the Mechanical Engineering department, so around then it occurred to us to LOOK at the disk - when you spun the little metal part, the little media part DIDN'T spin; they had become detached.
So... I took a toothpick. And some superglue. And I glued the media back to the metal. A few seconds and another raw sector read later, I had 100% of my code... in the wrong order. Actually I had about 160% of my code... there were a ton of repeated sections.
But I could figure that out well enough; day was saved for me.
Educate me - because right now, this sounds like FUD to me.
>> Within the corporate world, Exchange really does rule.
By monopoly, yes. This I don't contest at all. Nor your point about uniformity, but I don't think that always means you should jump to the most popular system.
>> There's nothing like it that can scale to 10,000+ users, be centrally administered
I'll admit I haven't PERSONALLY tried, but I know of 10,000+ sites that have moved to Groupwise or Lotus. I doubt either of those solutions doesn't scale, considering the vendors. Novell has been in this business LONGER than Microsoft has, but they don't have Windows to leverage.
>> and has such a wide variety of client access---outlook for the web (or whatever it's >> called) is really slick. I haven't seen anything even close to it.
Maybe Outlook Web Access is much cooler than the competition; I haven't compared that feature.
But, are you actually saying you should use Outlook because it's more PLATFORM COMPATIBLE? Certain of the most fun features of OWA don't work quite right if you're not using IE on Windows, but I can't fault them for taking extra advantage of what they know. But you're talking about the only major system without a reliably functioning OS X client (Entourage is reliably problematic when you actually try to use it with Exchange), the only one without any support at all for a Linux client, and the only one where the server will only run on Windows. You realize Novell and IBM actually MAKE Linux and OS X clients for their solutions, right? It's not only that some enterprising Linux dev reverse engineered the API, like for Evolution.
If you're going to say we should all adopt a single collaboration environment (why can't we just get along) then why would you choose one that's just not possible, on the server, to use for a place that's a mac shop or a Linux shop - perhaps a place that's afraid of the BSA after all the nasty things they've done.
And if you're going to say we should all adopt a single standalone _calendar_ format, and not a collaboration suite, then I think when Mozilla and Google and Apple are all using the RFC 2445 iCal format, the battle for the _compatible_ calendar format is settled. Guess what? Of the above major collaboration suites, Outlook seems the only one with iCal support that is limited, at least per Wikipedia. (No TODOs, Journals, etc.) Historically, Microsoft is consistently slow to adopt standards, and routinely has only limited support for them. At least some of the time this seems to be to encourage vendor lock in... The opposite of the product we should "all" use if we're "all" going to agree on something.
gp's post about them swiping it from Gmail might be correct, I have no idea, but I wouldn't be surprised.
But your description of Outlook isn't at all the relatively cool part what Leopard does. Leopard finds dates/times in your emails so it'll use those dates/times in the actual event. The whole point is that you _don't_ set the date/time for the event - it can parse them out of a bunch of text for you.
If Exchange would run on Linux, maybe I'd use it/recommend it. (Ditto for SQL Server.) The lack of OS-compatibility is the killer feature for me; it makes it absolutely a non-starter. And it IS a good assumption that you'll have OS incompatibility from MS products, certainly all server products.
They don't even bother having compatible crossplatform clients for their server software; Entourage has routinely had problems connecting to Exchange in several different orgs I've been involved in.
I think, btw, that while everyone COULD use it, calendaring is a very business app. Quite a few businesses have some nonWindows systems. So I think there's a substantial, realized market for crossplatform software in this area, and I think that selection of products reduces the tendency to make OSS solutions.
I believe you'll find some responses in this ASK that have OSS standalone calendaring solutions. That's fundamentally different than having unified calendaring, email, contact lists, etc, like Exchange does. To my knowledge, there isn't a smooth mature OSS solution to this.
This bundling is even more corporate - but there ARE definitely two big competitors - IBM Lotus and Novell Groupwise. Furthermore, those 3 packages (including Exchange) are all the options you have if you need the Blackberry server support, also.
-- And if anybody has any good reasons why one of those two is much better than the other in a mixed OS X / Win environment, I'm all ears --
Finally, I'd like to add that OS X Leopard has a feature where emails that contain text that seems like it might be something you might want to add to your calendar get parsed and get a little right-click menu to get added to iCal. Which is neat!
I'd add, it depends on product, the complexity of the codebase, the extensibility, modularity, readability, and extensibility of the codebase (eg, if it's highly modular it's easier to test a fix that's limited to the module/plugin)
I'd suggest that weeks sounds too long for an in the wild update without a security patch - or published workaround limiting your exposure. (eg, "use this method to restrict the IPs that can access it to trusted ones.") But that isn't me saying you're developing too slow, it's me saying that if it's going to take you that long you need to either find alternate solutions or create a architecture that allows you to quickly make access-limiting patches and layered security.
Actually, I'd make that more broad - if they want faster response to patches, what they need to do is to invest a lot on a highly modular, pluggable architecture so you can MAKE rapid changes. It's really a question of how much investment they want to make.
We routinely do same day fixes to certain kinds of things... but certainly the complex things take longer. And I think we're pretty unusual in that regard.
While I agree that this study accounted for smoking, I consistently find they don't account for nearly enough things. If you have the original scientific article, can you tell me whether they accounted for people who have a history of actively dieting?
In the US, at least, we allow diet products made with an incredible array of extremely unhealthy crap in the name of having fewer calories and lower fat... including allowing artificial sweeteners that are illegal in places like Canada. I would EASILY believe, in a heartbeat, that people who eat nutitiously but end up overweight are much, much healthier than people who fill themselves with "light" food in the name of weight avoidance.
You may be "informative" but you're also wrong, unless you're using some fancy definition of "more" like including all the people that never see a car.
Cars are EXTREMELY dangerous, and that we let all of us idiots drive such powerful death machines with such little regulation is frightening.
If you want some pseudomath - the insurance company premiums are directly related to their costs, at least if you assume a semicompetitive market. Housing insurance is annually lower than car insurance - even with extremely inexpensive car insurance - everywhere I've seen. And that's for cars costing substantially LESS than the house...
You don't need cellular broadband if you have something like an RSS reader that downloads the stories. Or wget, if you want to roll your own archive of a website. Anybody on/. ought to be able to cache up 20 minutes of stuff to read.
(As a public transit user myself, I realize that during some times of day getting a laptop out isn't feasible. But when it is...)
I have heard parent's point repeatedly - that we're making tests easier.
I can attest that in recent years it has become administratively inappropriate to give negative comments to or flunk students, so we continually pass students who haven't really learned along to be with their peers. That they didn't really learn isn't THEIR fault, but until someone can figure out a way to teach them, moving them up to the next set of material isn't helping them at all.
However, when I think about the impact of the trends I see, it isn't "there's no one left to do research" it's how big and poorly trained everybody else is.
I'm consistently amazed by how they let anyone who ISN'T in a hard science/math program get away without really ever understanding anything about science or math. A huge number of people don't have enough backing in the scientific method to have a basic sense of what is or isn't a fact - even in simple real world cases they can physically deal with. (Like how to fix household items, how to tell if a circuit is blown, how to debug RCA connections to their TV, etc.) And don't have enough backing in math to convert measurement units or tell if they got the right change.
The entire idea that anything could possibly have or not have empirical verification is lost on a very, very large number of people...
And to be clear, while I think higher education ought to take some responsibility for ensuring that the graduates have at least a small degree of well roundedness, I think the main problem in US education is much, much earlier.
As a solution to speed alone, the right answer (as some other posts mentioned) is a CMS/publishing solution that makes static HTML pages once on a change. The most braindead way to do this is to put an aggressive squid/apache cache in front of your server, and only refresh the cache every half-hour or on demand; nobody gets to go directly to the dynamic site and you have a minimal investment in the conversion. But certainly just using an automated system to write-out HTML files works too.
Using AJAX you have to also remember that you're giving away all your code - and that any user with GreaseMonkey can REWRITE your code to do whatever they want. So your scenario only works out if 100% of your application data for all time is supposed to be viewable (at least) by all users. (Which is not to mention a significant number of other AJAX security potholes.)
Use AJAX to save page refreshes (eg Google Maps) - and only that. For any real world app, your server needs to control your data.
And if you need help implementing this, drop me a reply;)
I'm going to try my best to explain; please forgive whichever parts are redundant for you.
--- SFTP As I'm pretty sure you know, there already is a protocol - SFTP - that connects via the SSH daemon on most any Linux box, and provides secure, FTP-like file transfers supported by most (but not all) FTP clients. Plus it doesn't have all the multi-port trouble with firewalls that FTP sometimes does.
Overall, I think SFTP DOES what you're mainly looking for, and I'll explain a bit more below.
--- Userbases It's not impossible, but is annoying, to have one Linux OS image super-securely managing two different SETS of users who have totally different profiles of what they're allowed to do and what files are relevant to them. For example, if you have a mailserver and a webserver with totally different userbases, you really want two Virtual Private Servers and therefore two different root accounts so even a root escalation on one server won't compromise the stuff on the other. Of course, this is not necessarily relevant if you're mostly giving webspace and mail to the same set of users.
--- fake security is really bad What you really, REALLY don't want is what chroot generally provides - a facility where the admin FEELS like it's safe but really it's not.
--- Real User Accounts
ssh as a nonroot user into a server, then type: ps -elf | grep ssh
You'll note that you connected to an ssh daemon which then, immediately, downgraded part of itself to run as your non-root user. This is really important - after the initial, hopefully minimal connection, everything you do is as your user. So it's totally constrained by all the things in the OS that constrain that user.
This is superior because: You can only do the same stuff your user SHOULD be able to do. No bug in the main part of ssh can let you perform an action with higher/wrong permissions than that - because it can't give you MORE permission than it has itself. No bug in the child part of ssh can let you escalate privileges up to root, because IT can't do that. No administrator has to know a "special way" to disable a user - if the user's account is disabled OR they don't have access to a file, they can't get to it.
I think there are other reasons along these lines, but I'll conclude this section with saying "real user accounts are usually A Good Thing (tm)"
--- Setting up chroot isn't much easier than setting up a VPS If you take to heart the user account thing, then you don't want a "fake" jail that only works for the FTP-like access; you want a jail that jails the whole FTP-like PROCESS, too, in case there turns out to be an exploit in it.
However, you then need to personally make sure the jailed FTP-like process also has access to anything it might need. Like "ls", and who knows what else.
The general case of this is to setup an entire virtual linux installation for them inside chroot and then rip out what functionality you don't want them to have, which is a lot of work.
Because of how chroot is designed, this also just isn't secure, but it's not a trivial piece of software to totally jail a process, and it's not cheap to do so. You have to make lots of things secure in an way that's entirely unlike other stuff in Linux.
At the core, this process still has permission to do whatever your user has permission to do in Linux. AND, if your user has too much control they're going to be able to do Bad Things even in a chroot jail.
But you could go a step further and setup a virtual private server - like Xen, User Mode Linux, OpenVZ or VMWare. This guarantees (to the limit of the security of the virtualization software!) that not only are the files protected but the process is totally contained in it's own space and can't "escape" to the root OS. Essentially this IS the software you're looking for; it totally jails processes.
Certainly, while there's really no cheap way to totally isolate a process, there could be a way in Linux more
I realize this is funny, but becoming an ISP works for some people.
At it's core, a DSL provider is running a big line to an exchange and then splitting it into little pieces. Some of these exchanges are significant buildings, but some are relatively small.
I discussed earlier what you might do if you have neighbors who can get internet. If you don't have neighbors at all, everything is going to be pricey. But if you have neighbors who don't have but WANT internet, you could all start a coop to get internet. This would still be expensive, but less ridiculously expensive. If you have a whole town without internet, you might even get the town officially involved and convince them that everyone would benefit from being wired up.
So you basically just find someone who'll bring reasonably big lines somewhere near you - which is not necessarily limited to our telco monopoly - and figure out how you'd split those lines with the people who are interested.
The general kinds of things I would do are below. I'm dealing with this in a "money is no object" kind of way, because ALL of these options are expensive and I don't really know how expensive.
1. Call the business part of the phone company and see what they will sell you. Maybe they can sell you a T1 line and they're holding out on you because it's not a consumer offering.
2. If some kind of DSL or cable is nearby, call and beg those companies, offering to front some money if they'll bring it to you.
3. See how close you can get a friendly neighbor to get more traditional broadband, and run your own "last mile" Options for the last mile include: ethernet, pringles can WiFi and buying your own DSLAM on ebay to run DSL. Note that you can get unlooped "security" lines from the phone company to run a private circuit to your neighbor's house to run your own DSL, if there's intervening territory so you can't run your own lines.
4. You said "hill" and not "mountain" - so consider what it would take to get satellite. Would a tall HAM-type tower do it? (The answer is yes, but the question is really is the height required practical for you) Could you rent 10 sq feet from someone for a smaller tower at the top of the hill or on the other side?
Now we're entering the "Make the most of your bandwidth" options.
5. Compression: If you're not using an ISP that does automatic tgz compression of all downloaded things before they hit your browser and isn't downscaling at least the largest images, make that happen. A roll-your-own way is to simply setup a little hosted server somewhere with real bandwidth and install a proxy, (Squid?) then force all your outbound web traffic through the proxy. In your position, I doubt this'll make your latency worse in any measurable way.
6. Adblocking: Turn on really aggressive ad blacklisting, so those things never ever come close to loading.
7. Skip some content: I think there are also FF extensions that'll let you skip large content and only load it on purpose, which could be helpful.
8. Caching: - cache the heck out of your connection. The easy way is just to massively inflate your browser's cache and never ever empty it. A harder way that will sometimes give better performance is to setup a proxy (squid) on your fast local network, tell it to cache the heck out of everything and then give it a lot of RAM. An advantage is that this gives you that whole system's physical RAM as cache - so the cached parts aren't just fast, they're REALLY fast. Plus you have much more control over how intense the caching is.
9. Preloading: If you have a relatively unmetered line but just very low bandwidth, you can also make sure you make optimum use of your connection during nonpeak times. For instance, use a wget script to preload into the cache things you read often. Make sure your mail is setup to download before you're likely to check it. (One way to accomplish this is to setup your mail to check all the time, but your dialup to auto-dial at appropriate moments... say an hour before you wake up and an hour before you get home from work.
No, I haven't used.NET much. What part of.NET is a secure client sandbox?
My impression was that.NET web applications could certainly generate HTML etc - but that if you were locally running things using a.NET runtime those were local applications with full permissions to take over your computer - unlike Flash or Java on a website.
Now, I've HEARD that ActiveX is securely sandboxed now, IF you have IE7 on Vista. But one version - and not even getting it into IE7 on XP - is not what I consider a great track record.
And this is strongly marred for me by Vista's track record of disregard for any sense of unprivileged users... in Vista anything it thinks is an 'installer' requires admin privs... even if it touches no system files. This does not protect against arbitrary executables and is therefore not virus protection... it only serves to make it difficult to have nonpriviledged users be able to usefully use the computer... something Apple has had right since OS X came out and *nix has had right forever.
Vista's security is totally based on a fictional "is this a good guy or a bad guy" model with no sense of grey, whereas in the real world everything is grey and you should minimize how much you trust everybody.
I think you're making my point to some extent... but you're not refuting and merely ignoring the most important part.
- We can't have a system where our nontechnical political leaders can pick out a secure system.
- And we can't have a crypto based counting system - even a totally open one - that can be verified by more than a handful of people.
-- And, most importantly, the point you seem to be ignoring - NO CRYPTO can prevent fraud at the user edge of the system. You may not have to trust the people who aggregate the votes, but you are inherently putting a lot of trust in whoever creates the machines not to add in "for every 20th vote for candidate A, make it B instead." It is physically impossible for us to have an army of third party geek technicians with appropriate training to do a hardware level audit of these machines - there aren't enough people with those skills.
It IS possible for us to have two partisan armies of recounters each recount every paper vote and compare their totals. It happens all the time, usnig well established procedures.
You're trusting - wildly, blindly trusting - the people who make the solution.
It's insecure to the people who implement that solution. You're giving a few programmers and technician's godlike powers over our politics. You can verified it's not tampered with "in transmission"... but not that the process is sound. As some examples:
If 0 and 1 are both valid votes for a person to make, no system except the voter themselves outside of the voting machine can hypothetically verify whether that vote was a 0 or 1. So you can only verify that the system accurately reported the votes by a source audit of all software, firmware, and hardware in the voting system. Let me highlight that point: In a modern system, almost any piece of the hardware is complex enough to conceal malicious changes.
But a source audit isn't enough; you have to have a provable chain of trust over the source to the compiler, and the compiler that compiled the compiler... you have to rewrite a programming language from scratch. AND at every step you have to prove no one cheated. Now, could YOU make such a system, given enough time, that YOU could trust? maybe. Could YOU make such a system that _I_ should trust? no. Because I don't know you.
This is the problem true - EXTERNAL* - voter paper trails solve. If the voter actually takes a slip with the printed vote, reads it, and actually places it in an actual box, then no amount of voter-machine fraud can defraud the recount. And so if you have that kind of fraud and detect it** you have a big mess, but not a wholesale failure of democracy electing a random person.
I pretty strongly doubt you could make a cryptographic system so strong that no one with total control over the results could forge the votes AND the checksums so they match. Maybe they'd need a private key that's on each machine... but whoops, we're talking about someone who PUTS those private keys on the machine. However, I'll readily admit I haven't done a lot of analysis in this area... because it doesn't matter at all to my point. If you can't trust the machines not to universally and subtly forge the results BEFORE any crypto process goes on, no amount of crypto can ever save you.
Even so, your BEST-case-scenario for auditability is that someone is going to publish every voter result in the country along with all the checksum and it's going to be publicly verified by... who? A few hundred academic programmers who understand enough crypto, tops? Otherwise you're talking about it being cryptographically verified by a very few people with a very few computers who are doing the counting.
In summary, I totally agree that a hypothetically secure system could be fairly secure against a random attacker, and that what we actually have looks like it was written with monkeys and typewriters by comparison, giving us banana democracy at best. The current system isn't just hackable, it's SO hackable it's almost definitely been done - and we KNOW that they waved their magic wand and threw out results after obvious problems in a bunch of different areas; Diebold techs basically said some vote counts that even their machines didn't say, and that's who got elected.
We can do a lot better than that in an electronic voting machine.
But at best, that's a false sense of security; it can never have broad end to end trust.
*An internal paper trail is NOT sufficient, because you can't externally verify it didn't print extra votes OR externally verify that it didn't scratch off valid votes.
**You are very likely to detect it, because a very close election usually triggers an automatic election - and an election with a lot of deviation will be detected by substantial exit poll variances. Our system is already setup so that basically if the loser thinks there was fraud they can demand this...
Paper voting systems are extremely vulnerable to localized, small scale fraud by a relatively large number of conspirators.
Any hypothetical electronic system, no matter how secure, is vulnerable to basically _universal_, unauditable fraud by a tiny number of conspirators in the right place - as low as 1. Any kind of cryptographic system can be defeated by the guy who actually controls where the actually-compiled source code - and the COMPILER source code - came from. Even in an OSS system, it's awfully hard to prove that's really the source that's being compiled and that it's being done by a fair compiler.
That's a big difference, and it's an innate, immutable difference. Paper is highly decentralized because much of the population can read. ANY computer system is highly centralized - even if you have perhaps 10 sets of voting machines, that's at best 10 major code trees...
Your worst-case scenario with a paper vote can be a conspiracy on the counting side - which is already done by members of both parties together. So the only way to have this work out is if you also stuff the observers of the OTHER party with conspirators.
The other way requires a pervasive box-stuffing campaign across a wide array of precincts right in the face of bipartisan election judges.
In both cases, you can basically only pull this off in an area where the government is pretty much universally and tightly controlled by one group. A good example is the original Daley's regime in Chicago (Daley per se may not have... ) Note, however, that if THOSE people were elected to the part where they tightly control the government, chances are the voting populace would vote for a similar candidate in that area.
And the risk of those conspirators going to jail is still relatively high.
As theRaven64 said - the important thing about a paper vote is that it's transparent to everyone.
I'll go a step further and say that we as a country are not capable at this time of commissioning a fair electronic voting standard - currently we can't even manage a "not-obviously-retarded" electronic voting standard. Asking election officials to manage cryptographic standards is in practice outsourcing our democracy to a handful of large self serving partisan corporations, because that's how technology tasks are done. The government does not have a good track record of accomplishing either security or transparency in tech projects.
Finally, note that THE reason electronic voting is _theoretically_ used is to provide faster counts. If you treat it like it should be - as a precount - it could easily be used to give a really fast estimate of the votes.
It is much more likely to die during character creation in HOL. Human Occupied Landfill is a hilarious game. We even actually played real sessions of it.
You start with what is officially labeled the 'chart chart'. And, before I forget, you have to have the supplement - Buttery Holesomeness - before you actually even have character creation rules.
> the Silverlight player includes the cut-down.NET runtime
Apologies; I'm so used to thinking of.NET as an application server platform I plain forgot it ran locally too.
>it's not Microsoft implementing this for Linux, it's Mono
For Linux, yes. For OS X and Win, no. At this particular moment, I'd take FF+FlashPlayer over FF+Silverlight for security. Maybe Silverlight will prove me wrong...
>IE7 on Vista fixed pretty much everything wrong with ActiveX's security model
Truly, you might be right. Except that Vista is a step backwards in a couple other ways important enough that IE7 being more secure only there doesn't comfort me.
The most obvious example of actual retrogression is that in Vista anything that seems to be an installer CAN'T behave nicely and not require admin privs. But just malicious exe code can. *sigh* So you INCREASE the number of users who have to run as Administrator frequently when you should be decreasing it.
Slashdot Mirror
wooden cutting boards are awesome - but the explanation I always heard was the tannins etc in the wood being actively antibacterial.
"Antibacterial" household products contain something different than soap. What thing that is, varies.
/. after all.
I'm not a chemist or a doctor. And I assume that if this is mistaken in any way, someone will correct me, since this is
For household use you don't need antibacterial agents to effectively wash your hands - because the act of actual abrasion with the surface-tension eliminating properties of soap removes most things from your skin. For the most part, your hands don't harbor a lot of problems IN the surface, because your body is busy killing that.
In my opinion, there are also two major classes of these antibacterial agents - which I'll classify as "simple" and "complex" To my knowledge, it's extremely difficult and rare for bacteria to become resist to "simple" antibacterial agents.
Simple antibacterial agents are things that kill everything. Like bleach (e.g. Chlorox), or high concentrations of alcohol (e.g. Glass Plus). To a lesser extent vinegar, ammonia, salt... These things are not necessarily good for people, but people are really big and can avoid drinking them in really high doses... but they're still really bad for bacteria etc to swim completely in and they get annihilated, because these things basically just melt cell walls.
For the most part these are quite safe to clean with... they don't especially build up in your system, so as long as you never get a super high dose, usually by breathing or drinking it, you're safe. But I don't recommend you swim in bleach, get it in your eyes, and drink it either. Those example cleaners are relatively harmless in most controlled cleaning situations - but there are plenty of options in this category that aren't - like strong acids - we just don't usually put them in consumer cleaners in high doses.
So I have no objection to, say, a little bleach being added to surface cleaners.
The antibiotics you take orally are wildly different, and must be complex. They can't be TOO bad for you, or they'd be rat poison and not a drug. So they try to attack something bacteria-cell specific that human cells are immune to. But bacteria operate in a range of ways, so often this only works on some bacteria. And they mutate... so the more specific and narrow the antibiotic is, the easier it is for the bacteria to become immune. The broader it is, the more likely it hurts you.
Some companies - because it's what the uneducated consuming public wants - are putting vaguely these kind of agents in household cleaning products. Not EXACTLY the same drugs we're taking orally. But chemicals that have narrow, complex effects on bacteria, which probably encourage mutation. Those mutations may or may not impact the effectiveness of current or future drugs.
HOWEVER, as much as I think antibacterial hand soap is pretty high on the list of evils, it's not NEARLY as bad as the number of people who merely don't finish the antibiotics they were prescribed. Those people are ruining the world.
As a rule, this idea is usually backwards. In order to gather significant power from this, you're basically increasing the amount of energy the vehicles expend - because for this to work, you have to keep the pavement bouncy enough to generate the power. (Put another way, the vehicle is most efficient if the pavement is very flat and very rigid)
So you're usually sucking energy FROM poorly maintained oil driven vehicles and putting it TO a grid that at least hypothetically could be powered by nuclear or wind at much lower cost and environmental impact.
The major kinds of places this sort of technique is useful: a) because the main problem is that you NEED to be far away and disconnected from the grid... b) where the bounce energy you're trying to capture is orders of magnitude smaller than the actual bouncing action c) where the initial energy is biomechanical, which is both pretty efficient and otherwise hard to optimize further.
Using this to power small road sensors that didn't need to be wired up would be fine. Using it to power an efficient laptop would be fine - if you're actively looking for a way to easily get more exercise. Using it to power a watch is pretty much ideal, which is why this has been around a long time.
Parent is a lying myMiniCity Troll - link is wrong.
That link is dwarfurl to myMiniCity - wikipedia is a lie.
mod them to negative a zillion, please.
I've heard that about Exchange's monolithic mail stores, which are obviously a huge problem for any kind of size or traffic. But obviously, it doesn't have to be that way... use maildir. I used to agree with your "get it all off the mailserver" philosophy, but now I think it should be "use a better mailserver"
In more details:
I think email is a clearly inferior file _transfer_ mechanism to, say, Subversion, which is what we use to share files we're collaborating on. But if you _don't_ have something like SVN/CVS to use for this, email is perhaps the most accessible system that has offline viewing for all participants, redundant local backups on everyone's machine, and most importantly versioning.
But there's no better way to archive and index email than to keep it as email. If that's how someone DID send you the file, you should be able to look it up there and retrieve it... even if you're going to move old mail to some kind of read-only storage. Moving it all locally onto a not-necessarily-backed-up workstation... and making it difficult to sync to a new workstation - just is not as good as a serverbased solution.
In the early days of 3.5" floppies being common, my floppy broke one more step...
I had spent a couple weeks on a programming project - basically a lame, wildly feature-incomplete clone of lynx in assembly. I had a backup of the couple weeks of programming... but not the last 36 solid hours or so of last minute push. And then the disk stopped working.
So suspecting a filesystem corruption, I brought it to a couple ubergeeks, one of them ran a raw sector read on it... there was just nothing there, no filesystem, no sectors. I was actually in the Mechanical Engineering department, so around then it occurred to us to LOOK at the disk - when you spun the little metal part, the little media part DIDN'T spin; they had become detached.
So... I took a toothpick. And some superglue. And I glued the media back to the metal. A few seconds and another raw sector read later, I had 100% of my code... in the wrong order. Actually I had about 160% of my code... there were a ton of repeated sections.
But I could figure that out well enough; day was saved for me.
Educate me - because right now, this sounds like FUD to me.
>> Within the corporate world, Exchange really does rule.
By monopoly, yes. This I don't contest at all. Nor your point about uniformity, but I don't think that always means you should jump to the most popular system.
>> There's nothing like it that can scale to 10,000+ users, be centrally administered
I'll admit I haven't PERSONALLY tried, but I know of 10,000+ sites that have moved to Groupwise or Lotus. I doubt either of those solutions doesn't scale, considering the vendors. Novell has been in this business LONGER than Microsoft has, but they don't have Windows to leverage.
>> and has such a wide variety of client access---outlook for the web (or whatever it's
>> called) is really slick. I haven't seen anything even close to it.
Maybe Outlook Web Access is much cooler than the competition; I haven't compared that feature.
But, are you actually saying you should use Outlook because it's more PLATFORM COMPATIBLE? Certain of the most fun features of OWA don't work quite right if you're not using IE on Windows, but I can't fault them for taking extra advantage of what they know. But you're talking about the only major system without a reliably functioning OS X client (Entourage is reliably problematic when you actually try to use it with Exchange), the only one without any support at all for a Linux client, and the only one where the server will only run on Windows. You realize Novell and IBM actually MAKE Linux and OS X clients for their solutions, right? It's not only that some enterprising Linux dev reverse engineered the API, like for Evolution.
If you're going to say we should all adopt a single collaboration environment (why can't we just get along) then why would you choose one that's just not possible, on the server, to use for a place that's a mac shop or a Linux shop - perhaps a place that's afraid of the BSA after all the nasty things they've done.
And if you're going to say we should all adopt a single standalone _calendar_ format, and not a collaboration suite, then I think when Mozilla and Google and Apple are all using the RFC 2445 iCal format, the battle for the _compatible_ calendar format is settled. Guess what? Of the above major collaboration suites, Outlook seems the only one with iCal support that is limited, at least per Wikipedia. (No TODOs, Journals, etc.) Historically, Microsoft is consistently slow to adopt standards, and routinely has only limited support for them. At least some of the time this seems to be to encourage vendor lock in... The opposite of the product we should "all" use if we're "all" going to agree on something.
gp's post about them swiping it from Gmail might be correct, I have no idea, but I wouldn't be surprised.
But your description of Outlook isn't at all the relatively cool part what Leopard does. Leopard finds dates/times in your emails so it'll use those dates/times in the actual event. The whole point is that you _don't_ set the date/time for the event - it can parse them out of a bunch of text for you.
If Exchange would run on Linux, maybe I'd use it/recommend it. (Ditto for SQL Server.) The lack of OS-compatibility is the killer feature for me; it makes it absolutely a non-starter. And it IS a good assumption that you'll have OS incompatibility from MS products, certainly all server products.
They don't even bother having compatible crossplatform clients for their server software; Entourage has routinely had problems connecting to Exchange in several different orgs I've been involved in.
I think, btw, that while everyone COULD use it, calendaring is a very business app. Quite a few businesses have some nonWindows systems. So I think there's a substantial, realized market for crossplatform software in this area, and I think that selection of products reduces the tendency to make OSS solutions.
I believe you'll find some responses in this ASK that have OSS standalone calendaring solutions. That's fundamentally different than having unified calendaring, email, contact lists, etc, like Exchange does. To my knowledge, there isn't a smooth mature OSS solution to this.
This bundling is even more corporate - but there ARE definitely two big competitors - IBM Lotus and Novell Groupwise. Furthermore, those 3 packages (including Exchange) are all the options you have if you need the Blackberry server support, also.
-- And if anybody has any good reasons why one of those two is much better than the other in a mixed OS X / Win environment, I'm all ears --
Finally, I'd like to add that OS X Leopard has a feature where emails that contain text that seems like it might be something you might want to add to your calendar get parsed and get a little right-click menu to get added to iCal. Which is neat!
I love the parent's subject-line analogy.
I'd add, it depends on product, the complexity of the codebase, the extensibility, modularity, readability, and extensibility of the codebase (eg, if it's highly modular it's easier to test a fix that's limited to the module/plugin)
I'd suggest that weeks sounds too long for an in the wild update without a security patch - or published workaround limiting your exposure. (eg, "use this method to restrict the IPs that can access it to trusted ones.") But that isn't me saying you're developing too slow, it's me saying that if it's going to take you that long you need to either find alternate solutions or create a architecture that allows you to quickly make access-limiting patches and layered security.
Actually, I'd make that more broad - if they want faster response to patches, what they need to do is to invest a lot on a highly modular, pluggable architecture so you can MAKE rapid changes. It's really a question of how much investment they want to make.
We routinely do same day fixes to certain kinds of things... but certainly the complex things take longer. And I think we're pretty unusual in that regard.
While I agree that this study accounted for smoking, I consistently find they don't account for nearly enough things. If you have the original scientific article, can you tell me whether they accounted for people who have a history of actively dieting?
In the US, at least, we allow diet products made with an incredible array of extremely unhealthy crap in the name of having fewer calories and lower fat... including allowing artificial sweeteners that are illegal in places like Canada. I would EASILY believe, in a heartbeat, that people who eat nutitiously but end up overweight are much, much healthier than people who fill themselves with "light" food in the name of weight avoidance.
You may be "informative" but you're also wrong, unless you're using some fancy definition of "more" like including all the people that never see a car.
Cars are EXTREMELY dangerous, and that we let all of us idiots drive such powerful death machines with such little regulation is frightening.
If you want some pseudomath - the insurance company premiums are directly related to their costs, at least if you assume a semicompetitive market. Housing insurance is annually lower than car insurance - even with extremely inexpensive car insurance - everywhere I've seen. And that's for cars costing substantially LESS than the house...
Why Does Puzzle Pirates require unlimited access to my computer?
You don't need cellular broadband if you have something like an RSS reader that downloads the stories. Or wget, if you want to roll your own archive of a website. Anybody on /. ought to be able to cache up 20 minutes of stuff to read.
(As a public transit user myself, I realize that during some times of day getting a laptop out isn't feasible. But when it is...)
I haven't read TFA yet - this is /. after all.
I have heard parent's point repeatedly - that we're making tests easier.
I can attest that in recent years it has become administratively inappropriate to give negative comments to or flunk students, so we continually pass students who haven't really learned along to be with their peers. That they didn't really learn isn't THEIR fault, but until someone can figure out a way to teach them, moving them up to the next set of material isn't helping them at all.
However, when I think about the impact of the trends I see, it isn't "there's no one left to do research" it's how big and poorly trained everybody else is.
I'm consistently amazed by how they let anyone who ISN'T in a hard science/math program get away without really ever understanding anything about science or math. A huge number of people don't have enough backing in the scientific method to have a basic sense of what is or isn't a fact - even in simple real world cases they can physically deal with. (Like how to fix household items, how to tell if a circuit is blown, how to debug RCA connections to their TV, etc.) And don't have enough backing in math to convert measurement units or tell if they got the right change.
The entire idea that anything could possibly have or not have empirical verification is lost on a very, very large number of people...
And to be clear, while I think higher education ought to take some responsibility for ensuring that the graduates have at least a small degree of well roundedness, I think the main problem in US education is much, much earlier.
As a solution to speed alone, the right answer (as some other posts mentioned) is a CMS/publishing solution that makes static HTML pages once on a change. The most braindead way to do this is to put an aggressive squid/apache cache in front of your server, and only refresh the cache every half-hour or on demand; nobody gets to go directly to the dynamic site and you have a minimal investment in the conversion. But certainly just using an automated system to write-out HTML files works too.
;)
Using AJAX you have to also remember that you're giving away all your code - and that any user with GreaseMonkey can REWRITE your code to do whatever they want. So your scenario only works out if 100% of your application data for all time is supposed to be viewable (at least) by all users. (Which is not to mention a significant number of other AJAX security potholes.)
Use AJAX to save page refreshes (eg Google Maps) - and only that. For any real world app, your server needs to control your data.
And if you need help implementing this, drop me a reply
I'm going to try my best to explain; please forgive whichever parts are redundant for you.
--- SFTP
As I'm pretty sure you know, there already is a protocol - SFTP - that connects via the SSH daemon on most any Linux box, and provides secure, FTP-like file transfers supported by most (but not all) FTP clients. Plus it doesn't have all the multi-port trouble with firewalls that FTP sometimes does.
Overall, I think SFTP DOES what you're mainly looking for, and I'll explain a bit more below.
--- Userbases
It's not impossible, but is annoying, to have one Linux OS image super-securely managing two different SETS of users who have totally different profiles of what they're allowed to do and what files are relevant to them. For example, if you have a mailserver and a webserver with totally different userbases, you really want two Virtual Private Servers and therefore two different root accounts so even a root escalation on one server won't compromise the stuff on the other. Of course, this is not necessarily relevant if you're mostly giving webspace and mail to the same set of users.
--- fake security is really bad
What you really, REALLY don't want is what chroot generally provides - a facility where the admin FEELS like it's safe but really it's not.
--- Real User Accounts
ssh as a nonroot user into a server, then type:
ps -elf | grep ssh
You'll note that you connected to an ssh daemon which then, immediately, downgraded part of itself to run as your non-root user. This is really important - after the initial, hopefully minimal connection, everything you do is as your user. So it's totally constrained by all the things in the OS that constrain that user.
This is superior because:
You can only do the same stuff your user SHOULD be able to do.
No bug in the main part of ssh can let you perform an action with higher/wrong permissions than that - because it can't give you MORE permission than it has itself.
No bug in the child part of ssh can let you escalate privileges up to root, because IT can't do that.
No administrator has to know a "special way" to disable a user - if the user's account is disabled OR they don't have access to a file, they can't get to it.
I think there are other reasons along these lines, but I'll conclude this section with saying "real user accounts are usually A Good Thing (tm)"
--- Setting up chroot isn't much easier than setting up a VPS
If you take to heart the user account thing, then you don't want a "fake" jail that only works for the FTP-like access; you want a jail that jails the whole FTP-like PROCESS, too, in case there turns out to be an exploit in it.
However, you then need to personally make sure the jailed FTP-like process also has access to anything it might need. Like "ls", and who knows what else.
The general case of this is to setup an entire virtual linux installation for them inside chroot and then rip out what functionality you don't want them to have, which is a lot of work.
Because of how chroot is designed, this also just isn't secure, but it's not a trivial piece of software to totally jail a process, and it's not cheap to do so. You have to make lots of things secure in an way that's entirely unlike other stuff in Linux.
At the core, this process still has permission to do whatever your user has permission to do in Linux. AND, if your user has too much control they're going to be able to do Bad Things even in a chroot jail.
But you could go a step further and setup a virtual private server - like Xen, User Mode Linux, OpenVZ or VMWare. This guarantees (to the limit of the security of the virtualization software!) that not only are the files protected but the process is totally contained in it's own space and can't "escape" to the root OS. Essentially this IS the software you're looking for; it totally jails processes.
Certainly, while there's really no cheap way to totally isolate a process, there could be a way in Linux more
I realize this is funny, but becoming an ISP works for some people.
At it's core, a DSL provider is running a big line to an exchange and then splitting it into little pieces. Some of these exchanges are significant buildings, but some are relatively small.
I discussed earlier what you might do if you have neighbors who can get internet. If you don't have neighbors at all, everything is going to be pricey. But if you have neighbors who don't have but WANT internet, you could all start a coop to get internet. This would still be expensive, but less ridiculously expensive. If you have a whole town without internet, you might even get the town officially involved and convince them that everyone would benefit from being wired up.
So you basically just find someone who'll bring reasonably big lines somewhere near you - which is not necessarily limited to our telco monopoly - and figure out how you'd split those lines with the people who are interested.
The general kinds of things I would do are below. I'm dealing with this in a "money is no object" kind of way, because ALL of these options are expensive and I don't really know how expensive.
1. Call the business part of the phone company and see what they will sell you. Maybe they can sell you a T1 line and they're holding out on you because it's not a consumer offering.
2. If some kind of DSL or cable is nearby, call and beg those companies, offering to front some money if they'll bring it to you.
3. See how close you can get a friendly neighbor to get more traditional broadband, and run your own "last mile" Options for the last mile include: ethernet, pringles can WiFi and buying your own DSLAM on ebay to run DSL. Note that you can get unlooped "security" lines from the phone company to run a private circuit to your neighbor's house to run your own DSL, if there's intervening territory so you can't run your own lines.
4. You said "hill" and not "mountain" - so consider what it would take to get satellite. Would a tall HAM-type tower do it? (The answer is yes, but the question is really is the height required practical for you) Could you rent 10 sq feet from someone for a smaller tower at the top of the hill or on the other side?
Now we're entering the "Make the most of your bandwidth" options.
5. Compression: If you're not using an ISP that does automatic tgz compression of all downloaded things before they hit your browser and isn't downscaling at least the largest images, make that happen. A roll-your-own way is to simply setup a little hosted server somewhere with real bandwidth and install a proxy, (Squid?) then force all your outbound web traffic through the proxy. In your position, I doubt this'll make your latency worse in any measurable way.
6. Adblocking: Turn on really aggressive ad blacklisting, so those things never ever come close to loading.
7. Skip some content: I think there are also FF extensions that'll let you skip large content and only load it on purpose, which could be helpful.
8. Caching: - cache the heck out of your connection. The easy way is just to massively inflate your browser's cache and never ever empty it. A harder way that will sometimes give better performance is to setup a proxy (squid) on your fast local network, tell it to cache the heck out of everything and then give it a lot of RAM. An advantage is that this gives you that whole system's physical RAM as cache - so the cached parts aren't just fast, they're REALLY fast. Plus you have much more control over how intense the caching is.
9. Preloading: If you have a relatively unmetered line but just very low bandwidth, you can also make sure you make optimum use of your connection during nonpeak times. For instance, use a wget script to preload into the cache things you read often. Make sure your mail is setup to download before you're likely to check it. (One way to accomplish this is to setup your mail to check all the time, but your dialup to auto-dial at appropriate moments... say an hour before you wake up and an hour before you get home from work.
No, I haven't used .NET much. What part of .NET is a secure client sandbox?
.NET web applications could certainly generate HTML etc - but that if you were locally running things using a .NET runtime those were local applications with full permissions to take over your computer - unlike Flash or Java on a website.
My impression was that
Now, I've HEARD that ActiveX is securely sandboxed now, IF you have IE7 on Vista. But one version - and not even getting it into IE7 on XP - is not what I consider a great track record.
And this is strongly marred for me by Vista's track record of disregard for any sense of unprivileged users... in Vista anything it thinks is an 'installer' requires admin privs... even if it touches no system files. This does not protect against arbitrary executables and is therefore not virus protection... it only serves to make it difficult to have nonpriviledged users be able to usefully use the computer... something Apple has had right since OS X came out and *nix has had right forever.
Vista's security is totally based on a fictional "is this a good guy or a bad guy" model with no sense of grey, whereas in the real world everything is grey and you should minimize how much you trust everybody.
I think you're making my point to some extent... but you're not refuting and merely ignoring the most important part.
- We can't have a system where our nontechnical political leaders can pick out a secure system.
- And we can't have a crypto based counting system - even a totally open one - that can be verified by more than a handful of people.
-- And, most importantly, the point you seem to be ignoring - NO CRYPTO can prevent fraud at the user edge of the system. You may not have to trust the people who aggregate the votes, but you are inherently putting a lot of trust in whoever creates the machines not to add in "for every 20th vote for candidate A, make it B instead." It is physically impossible for us to have an army of third party geek technicians with appropriate training to do a hardware level audit of these machines - there aren't enough people with those skills.
It IS possible for us to have two partisan armies of recounters each recount every paper vote and compare their totals. It happens all the time, usnig well established procedures.
You totally misunderstand where it's insecure.
You're trusting - wildly, blindly trusting - the people who make the solution.
It's insecure to the people who implement that solution. You're giving a few programmers and technician's godlike powers over our politics. You can verified it's not tampered with "in transmission"... but not that the process is sound. As some examples:
If 0 and 1 are both valid votes for a person to make, no system except the voter themselves outside of the voting machine can hypothetically verify whether that vote was a 0 or 1. So you can only verify that the system accurately reported the votes by a source audit of all software, firmware, and hardware in the voting system. Let me highlight that point: In a modern system, almost any piece of the hardware is complex enough to conceal malicious changes.
But a source audit isn't enough; you have to have a provable chain of trust over the source to the compiler, and the compiler that compiled the compiler... you have to rewrite a programming language from scratch. AND at every step you have to prove no one cheated. Now, could YOU make such a system, given enough time, that YOU could trust? maybe. Could YOU make such a system that _I_ should trust? no. Because I don't know you.
This is the problem true - EXTERNAL* - voter paper trails solve. If the voter actually takes a slip with the printed vote, reads it, and actually places it in an actual box, then no amount of voter-machine fraud can defraud the recount. And so if you have that kind of fraud and detect it** you have a big mess, but not a wholesale failure of democracy electing a random person.
I pretty strongly doubt you could make a cryptographic system so strong that no one with total control over the results could forge the votes AND the checksums so they match. Maybe they'd need a private key that's on each machine... but whoops, we're talking about someone who PUTS those private keys on the machine. However, I'll readily admit I haven't done a lot of analysis in this area... because it doesn't matter at all to my point. If you can't trust the machines not to universally and subtly forge the results BEFORE any crypto process goes on, no amount of crypto can ever save you.
Even so, your BEST-case-scenario for auditability is that someone is going to publish every voter result in the country along with all the checksum and it's going to be publicly verified by... who? A few hundred academic programmers who understand enough crypto, tops? Otherwise you're talking about it being cryptographically verified by a very few people with a very few computers who are doing the counting.
In summary, I totally agree that a hypothetically secure system could be fairly secure against a random attacker, and that what we actually have looks like it was written with monkeys and typewriters by comparison, giving us banana democracy at best. The current system isn't just hackable, it's SO hackable it's almost definitely been done - and we KNOW that they waved their magic wand and threw out results after obvious problems in a bunch of different areas; Diebold techs basically said some vote counts that even their machines didn't say, and that's who got elected.
We can do a lot better than that in an electronic voting machine.
But at best, that's a false sense of security; it can never have broad end to end trust.
*An internal paper trail is NOT sufficient, because you can't externally verify it didn't print extra votes OR externally verify that it didn't scratch off valid votes.
**You are very likely to detect it, because a very close election usually triggers an automatic election - and an election with a lot of deviation will be detected by substantial exit poll variances. Our system is already setup so that basically if the loser thinks there was fraud they can demand this...
Paper voting systems are extremely vulnerable to localized, small scale fraud by a relatively large number of conspirators.
Any hypothetical electronic system, no matter how secure, is vulnerable to basically _universal_, unauditable fraud by a tiny number of conspirators in the right place - as low as 1. Any kind of cryptographic system can be defeated by the guy who actually controls where the actually-compiled source code - and the COMPILER source code - came from. Even in an OSS system, it's awfully hard to prove that's really the source that's being compiled and that it's being done by a fair compiler.
That's a big difference, and it's an innate, immutable difference. Paper is highly decentralized because much of the population can read. ANY computer system is highly centralized - even if you have perhaps 10 sets of voting machines, that's at best 10 major code trees...
Your worst-case scenario with a paper vote can be a conspiracy on the counting side - which is already done by members of both parties together. So the only way to have this work out is if you also stuff the observers of the OTHER party with conspirators.
The other way requires a pervasive box-stuffing campaign across a wide array of precincts right in the face of bipartisan election judges.
In both cases, you can basically only pull this off in an area where the government is pretty much universally and tightly controlled by one group. A good example is the original Daley's regime in Chicago (Daley per se may not have... ) Note, however, that if THOSE people were elected to the part where they tightly control the government, chances are the voting populace would vote for a similar candidate in that area.
And the risk of those conspirators going to jail is still relatively high.
As theRaven64 said - the important thing about a paper vote is that it's transparent to everyone.
I'll go a step further and say that we as a country are not capable at this time of commissioning a fair electronic voting standard - currently we can't even manage a "not-obviously-retarded" electronic voting standard. Asking election officials to manage cryptographic standards is in practice outsourcing our democracy to a handful of large self serving partisan corporations, because that's how technology tasks are done. The government does not have a good track record of accomplishing either security or transparency in tech projects.
Finally, note that THE reason electronic voting is _theoretically_ used is to provide faster counts. If you treat it like it should be - as a precount - it could easily be used to give a really fast estimate of the votes.
It is much more likely to die during character creation in HOL. Human Occupied Landfill is a hilarious game. We even actually played real sessions of it.
You start with what is officially labeled the 'chart chart'. And, before I forget, you have to have the supplement - Buttery Holesomeness - before you actually even have character creation rules.
> the Silverlight player includes the cut-down .NET runtime
.NET as an application server platform I plain forgot it ran locally too.
o ld=0&commentsort=0&mode=thread&cid=18016052
Apologies; I'm so used to thinking of
>it's not Microsoft implementing this for Linux, it's Mono
For Linux, yes. For OS X and Win, no. At this particular moment, I'd take FF+FlashPlayer over FF+Silverlight for security. Maybe Silverlight will prove me wrong...
>IE7 on Vista fixed pretty much everything wrong with ActiveX's security model
Truly, you might be right. Except that Vista is a step backwards in a couple other ways important enough that IE7 being more secure only there doesn't comfort me.
The most obvious example of actual retrogression is that in Vista anything that seems to be an installer CAN'T behave nicely and not require admin privs. But just malicious exe code can. *sigh* So you INCREASE the number of users who have to run as Administrator frequently when you should be decreasing it.
http://slashdot.org/comments.pl?sid=222380&thresh