It depends on the method used for handling group membership, but I -think- it is possible to query the current multicast membership list. If evil.provider.net were to provide multicast but require that session reservation be done through them, they could have a script which periodically scanned the membership list. The total number of viewers would then be the total number of unique members of the group for the duration of the session, which could be directly billed for.
evil.provider.net could also opt to charge a flat fee on the assumption that a typical high-volume multicast might easily reach 10,000+ people.
A third option would be to have the multicast stream start at the ISP, with the broadcaster unicasting to a multicast reflector. The stream would then be encrypted, and decryption keys would be provided on request or at a nominal charge.
The photographs don't show an individual hair under a microscope (pity) but the density would be good for both sensing and feeding. My guess would be both. The BBC's photos show it floating, not on the sea bed, which tends more towards the filter feeding, but being able to tell sea currents would likely be valuable.
I can't remember if it's the anemone or the sea urchin (or both) that uses "arms" to guide food to a mouth. If there is a central mouth, rather than one on each hair (as you might expect on a filter feeder), then my guess would be that the hairs are manipulators for food particles.
...but (isn't there always?:) paper ballots are too easy to tamper with. Few American elections go by without fairly solid evidence of tampering with ballot boxes, ballot boxes going missing, ballots being "lost" behind objects, etc.
Paper ballots also pose the problem that you've got to trust the collectors and counters. In many cases, nobody else will ever get to see the ballots themselves, so nobody else will ever know if someone has edited the figures.
I'm not saying paper ballots are a disaster, only that the existing paper ballots are vulnerable to fraud. In some cases, the parties have even been known to "collect" the ballots by mail and dispose of those for the "wrong" side.
These, again, are solvable problems but if ANY system is to be trusted, these problems will have to be solved. I'm less concerned with the "how" than with the "when". WHEN will we have trustable elections?
Any bluetooth-enabled cellphone that isn't protected against people placing malicious calls is therefore not protected against malicious TiVoing.
"How could TiVo be used maliciously?" Bombard TiVo with enough PPV demands and it could start getting expensive. Fill the hard-drive with enough teleshopping or other pr0n, you've essentially managed a denial-of-download attack. America doesn't have anything similar to Open University, but that would be another potentially vulnerable area.
All you need is something that you can see and which will be concentrated in a tumor. You add a tracer to the food/water and watch where the tracer goes. Picking a suitable tracer would be tough, but that's an implementation detail.:)
Seriously, the use of tracers - dyes and radioactive isotopes - are fairly common for seeing where things go, so should be usable in cases where something concentrates. In either case, there will be a unique absorption frequency that would identify where concentrations were building up. That same frequency can then be used to literally cook that region and not affect anything else. It would be less damaging than radiotherapy, because it would be targetted.
Why isn't this done, if it's such a neat idea? Because finding something that will concentrate only in the target area is HARD. People have been working on targetted chemotherapy for decades and if there's been a breakthrough, it's not exactly been an Earth-shattering one. If the targetting mechanism could be figured out, then targetted radiotherapy would be better, as nothing away from the target compound or isotope would be affected at all, but it would be much more expensive. (Picture a bunch of microwave lasers, tuned exactly to the resonance frequency of a specific molecule, first scanning the body then blasting all concentrations, where ANY errors on position, frequency or intensity could be lethal.)
Those do cover most cases. However, it is a self-sustaining selection. If routers don't support the other protocols, nobody can see if they're going to be any better for their specific case. If nobody uses the other protocols, then a lack of support won't be obviously troublesome to the majority of users.
Now, OSPF, RIP and BGP are very good protocols - even for lots of the special cases - so it's also true that the gains to be had (even in theory) by using a more specific protocol will never be that great. There will be some, but it won't be gigantic.
Cases where these protocols fall down include using Linux on a laptop to route mobile network traffic, using a mesh or hypercube topology, multicasting and situations where network connections are fixed but unreliable. Multicasting is beginning to be fashionable, but none of the others are.
In consequence, it is indeed correct to say that nobody "needs" any more than those three protocols.
In a more abstract sense, I am firmly of the opinion that a wide range of choices (so long as a narrow selection is possible and has no overhead from the width of the original options) is always better than a narrow range (even if it's what you'll likely use anyway). Part of the problem with wide ranges is that they're typically done poorly, so you end up having to install stuff you'll never use. For example, Fedora Core has all kinds of really pointless enforced dependencies that could have been avoided very easily, so I don't consider that to offer genuine freedom of choice. If done right, it gets people to think about what they want to do and how best to do it, rather than to blindly point and click.
It's not as if you're reading, or that you're interested in discussion, or indeed are interested in discerning when you might be wrong (heaven forbid that you might be wrong - only other people are wrong). You've not actually reasoned on a single thing, you've only flamed. If you're that immature, go to alt.flame - well, no, on second thoughts don't. They have higher standards than you can hope for in your lifetime.
Sorry to break it to you, if you've a userland process, you've userland activity. It makes bugger all difference where you'd like things to take place, they take place where the code is. "But packets are routed by the kernel!" That's not what the argument is about, the argument is not about packet flows, it's about BGP, and BGP is processed by the BGP daemon and not the kernel.
(Even if we're talking about packet flows, you're still wrong, as Click routes packets in userspace, which is why it can route them to NS. Oh, you've never used Click or NS? Then don't complain when others know more than your Holiness.)
There's also a matter of source. I'm well-established on Slashdot and have a strong pattern of getting modded up significantly. My credentials are verifiable, reputable and significant. You're a newcomer with no credibility, no manners, no recognition, no peer-reviewed publications, probably no degree and I doubt much in the way of an IQ. All you have is a vicious tongue and an attitude that would disgrace a neanderthal.
No sane person would regard me as the source of all wisdom, but any person who - on the strength of what has been posted - had to decide between us as to who was more likely to be the reliable source, well, I suspect I'd win by a landslide.
Bandwidth on the Internet is a major problem. Well, unless it's sent out over multicast with reflectors serving those still using unicast-only ISPs. Good compression helps, of course, but good compression reduces quality and is expensive on CPUs.
The problems are all solvable - don't get me wrong - but it takes either a lot of money or someone with a lot of skill to get something like that set up, and the skill option is the only scalable one.
NASA's boss, Dr. Griffin, has been saying loud and clear to Congress that the budget is fine, that we can go to Mars and that the worst that will happen is a few projects will be delayed.
Now that things are getting tighter, we're discovering that he was playing a political yes-man, that projects have been in extreme danger for some time, and that the current budget might mean the closure of almost all Earth Science departments at NASA.
Please remember that he was specifically asked to get rid of the yes-man culture at NASA, but he has now been exposed as not only not doing so, but has been promoting it through his actions. I hope Congress raises NASA's budget to sane levels, sure, but it won't be easy if NASA won't tell them what levels are needed to be sane.
Whilst Congress is at it, I hope they also pass a bill to fire Dr. Griffin and pass a law prohibiting yes-men from ever being hired or retained by the agency.
I've been running IPv4 routers since, oh, 1991, and IPv6 routers since 1996. I've probably submitted patches to more routing software than you've used and I don't need to slam someone else's viewpoints to be able to claim the validity of my own. I pity the inferior intellect that cannot understand how diversity is a strength, for no intellect capable of learning is truly inferior, thus only those biologically incapable of learning have any business flaming.
By 3 months you mean a year and a half. By "everyone" you mean nobody at all. And you've still not said what this mythical axe is.Are you out of lithium?
You must be able to prove that every valid vote was counted exactly once - no more, no less
You must also be able to prove that fake ballots cannot be injected into the system
You must finally be able to prove that valid votes cannot be deducted from the system for the required length of time
These are a bit trickier than just building a machine that can add 1 to a column, but not THAT much harder.
I would ascribe every digital ballot paper with a hash value that uniquely identifies that paper and would be hard to forge. eg: Have each ballot paper marked with a serial number, then digitally signed by the electoral authorities.
Each voter's voting card would have a totally random public encryption key on it, plus a number. On going to the voting machine, the card would first tick the person off on the list of people who had voted. After casting the votes, the machine would encrypt the ballot paper with the encryption key, then it would append the number to the end. The electronic ballot paper would then, after a random delay, be sent back to the central repository via an SSL connection. The machine would keep no tallies and no records whatsoever. Nor would the local office. It would all be central. (The local office could count votes cast, though, as it would be useful to compare against votes decoded.)
The central system would use the number to select a relatively small set of private keys. It would try each key in turn until it found the key that unlocked that ballot paper. That private key would then be deleted. The unlocked ballot paper would be placed into a secure database. The number of valid votes identified would be counted and publicly published in real-time.
Just to be absolutely certain what is meant here, the database must be write-only from the central system and must be in a tamper-proof environment. Once all ballots are uploaded, it will then perform the count and download the results, ALL of the decrypted ballots and ALL of the encrypted ballots.
That way, anyone can perform a recount and although it would be a monumental task to validate the votes, it could be done. This system is pseudo-anonymous, not truly anonymous, using a VERY large base to make anonymity effective. The upshot is that if a random sample of voter cards were gathered (anonymously!), it would be possible to show that each of those cards matches to exactly one encrypted vote and one decrypted vote.
This shouldn't be necessary, as most of the avenues for fraud have already been eliminated. The effort to fraudulently enter a vote in this system would be extraordinary, as it would require breaking the ballot paper generation system, the encryption key system AND the decryption system, in order to be transparent. Failure to break all of these would result in the votes being rejected by the unbroken component.
I don't think an actual voting system need be this complex, but that's not the point. The point here is that it is possible to imagine a system that is (a) Open Source and (b) so damn-near impervious that it would be cheaper to just buy the person who'd been elected than rig so much as a single vote.
Has this been done? Probably not. Could it be done? Sure. Give me a couple of weeks, a few smart-cards, readers, kiosks and a tamper-proof computer case. There should be no difficulty in writing a system that would be close to iron-clad for the next 50-100 years, with so close to zero chance of tampering that it's just not going to happen.
If an OSS election system group has the hardware and would like to play with this scheme, I'd be happy to write it for them.
I've used every *BSD out there, OpenBSD included. I tend to regard the installer for OpenBSD to be a bit grotty, but serviceable. Package management looks good. Ports is fine. Security - if it ain't B1, it ain't secure. (And even if it is B1, if it ain't audited to the same degree as OpenBSD or better, it ain't worth shit.)
I find Theo a trifle abrasive - most do - but I don't hold that against him. Most highly talented people ARE. I reserve my contempt for talentless scum-buckets who believe that abuse is all the talent you need.
Yes, I'm a little pissed off with the OpenSSH developers - I think they're way too insular and NIH. No biggie. Last time I got into that argument, I forked OpenSSH just to show it could be done.
Hell, don't think I've not done that with others, before - you think I collected all the patches that went into FOLK, massaged them all individually for each and every patch release, and got most of them to actually work together, purely for fun? No, it was to make a point. YOU might like your own private niche, and you're welcome to it, but -I- won't suffer for anything less than everything there is, was, or ever will be. My vision might be a little tougher to obtain than the OpenSSH/OpenBSD crowd's, but the view's a hell of a lot better along the way.
Of a 64-bit chip is the ability to transfer a larger chunk of packet header in a single transfer and the ability to compare a larger amount of data in one go. Saves on these things called "clock cycles".
(Although an IPv4 address is only 32-bits long, IPv6 addresses are 128-bits long. Thus, you can compare addresses in two sets of loads, as opposed to four sets.)
Of OpenMOSIX - now we're getting into the child's play stuff I'd have thought would be obvious to anyone. Let's start with the obvious. OpenMOSIX (with the DSM extension) supports the migration of threads within a process between boxes, whilst keeping the memory accessible to all threads the same. This has two consequences. First, processes that are not directly related to routing but need to run somewhere (eg: SNMP monitoring, router console - if any, encryption for all those IPSec tunnels, etc) can all be farmed out and the boxes directly in-line with the networks need not handle any of that stuff at all.
With the routing itself, it gets more important. Most load-balancing works by flip-flopping between routers. This is only valid if all packets take an equal time to process. So-called "hot-potato" routing is, however, going to be a LOT faster than a lot of other operations, so no such guarantee exists. There is a further complexity. If you have N identical routers, you're assuming that there is an equal amount of all types of traffic, interleaved in such a way that no router is going to spend time idle waiting for traffic it will never get.
Of course, you COULD hand the routing threads migrate to where the work is, instead. Or you could just use OpenMOSIX' DSM to provide a uniform router table to all load-balancing routers and not use thread migration at all. I'd tend to go with migration, as you don't want the overhead of running code you're not currently using, but it works either way.
OR you could use DSM to provide a pool of incoming packets that a large number of software routers on other boxes could all pull from as capacity became available.
The technology DOES have a value - even when not always expected. Only a troll equates expectations with reality.
If the test is "can I get a Linux box that can duplicate the functionality of a Cisco box", then I would argue that most (> 75%) of the functionality needed is present. The Cisco-patented protocols for router detection and hot-swapping aren't there, along with the IETF's hot-swapping VRRP protocol. Neither is MPLS, which is far more irritating in my opinion. (Linux does do some router detection and there are Open Source hot-swapping/high-availability protocols, such as CARP.)
If the test is "can I get a Linux box that can duplicate the functionality of a Cisco box for significantly less than the cost of a Cisco router", then I'd be more hesitant. You're correct that the hardware isn't cheap, and Cisco can buy in bulk. The average customer cannot. It would also be a non-trivial task to find/build a motherboard that can get the throughput and the uptime, let alone for a competitive price.
If the test is "I've a bunch of really weird, shifting constraints, which is better?" then I'd probably go with Linux. Cisco's routers are not easily modified, although I believe there are some modules for them. Cisco are only going to do modules that will turn a profit, though, so for really unusual requirements, you're probably out of luck. You've a better chance finding the hardware and drivers for Linux, although it's far from guaranteed - and not always cheap when it's there.
You're probably looking more at the middle case. In that case, no. Linux is not (at the present time) a good option. I believe Juniper's routers are cheaper than Cisco's, though. My reply was more focused on the first case (can you actually accomplish the task) and I believe the answer is a provisional yes. The last case would mostly apply to very specialized industries, R&D groups, etc, where the requirements are either ill-defined, constantly changing or just plain weird.
It also depends on exactly what's being compared. For example, OpenBSD's support for SMP and 64-bit processors isn't exactly world-class, nor is there anything comparable to OpenMOSIX at this time. Quagga, under Linux, can take advantage of all of these. It'll do so even better when it's properly threaded, and select() is sent to the great bit-bucket in the sky.
Using lots of different systems for a long time tends to make one:
a) More informed about the existence of the other ways of doing things, and
b) Far less abusive. (Particularly when bragging about a secure OS that has no mandatory access controls or role-based memory segmentation.)
Let's see. What possible advantage could there be in not having 4 completely unnecessary context switches, assorted interrupts and an application scheduler call for EVERY packet that traverses the system... Hmmmmm. Tricky. Let me know when you've worked it out.
(The security implications of having something in the kernel would not be a factor in a truly role-based MAC-segmented OS. Indeed, the distinctions between userspace, kernel space, or an entirely remote machine become meaningless.)
mrouted? The best you have to offer is an ancient, abandonware router for DVMRP? For chrissakes, nobody runs that crap these days. PIMv2 has been out for some time, as dense-mode, sparse-mode, bidirectional and source-specific. Its original home was Xerox' PARC (you can still find a copy there, I think). DVMRP is based on the RIP protocol, handles pruning very badly and is generally considered a lamer's protocol.
"Secure routing" is not running a router over IPSec. (Besides which, that would be horribly inefficient. IPSec is good for sustained connections, but the negotiation is expensive and therefore not so great for transmitting occasional state changes.) A secure routing protocol is a routing protocol in which the security is built in (amazingly enough). This may include many of the techniques used in IPSec such as host authentication, packet validation and packet verification, but most will go considerably further to prevent router table poisoning.
(IPSec - or any similar authentication scheme - alone is not enough. If a single router is poisoned, the poison will be carried across the entire system, as that poisoned router will necessarily be trusted. You might as well rely on.rhosts, rather than passwords. Once there's a break ANYWHERE, the break will be EVERYWHERE.)
Secure routing does not operate on a blind trust basis, but has some sort of verification mechanism to prove that the route is indeed valid.
BGP is one protocol. RIP makes two. (Three if you differentiate between RIPv1 and RIPv2.) BGP tends to mean BGP4 - I have never seen any other version implemented on any modern router. OSPF comes in two popular flavours - versions 1 and 2 - but there are flavours for wireless networks, mesh networks and multicast networks, which are generally NOT supported.
In fact, there was nothing there that covered multicasting, mesh, overlay, wireless or hybrid networking. There was nothing there for secure routing, either.
That gives 6 out of 150 and only a fraction of the areas routing protocols have been written for. And this is supposed to impress me? Who the hell are you kidding? These are also stand-alone daemons, not kernel-space routing code.
Oh, and I stopped using OpenBSD when I moved over to MirBSD - it has the security of OpenBSD but far more software and less of an asshole crowd. But, then, anyone whose followed my posts would know this, rather than ignorantly telling me what I'm supposedly ignorant on. (They'd also know I've been using the *BSDs since 1990 - which, I would guess, is somewhat before yourself.)
The quick answer is "yes, you can support T1, etc." The longer answer is "if the kernel supports the necessary driver, or if there's a third-party driver (such as WANPIPE) which supports your T1 device, then there should be no problem, as Xorp uses the kernel to do all low-level operations".
The substantially longer answer is: "Not all boxes of this kind play nice - Qwest's DSL modem runs Linux, as does Linksys, and a whole bunch of other cheap off-the-shelf devices. Very very few of these are updatable by the user - and those that are are mostly that way because enthusiasts hacked them. These firms comply with the GPL only under duress, for the most part. Other firms do play well with the license and respect the consumer with specific needs. Where direct access to the kernel exists, support for T1, DSL, etc, will be very straightforward. If the access doesn't exist, it's possible but substantially harder."
You really want to run Xorp alongside MIT's Click, as that gives you the best routing capability. The two are intended to interoperate, but there's bugger all documentation on doing this.
The number 1 problem with Xorp is that it supports only a tiny fraction of standard Internet routing protocols. They don't have the developers to support anything more than a bare-bones software router. If you're only going to use what they have, it's no big deal. (NOTE: I am only including actual common routing protocols, here. There are over 150 routing protocols defined and implemented by somebody, but few routers support more than 3% and only the Really Major Routers even pass the 10% mark.)
The number 2 problem is that it lets the native OS deal with all of the QoS. This means that Xorp isn't guaranteed to behave the same on different platforms. It's not a lethal problem and some (including the Xorp developers) consider it a major bonus. I'm not convinced it's a good thing, though. It makes multicasting very confusing.
The final problem is that Click will normally be run as a kernel module, but Xorp is in userspace. This means you've a LOT of context switching when running in such a mode. Because you want minimum latency, the overhead of pushing packets into userspace in the first place might not be efficient enough.
I believe Xorp to be a good product. It is also the ONLY software router that is (a) Open Source and (b) being maintained (Quagga, Zebra and MRT are all dead, and GateD was withdrawn). I don't know if the Xorp group want more core developers, but I desperately hope that third-party developers offer patches and modules for it to beef up the abilities.
(Linux is an important software router. NetBSD and OpenBSD could be, if the routing software was good enough. The three of them should have the low-to-medium router market totally sewn up in no time flat, in a very short timeframe. That won't happen, though, if there's not enough independent interest and support.)
Compilers are generally written sufficiently conservatively that problems tend to be safe-but-does-the-wrong-thing code, and the bugs you'd find with the checker would generally be "internal compiler error" bugs, not ones that lead to incorrect output (or any output at all...)
Dunno why, but nearly all the errors I've found are of the "internal compiler error" kind. (Why can't I have a NORMAL error for once?) For Fortran code, for example, I'm generally using G95 because gfortran barfs on a lot of the computational fluid dynamics code I'm using.
Slashdot Mirror
evil.provider.net could also opt to charge a flat fee on the assumption that a typical high-volume multicast might easily reach 10,000+ people.
A third option would be to have the multicast stream start at the ISP, with the broadcaster unicasting to a multicast reflector. The stream would then be encrypted, and decryption keys would be provided on request or at a nominal charge.
I can't remember if it's the anemone or the sea urchin (or both) that uses "arms" to guide food to a mouth. If there is a central mouth, rather than one on each hair (as you might expect on a filter feeder), then my guess would be that the hairs are manipulators for food particles.
(Well, I thought I'd "muscle" in on the jokes)
Paper ballots also pose the problem that you've got to trust the collectors and counters. In many cases, nobody else will ever get to see the ballots themselves, so nobody else will ever know if someone has edited the figures.
I'm not saying paper ballots are a disaster, only that the existing paper ballots are vulnerable to fraud. In some cases, the parties have even been known to "collect" the ballots by mail and dispose of those for the "wrong" side.
These, again, are solvable problems but if ANY system is to be trusted, these problems will have to be solved. I'm less concerned with the "how" than with the "when". WHEN will we have trustable elections?
"How could TiVo be used maliciously?" Bombard TiVo with enough PPV demands and it could start getting expensive. Fill the hard-drive with enough teleshopping or other pr0n, you've essentially managed a denial-of-download attack. America doesn't have anything similar to Open University, but that would be another potentially vulnerable area.
Seriously, the use of tracers - dyes and radioactive isotopes - are fairly common for seeing where things go, so should be usable in cases where something concentrates. In either case, there will be a unique absorption frequency that would identify where concentrations were building up. That same frequency can then be used to literally cook that region and not affect anything else. It would be less damaging than radiotherapy, because it would be targetted.
Why isn't this done, if it's such a neat idea? Because finding something that will concentrate only in the target area is HARD. People have been working on targetted chemotherapy for decades and if there's been a breakthrough, it's not exactly been an Earth-shattering one. If the targetting mechanism could be figured out, then targetted radiotherapy would be better, as nothing away from the target compound or isotope would be affected at all, but it would be much more expensive. (Picture a bunch of microwave lasers, tuned exactly to the resonance frequency of a specific molecule, first scanning the body then blasting all concentrations, where ANY errors on position, frequency or intensity could be lethal.)
...are busy designing Earth II, owing to Earth I being loaded with the wrong Operating System.
Also, cyborg Condors that, on being shot, fly into the shooter and explode.
Now, OSPF, RIP and BGP are very good protocols - even for lots of the special cases - so it's also true that the gains to be had (even in theory) by using a more specific protocol will never be that great. There will be some, but it won't be gigantic.
Cases where these protocols fall down include using Linux on a laptop to route mobile network traffic, using a mesh or hypercube topology, multicasting and situations where network connections are fixed but unreliable. Multicasting is beginning to be fashionable, but none of the others are.
In consequence, it is indeed correct to say that nobody "needs" any more than those three protocols.
In a more abstract sense, I am firmly of the opinion that a wide range of choices (so long as a narrow selection is possible and has no overhead from the width of the original options) is always better than a narrow range (even if it's what you'll likely use anyway). Part of the problem with wide ranges is that they're typically done poorly, so you end up having to install stuff you'll never use. For example, Fedora Core has all kinds of really pointless enforced dependencies that could have been avoided very easily, so I don't consider that to offer genuine freedom of choice. If done right, it gets people to think about what they want to do and how best to do it, rather than to blindly point and click.
Sorry to break it to you, if you've a userland process, you've userland activity. It makes bugger all difference where you'd like things to take place, they take place where the code is. "But packets are routed by the kernel!" That's not what the argument is about, the argument is not about packet flows, it's about BGP, and BGP is processed by the BGP daemon and not the kernel.
(Even if we're talking about packet flows, you're still wrong, as Click routes packets in userspace, which is why it can route them to NS. Oh, you've never used Click or NS? Then don't complain when others know more than your Holiness.)
There's also a matter of source. I'm well-established on Slashdot and have a strong pattern of getting modded up significantly. My credentials are verifiable, reputable and significant. You're a newcomer with no credibility, no manners, no recognition, no peer-reviewed publications, probably no degree and I doubt much in the way of an IQ. All you have is a vicious tongue and an attitude that would disgrace a neanderthal.
No sane person would regard me as the source of all wisdom, but any person who - on the strength of what has been posted - had to decide between us as to who was more likely to be the reliable source, well, I suspect I'd win by a landslide.
The problems are all solvable - don't get me wrong - but it takes either a lot of money or someone with a lot of skill to get something like that set up, and the skill option is the only scalable one.
Now that things are getting tighter, we're discovering that he was playing a political yes-man, that projects have been in extreme danger for some time, and that the current budget might mean the closure of almost all Earth Science departments at NASA.
Please remember that he was specifically asked to get rid of the yes-man culture at NASA, but he has now been exposed as not only not doing so, but has been promoting it through his actions. I hope Congress raises NASA's budget to sane levels, sure, but it won't be easy if NASA won't tell them what levels are needed to be sane.
Whilst Congress is at it, I hope they also pass a bill to fire Dr. Griffin and pass a law prohibiting yes-men from ever being hired or retained by the agency.
I've been running IPv4 routers since, oh, 1991, and IPv6 routers since 1996. I've probably submitted patches to more routing software than you've used and I don't need to slam someone else's viewpoints to be able to claim the validity of my own. I pity the inferior intellect that cannot understand how diversity is a strength, for no intellect capable of learning is truly inferior, thus only those biologically incapable of learning have any business flaming.
By 3 months you mean a year and a half. By "everyone" you mean nobody at all. And you've still not said what this mythical axe is.Are you out of lithium?
These are a bit trickier than just building a machine that can add 1 to a column, but not THAT much harder.
I would ascribe every digital ballot paper with a hash value that uniquely identifies that paper and would be hard to forge. eg: Have each ballot paper marked with a serial number, then digitally signed by the electoral authorities.
Each voter's voting card would have a totally random public encryption key on it, plus a number. On going to the voting machine, the card would first tick the person off on the list of people who had voted. After casting the votes, the machine would encrypt the ballot paper with the encryption key, then it would append the number to the end. The electronic ballot paper would then, after a random delay, be sent back to the central repository via an SSL connection. The machine would keep no tallies and no records whatsoever. Nor would the local office. It would all be central. (The local office could count votes cast, though, as it would be useful to compare against votes decoded.)
The central system would use the number to select a relatively small set of private keys. It would try each key in turn until it found the key that unlocked that ballot paper. That private key would then be deleted. The unlocked ballot paper would be placed into a secure database. The number of valid votes identified would be counted and publicly published in real-time.
Just to be absolutely certain what is meant here, the database must be write-only from the central system and must be in a tamper-proof environment. Once all ballots are uploaded, it will then perform the count and download the results, ALL of the decrypted ballots and ALL of the encrypted ballots.
That way, anyone can perform a recount and although it would be a monumental task to validate the votes, it could be done. This system is pseudo-anonymous, not truly anonymous, using a VERY large base to make anonymity effective. The upshot is that if a random sample of voter cards were gathered (anonymously!), it would be possible to show that each of those cards matches to exactly one encrypted vote and one decrypted vote.
This shouldn't be necessary, as most of the avenues for fraud have already been eliminated. The effort to fraudulently enter a vote in this system would be extraordinary, as it would require breaking the ballot paper generation system, the encryption key system AND the decryption system, in order to be transparent. Failure to break all of these would result in the votes being rejected by the unbroken component.
I don't think an actual voting system need be this complex, but that's not the point. The point here is that it is possible to imagine a system that is (a) Open Source and (b) so damn-near impervious that it would be cheaper to just buy the person who'd been elected than rig so much as a single vote.
Has this been done? Probably not. Could it be done? Sure. Give me a couple of weeks, a few smart-cards, readers, kiosks and a tamper-proof computer case. There should be no difficulty in writing a system that would be close to iron-clad for the next 50-100 years, with so close to zero chance of tampering that it's just not going to happen.
If an OSS election system group has the hardware and would like to play with this scheme, I'd be happy to write it for them.
I find Theo a trifle abrasive - most do - but I don't hold that against him. Most highly talented people ARE. I reserve my contempt for talentless scum-buckets who believe that abuse is all the talent you need.
Yes, I'm a little pissed off with the OpenSSH developers - I think they're way too insular and NIH. No biggie. Last time I got into that argument, I forked OpenSSH just to show it could be done.
Hell, don't think I've not done that with others, before - you think I collected all the patches that went into FOLK, massaged them all individually for each and every patch release, and got most of them to actually work together, purely for fun? No, it was to make a point. YOU might like your own private niche, and you're welcome to it, but -I- won't suffer for anything less than everything there is, was, or ever will be. My vision might be a little tougher to obtain than the OpenSSH/OpenBSD crowd's, but the view's a hell of a lot better along the way.
(Although an IPv4 address is only 32-bits long, IPv6 addresses are 128-bits long. Thus, you can compare addresses in two sets of loads, as opposed to four sets.)
Of OpenMOSIX - now we're getting into the child's play stuff I'd have thought would be obvious to anyone. Let's start with the obvious. OpenMOSIX (with the DSM extension) supports the migration of threads within a process between boxes, whilst keeping the memory accessible to all threads the same. This has two consequences. First, processes that are not directly related to routing but need to run somewhere (eg: SNMP monitoring, router console - if any, encryption for all those IPSec tunnels, etc) can all be farmed out and the boxes directly in-line with the networks need not handle any of that stuff at all.
With the routing itself, it gets more important. Most load-balancing works by flip-flopping between routers. This is only valid if all packets take an equal time to process. So-called "hot-potato" routing is, however, going to be a LOT faster than a lot of other operations, so no such guarantee exists. There is a further complexity. If you have N identical routers, you're assuming that there is an equal amount of all types of traffic, interleaved in such a way that no router is going to spend time idle waiting for traffic it will never get.
Of course, you COULD hand the routing threads migrate to where the work is, instead. Or you could just use OpenMOSIX' DSM to provide a uniform router table to all load-balancing routers and not use thread migration at all. I'd tend to go with migration, as you don't want the overhead of running code you're not currently using, but it works either way.
OR you could use DSM to provide a pool of incoming packets that a large number of software routers on other boxes could all pull from as capacity became available.
The technology DOES have a value - even when not always expected. Only a troll equates expectations with reality.
If the test is "can I get a Linux box that can duplicate the functionality of a Cisco box for significantly less than the cost of a Cisco router", then I'd be more hesitant. You're correct that the hardware isn't cheap, and Cisco can buy in bulk. The average customer cannot. It would also be a non-trivial task to find/build a motherboard that can get the throughput and the uptime, let alone for a competitive price.
If the test is "I've a bunch of really weird, shifting constraints, which is better?" then I'd probably go with Linux. Cisco's routers are not easily modified, although I believe there are some modules for them. Cisco are only going to do modules that will turn a profit, though, so for really unusual requirements, you're probably out of luck. You've a better chance finding the hardware and drivers for Linux, although it's far from guaranteed - and not always cheap when it's there.
You're probably looking more at the middle case. In that case, no. Linux is not (at the present time) a good option. I believe Juniper's routers are cheaper than Cisco's, though. My reply was more focused on the first case (can you actually accomplish the task) and I believe the answer is a provisional yes. The last case would mostly apply to very specialized industries, R&D groups, etc, where the requirements are either ill-defined, constantly changing or just plain weird.
It also depends on exactly what's being compared. For example, OpenBSD's support for SMP and 64-bit processors isn't exactly world-class, nor is there anything comparable to OpenMOSIX at this time. Quagga, under Linux, can take advantage of all of these. It'll do so even better when it's properly threaded, and select() is sent to the great bit-bucket in the sky.
a) More informed about the existence of the other ways of doing things, and
b) Far less abusive. (Particularly when bragging about a secure OS that has no mandatory access controls or role-based memory segmentation.)
Let's see. What possible advantage could there be in not having 4 completely unnecessary context switches, assorted interrupts and an application scheduler call for EVERY packet that traverses the system... Hmmmmm. Tricky. Let me know when you've worked it out.
(The security implications of having something in the kernel would not be a factor in a truly role-based MAC-segmented OS. Indeed, the distinctions between userspace, kernel space, or an entirely remote machine become meaningless.)
mrouted? The best you have to offer is an ancient, abandonware router for DVMRP? For chrissakes, nobody runs that crap these days. PIMv2 has been out for some time, as dense-mode, sparse-mode, bidirectional and source-specific. Its original home was Xerox' PARC (you can still find a copy there, I think). DVMRP is based on the RIP protocol, handles pruning very badly and is generally considered a lamer's protocol.
"Secure routing" is not running a router over IPSec. (Besides which, that would be horribly inefficient. IPSec is good for sustained connections, but the negotiation is expensive and therefore not so great for transmitting occasional state changes.) A secure routing protocol is a routing protocol in which the security is built in (amazingly enough). This may include many of the techniques used in IPSec such as host authentication, packet validation and packet verification, but most will go considerably further to prevent router table poisoning.
(IPSec - or any similar authentication scheme - alone is not enough. If a single router is poisoned, the poison will be carried across the entire system, as that poisoned router will necessarily be trusted. You might as well rely on
Secure routing does not operate on a blind trust basis, but has some sort of verification mechanism to prove that the route is indeed valid.
In fact, there was nothing there that covered multicasting, mesh, overlay, wireless or hybrid networking. There was nothing there for secure routing, either.
That gives 6 out of 150 and only a fraction of the areas routing protocols have been written for. And this is supposed to impress me? Who the hell are you kidding? These are also stand-alone daemons, not kernel-space routing code.
Oh, and I stopped using OpenBSD when I moved over to MirBSD - it has the security of OpenBSD but far more software and less of an asshole crowd. But, then, anyone whose followed my posts would know this, rather than ignorantly telling me what I'm supposedly ignorant on. (They'd also know I've been using the *BSDs since 1990 - which, I would guess, is somewhat before yourself.)
The substantially longer answer is: "Not all boxes of this kind play nice - Qwest's DSL modem runs Linux, as does Linksys, and a whole bunch of other cheap off-the-shelf devices. Very very few of these are updatable by the user - and those that are are mostly that way because enthusiasts hacked them. These firms comply with the GPL only under duress, for the most part. Other firms do play well with the license and respect the consumer with specific needs. Where direct access to the kernel exists, support for T1, DSL, etc, will be very straightforward. If the access doesn't exist, it's possible but substantially harder."
If there's martian frames in Network Neighborhood,
Who do you call?
Packetbusters!
The number 1 problem with Xorp is that it supports only a tiny fraction of standard Internet routing protocols. They don't have the developers to support anything more than a bare-bones software router. If you're only going to use what they have, it's no big deal. (NOTE: I am only including actual common routing protocols, here. There are over 150 routing protocols defined and implemented by somebody, but few routers support more than 3% and only the Really Major Routers even pass the 10% mark.)
The number 2 problem is that it lets the native OS deal with all of the QoS. This means that Xorp isn't guaranteed to behave the same on different platforms. It's not a lethal problem and some (including the Xorp developers) consider it a major bonus. I'm not convinced it's a good thing, though. It makes multicasting very confusing.
The final problem is that Click will normally be run as a kernel module, but Xorp is in userspace. This means you've a LOT of context switching when running in such a mode. Because you want minimum latency, the overhead of pushing packets into userspace in the first place might not be efficient enough.
I believe Xorp to be a good product. It is also the ONLY software router that is (a) Open Source and (b) being maintained (Quagga, Zebra and MRT are all dead, and GateD was withdrawn). I don't know if the Xorp group want more core developers, but I desperately hope that third-party developers offer patches and modules for it to beef up the abilities.
(Linux is an important software router. NetBSD and OpenBSD could be, if the routing software was good enough. The three of them should have the low-to-medium router market totally sewn up in no time flat, in a very short timeframe. That won't happen, though, if there's not enough independent interest and support.)
Dunno why, but nearly all the errors I've found are of the "internal compiler error" kind. (Why can't I have a NORMAL error for once?) For Fortran code, for example, I'm generally using G95 because gfortran barfs on a lot of the computational fluid dynamics code I'm using.