The reality is that doing security audits and code reviews are boring. Unless you have someone who is really dedicated and knows their stuff taking on the task for an open source project, or someone paying a team to do it (TrueCrypt/VeraCrypt), it's not going to happen. In theory corporations are paying their staff so it should happen, but in reality corporations are likely to push such reviews way down the priority list because they cost money. Spending money is bad to a corporation, m'kay?
Personally I've never believed in the "many eyeballs" approach because even when porting an open source project to a new release of an OS or a custom distribution, I only learn the bare surface of the code -- enough to get the port running. I most certainly do not do an in-depth learning and understanding of the code being ported.
As a result, the only one who does any sort of real review is usually the original developer -- the person(s) least likely to see the flaws in their work that are caused by misunderstandings and erroneous assumptions -- because they don't know any different than they did when writing the code in the first place!
Apparently having a different view on things is discouraged nowadays, because every time I disagree with the slashbot masses on politics and theory, I get modded down.
Mod points aren't "disagree" points, assholes. If you disagree, start a discussion.
And it mattered not one whit to me because I don't use any bandwidth-heavy video services like Netflix in the first place. I couldn't care less about the quality of Netflix streams.
None of the services I use are bandwidth intensive. None of those websites are big enough to pay for customized or specialized hardware and links. They've always been at the mercy of the congested public net.
And getting as much of the Netflix traffic off that congested public net as possible can only improve the bandwidth availability for all those other sites.
Channel bonding sends pieces of the request in parallel over the different channels. It does not send the same request over multiple channels. Channel bonding's goal is to increase total bandwidth, not to reduce latency.
Hmm. I just caught the part about the Linux server at the data center doing the demultiplexing.
I suppose, at least in theory, you could go on the assumption that both channels are always sending the same data, and have them forward the request appropriately, cache the message block, and do a comparison on all message blocks incoming over both channels before forwarding one to eliminate the duplicates.
You'd then have to do the same thing on the Windows "client" box at home.
Quite frankly, I can't see how it wouldn't be easier to just get a landline connection. You certainly couldn't rely on "normal" multipath software solutions to do this -- they're designed to switch back and forth between a primary and a failover route, not transmit over both routes at the same time.
You'd also have to become very familiar with the internal driver coding for both Windows and Linux. Certainly not a project for a "new to programming" person who wouldn't think up the simple solution of keeping a queue/cache of requests to check for duplicates in the first place.
TCP can deal with duplicate packets from the same endpoints. Sending duplicate packets over two entirely seperate routes would require that the server be able to deal with demultiplexing the requests. I seriously, seriously doubt that any game servers are set up to do that. As far as the game server would be concerned, it's two seperate clients for the same account connected.
Gee, talk about jumping to erroneous conclusions. The majority of humanity supports itself. Those who can't are the exception, and are still human.
Chimps that could hold down jobs, on the other hand, would be exceedingly rare and would be the exceptional cases (if there are any at all.)
As to the racists who jumped on my post: You people are sick degenerates from the shallowest end of the gene pool and should be flushed from the bowels of humanity.
The Ubuntu upgrade encountered DB/2's configuration and startup scripts in the/etc tree, didn't know what to do with them, had updated half the packages on the system, barfed, and left the system with a non-responsive command prompt. As half the packages were for one release and half for another, the system would no longer even boot. Without the ability to boot even into single user mode, it was clearly impossible to recover the system so I switched to Debian.
I don't know that Debian is immune to the problem, but I've heard far less people complain about failed Debian updates than Ubuntu updates.
Having software that was locally installed, built from source, or otherwise not part of the system software database should not cause an upgrade to crash. At worst it should warn you that there are unrecognized files present and that you'll have to update them manually.
This is the only time in 30+ years of working with computers that I've seen an update crash because it ran into something it didn't recognize. I guess that's "hats off" to Ubuntu for another first.:P
They're all missing one key evaluation point: how do they handle system upgrades? Not updates, but major release upgrades.
I'd been very happy with Ubuntu until it came time to do an upgrade, and it barfed when it encountered my DB/2 LUW server, crashed, and left the machine badly corrupted. Who knows if Debian will fare any better when the time comes, but that's one of the main reasons I chose Debian as my next distro: it doesn't force major upgrades every year or few. (I had been on the Ubuntu LTS cycle for the same reason.)
Slashdot Mirror
The reality is that doing security audits and code reviews are boring. Unless you have someone who is really dedicated and knows their stuff taking on the task for an open source project, or someone paying a team to do it (TrueCrypt/VeraCrypt), it's not going to happen. In theory corporations are paying their staff so it should happen, but in reality corporations are likely to push such reviews way down the priority list because they cost money. Spending money is bad to a corporation, m'kay?
Personally I've never believed in the "many eyeballs" approach because even when porting an open source project to a new release of an OS or a custom distribution, I only learn the bare surface of the code -- enough to get the port running. I most certainly do not do an in-depth learning and understanding of the code being ported.
As a result, the only one who does any sort of real review is usually the original developer -- the person(s) least likely to see the flaws in their work that are caused by misunderstandings and erroneous assumptions -- because they don't know any different than they did when writing the code in the first place!
Apparently having a different view on things is discouraged nowadays, because every time I disagree with the slashbot masses on politics and theory, I get modded down.
Mod points aren't "disagree" points, assholes. If you disagree, start a discussion.
And it mattered not one whit to me because I don't use any bandwidth-heavy video services like Netflix in the first place. I couldn't care less about the quality of Netflix streams.
None of the services I use are bandwidth intensive. None of those websites are big enough to pay for customized or specialized hardware and links. They've always been at the mercy of the congested public net.
And getting as much of the Netflix traffic off that congested public net as possible can only improve the bandwidth availability for all those other sites.
Anyone who relies on the security of a cloud server to protect information that other people want is a fool. Period.
I don't care if it's nude pictures, your stock reports, or your financial data.
The internet is not secure. Sooner or later, a flaw will be found and your data is out in the wild.
There's a big difference between buying a box and funding the research as Microsoft has done.
Channel bonding sends pieces of the request in parallel over the different channels. It does not send the same request over multiple channels. Channel bonding's goal is to increase total bandwidth, not to reduce latency.
Hmm. I just caught the part about the Linux server at the data center doing the demultiplexing.
I suppose, at least in theory, you could go on the assumption that both channels are always sending the same data, and have them forward the request appropriately, cache the message block, and do a comparison on all message blocks incoming over both channels before forwarding one to eliminate the duplicates.
You'd then have to do the same thing on the Windows "client" box at home.
Quite frankly, I can't see how it wouldn't be easier to just get a landline connection. You certainly couldn't rely on "normal" multipath software solutions to do this -- they're designed to switch back and forth between a primary and a failover route, not transmit over both routes at the same time.
You'd also have to become very familiar with the internal driver coding for both Windows and Linux. Certainly not a project for a "new to programming" person who wouldn't think up the simple solution of keeping a queue/cache of requests to check for duplicates in the first place.
TCP can deal with duplicate packets from the same endpoints. Sending duplicate packets over two entirely seperate routes would require that the server be able to deal with demultiplexing the requests. I seriously, seriously doubt that any game servers are set up to do that. As far as the game server would be concerned, it's two seperate clients for the same account connected.
What makes you think the servers can deal with multiple copies of data sanely?
I owned an Amiga, you whelp, so I saw plenty of them.
Nope. I love a good graphics show. But I don't really play games any more, so I can't speak to their playability.
Sorry, but that looks like 1980's level graphics to me, maybe at the level of the early Amiga games. Not impressed.
Apparently you missed all the issues and lost customers reported by Amazon, Microsoft, IBM, et. al. for their cloud services...
Even if you believe such nonsense, the world is the customer, and the customers are leaving in droves.
Not when you don't have overdraft protection.
Screw "American's Faith." You need to start worrying about the world's opinion about your intrusive spies.
Keep a sub-$1 balance in your bank account. :P
Gee, talk about jumping to erroneous conclusions. The majority of humanity supports itself. Those who can't are the exception, and are still human.
Chimps that could hold down jobs, on the other hand, would be exceedingly rare and would be the exceptional cases (if there are any at all.)
As to the racists who jumped on my post: You people are sick degenerates from the shallowest end of the gene pool and should be flushed from the bowels of humanity.
The Ubuntu upgrade encountered DB/2's configuration and startup scripts in the /etc tree, didn't know what to do with them, had updated half the packages on the system, barfed, and left the system with a non-responsive command prompt. As half the packages were for one release and half for another, the system would no longer even boot. Without the ability to boot even into single user mode, it was clearly impossible to recover the system so I switched to Debian.
I don't know that Debian is immune to the problem, but I've heard far less people complain about failed Debian updates than Ubuntu updates.
Having software that was locally installed, built from source, or otherwise not part of the system software database should not cause an upgrade to crash. At worst it should warn you that there are unrecognized files present and that you'll have to update them manually.
This is the only time in 30+ years of working with computers that I've seen an update crash because it ran into something it didn't recognize. I guess that's "hats off" to Ubuntu for another first. :P
They'll have rights as soon as they can hold down jobs to feed themselves.
They're all missing one key evaluation point: how do they handle system upgrades? Not updates, but major release upgrades.
I'd been very happy with Ubuntu until it came time to do an upgrade, and it barfed when it encountered my DB/2 LUW server, crashed, and left the machine badly corrupted. Who knows if Debian will fare any better when the time comes, but that's one of the main reasons I chose Debian as my next distro: it doesn't force major upgrades every year or few. (I had been on the Ubuntu LTS cycle for the same reason.)
Dragging CAT6 is no worse than dragging a phone line. Get off your lazy arse and do it.
Running VAX software just ain't no fun unless you're causing a city-wide brownout with the power drain... :P
When the DEA seizes a cell phone from a drug dealer, are they allowed to call numbers stored in the cell phone, posing as the dealer in question?
If not, then what they did with this Facebook page is also illegal.
All they have to do is put up a new login/greeting page that reads "Welcome to Facebook, test subject 42. All your actions are belong to us."