While we're at it, they're just flagging files transfered.. What if someone sets up a relayer in a country where its legal and uses it to send kiddieporn to you via email? Click a message, commit a crime and go to jail. Or if someone defaces a site and puts up CP, or if someone just ups random CP to a public site(4chan), or any number of other ways.
This is what worries me about the "it's illegal to view $foo" laws - it's entirely possible that you don't know you're about to view $foo until it's too late and you've broken the law. Is there a need to go after people who have simply downloaded something dodgy since they may not have intentionally done so? Better to concentrate on people who are *paying* for content since by paying they are financially supporting the continuation of the crime (the people who haven't paid are not supporting the real criminals).
If we make sure The Good Guys (read: us) have 99 times as much nukular weapons as The Bad Guys (read: them), then only 1% of all nukular weapons will be in the hands of the Bad Guys.
Are you sure you're the good guys? Maybe you only think your the good guys because you have enough nukes to prevent anyone suggesting you're the bad guys. I imagine that if China had vastly more nukes than anyone else then they would probably be considered "the good guys" since they'd squash anyone who disagreed.
Assuming you are talking about the US, I would argue that recent actions have put the US firmly in the "bad guys" camp to my mind. Assuming you are right is really arrogant. Hint: both democracy and capitalism are flawed, yet you are forcing them upon the rest of the world. Given these known flaws, who are you to decide that democracy and capitalism it the only "good" system for everyone?
Tell that to the people who just want a router (not hacking it or anything), and had to find out that v5 fails at even fairly basic tasks. They used the cheapest tool for the job
VxWorks is non-free, so I very much doubt it's cheaper to licence than Linux (which costs nothing). Also, VxWorks' stability is well proven (you think they'd run it on the Mars rovers if it wasn't?) - the problems are most likley to be with Cisco's software, not the OS. So blaming the OS and claiming that it would work perfectly if they used Linux is bogus when the problems are almost certainly in Cisco's code.
Don't get me wrong, I'm all in favour of using Linux on devices, but it has to make economic sense and if paying a licence fee for VxWorks and saving money on the hardware works out more economic than running Linux on more costly hardware then I'm not sure how you can claim this is wrong.
Linksys did it the way they did as a backhanded way to cash in on the Free Software crowd. You can tell because the GL is basically the same hardware as the V4, but they increased the price
You need to learn about economies of scale. The v5 is cheaper hardware, thus it is better for the people who don't want to flash it - this is the vast majority of the customer base. They have continued to sell the v4 for the very tiny fraction of the customer base who want to flash them. They will be manufacturing the v4 in (relatively) small factory runs and this increases the manufacturing cost for each unit. Not to mention the costs associated with stocking an extra low-volume product line. Whilest this probably doesn't account for the entire price increase, it will certainly be significant.
If Linksys actually cared about the community they'd have just continued with one version
I'm not sure how becoming uncompetetive in the market place benefits anyone. The vast majority of customers *do not know or care* about hacking these devices, so why should they pay for more expensive hardware just so that a few people can hack them?
or at least continued to use Linux on the crippled "normal" V5.
The v5 has much less resources (RAM/Flash) and VxWorks is much smaller than Linux. They used the best tool for the job. Remember the job _they_ are trying to do is different to what you ware trying to do - they just want to sell an access point, they don't want to include the extra features that you can get by running WhiteRussian or similar.
Cisco is a business who's job is to make money. The fact that they obviously believe that they can make money (or at least not lose money) by selling the GL version to the small number of us who want to be able to flash it is a Good Thing, even if that means we get charged slightly more.
Remember that a proportion of the sales of their more expensive hardware may well be undercut by people running hacked 54GL's - I bought mine so I could flash it with WhiteRussian and turn on 802.1q support, if this hadn't been possible I probably ended up buying something more expensive in order to get the functionality.
The more businesses that realise they can make money by selling what we want instead of ignoring us as a minority the better.
In fact, they have released WRT54GL with linux, specifically for this purpose. They just didn't want people bricking their routers and returning them under warranty.
Well it's actually dead easy to recover a bricked 54GL, they have a very sane design (the bootloader will fire up the NIC on a known IP address and run a tftp server if it can't load the OS so you can upload new firmware).
It seems the real reason why they sell both the 54GL and the 54G-v5 is that the v5 is cheaper hardware (good for the people who want to use the stock firmware) but the market for the people who did want to flash it was considered big enough to continue selling hardware to (at a higher price). I wouldn't be supprised if the support costs on the GL series are much lower too, since most people who buy it will probably have Clue.
I hope this is a lesson to other companies - there is a market for open, hackable devices.
If you think you can turn any WRT54g into a $400 router, you are dead wrong. Those things are unstable as hell, even with Linux on them.
Umm, my WRT54GL running WhiteRussian has only ever crashed when there was a brownout (which also took out my Sky decoder and stereo). I think your argument is bogus.
For one, they just aren't fast enough to satisfy even a couple of users who, say, use BitTorrent or play games or use VoIP.
This rather depends on what you're using it for. The CPU is easilly fast enough to bridge 802.11g traffic onto the switch (which is what it's intended for).
The VxWorks version is downright unusable.
So, umm, flash it with Linux?
buying the GL version is not much of an option for us poor shmucks who already own these pieces of shit with their shitty little OS.
Isn't that kind of your own fault for not researching what you were purchasing - you can't expect to be able to flash just any piece of hardware with an alternative firmware. Besides, stop moaning - if you really want to flash it then now you can.
Practical clothes can be churned out by machines in a matter of seconds, if we set them up and tell them to do it, yet much of what is worn in the so-called first world is made by hand by people leaving in poverty conditions in less-developed countries.
Whilest having people work for a crumby wage is bad, I'm not sure why you think having machines do their job is better - now they've gone from working for a crumby wage to being unemployed... hardly progress.
However this is not the recommended route, and things may be more complex than this (for example requiring you to update yum, rpm and associated packages first). The kernel does not normally need to be updated first, and you run a greater risk of ending up with an unbootable machine if you do so.
I'm hoping these kinds of upgrades become supported at some point, especially now Fedora is using yum at install time too. Although I've usually avoided doing upgrades, preferring complete ground-up reinstalls since most of the upgrades I've done (using Anaconda) have ended up slightly broken at best case or completely trashed at worst case.
Whilest I've used RedHat distributions for years and will likely continue to use Fedora Core in the foreseeable future, the attitude to some of these bugs has at times shocked me. I think it was in my upgrade from Fedora 2 to 3, FireFox didn't exist in Fedora 2 so I had it installed from the Mozilla release instead of in an RPM. The upgrade tried to install the firefox RPM, found an existing firefox directory and failed. Rather than handling this error cleanly and just skipping the (fairly unimportant) RPM Anaconda aborted the whole install, leaving a half upgraded and completely unbootable system. A fairly serious error I thought, so I reported it and got a reply "well don't do that then" and it was marked as NOTABUG. Now I'm sorry, but if an upgrade can completely trash a fully functional system I think that qualifies as quite a serious bug. Interestingly, it got reopened a few months later and I was asked to provide more debugging, which of course I couldn't do since I had long since erased and reinstalled the trashed system.
I do think they've missed a trick with using yum as the installer though - when doing a network install there's still no way to use the fedora-updates repository at install time, you still have to install the system with the old packages and then yum update it later.
I think the market will make them behave just fine.
This has been shown to be untrue time and time again: If a big player in the market throws it's weight around in order to crush the competition the the small businesses just can't survive and become a big threat to the big player. The result - a monopoly (or cartel of corporations) who can do whatever they want. They can pretty much charge what they want and provide a very poor service and make very good profits, even though they are certainly not behaving.
Look at the likes of Microsoft, large telecomms companies, TV companies, etc - all these industries have similar problems. Here in the UK we do at least have regulation, but there are still numerous examples of people like BT, BSkyB, etc using their market positions in an opressive way and benefitting from it.
The Challenger would have exploded just as violently if it was powered by Lithium, or any other fuel you care to mention.
Well, energy density and ease of setting of a chain reaction aren't the same thing - you can have a very energy-dense material which is quite stable (think how much energy is stored in a block of C4, yet it's actually quite difficult to detonate it).
Also, Challenger didn't "explode" - it broke up in the hypersonic airstream and the fuel simply ignighted in the air - even if it had very stable fuel it would still have broken up just as violently, you just might not have seen a big fireball at the same time.
I don't ever watch reality shows under any circumstances, but I'm waiting for a Big Brother series which puts McBride, Ballmer, Gates, RMS and a few people from the RIAA and MPAA in a house together (probably with a few chairs) - I'd watch that.:)
that's assuming that the 3rd party ever would download the said data:)
Bittorrent, unlike other P2P systems, only networks clients who are downloading the same torrent, so it's fairly safe to assume that any other client in the swarm will eventually get the chunk you're after. *
(* Admittedly you can exclude specific files from the torrent on some clients, but it would be rare for all clients to exclude the same chunks).
Also, I'd have to ask - what's in it for the people with sensible networks who have to expend their bandwidth to route traffic between people on broken networks? The only people who gain are the people who aren't accepting inbound connections, the rest of the network suffers as a result.
there are quite a lot of places where all inbound traffic is prohibited - ability to download through a bittorrent would reduce load on ftp/http/etc servers - unfortunately, currently i am forced to download everything from the official mirrors.
If you are stuck somewhere where inbound traffic is prohibited then there is no point in downloading from a P2P system anyway. Yes, you reduce the load on the HTTP servers but you increase the load on the bittorrent network so there is no net gain.
The whole point in P2P is that everyone contributes to the network and this increases the performance for everyone, if you have a large chunk of users not contributing then the whole network suffers, becomes a client/server architecture and there's suddenly no advantage in using BitTorrent over a client/server system such as HTTP.
It's worth noting that BitTorrent (and most other P2P technologies) keep track of your up/down ratio and will give you artificially bad download performance if you're not uploading, so you're almost certainly better off just grabbing the data from an official mirror.
first, it is possible to connect to peers who have incoming ports open. that limits available peers and prohibits anybody else from downloading from such a peer.
Whilest some P2P technologies support doing this, I believe that the Bittorrent protocol doesn't since it is considered a Bad Thing (leads to clients doing a lot of downloading but not uploading much).
second, there are protocols/clients who support connecting of two such peers through a third party. that usually limits network connection speed, but allows communication as long as there's that third party.
Again, I believe the Bittorrent protocol doesn't support this mode since it is considered pointless - no point in routing traffic through a 3rd party if you can just wait until that 3rd party has downloaded the chunk you're interested in itself. Doing this kind of routing takes bandwidth away from the rest of the network just because you have a poor network configuration and that's the sort of thing Bittorrent (quite rightly) tries to discourage - don't pander to the people who can't configure their networks correctly at the expense of other users.
Actually they can't even do 1GHz at light speed. But that's why we have pipelining, and current generation have between 10-20 pipeline steps..
Not to mention that signals don't travel at c inside the chips. However, the signal path lengths can be decreased substantially by producing 3D integrated circuits. However, then heat dissipation becomes a real problem since there's more silicon for the heat to pass through before it gets to your heatsink. Of course this may not be a problem if your heatsink has a temperature of 4.5K:)
I'm curious how silicon reacts to these temperatures though - a lot of stuff becomes superconducting at such low temperatures.
After all, even 802.11 gear runs at 2.4GHz, that's enough to cook ones private parts after extended use of a laptop.
No, it isn't. 802.11 kit has an RF power output of around 100mW - absolute peanuts compared to your 800W microwave oven. The RF radiation from an 802.11 network isn't enough to cook anything.
What you might be referring to is the thermal output produced by a laptop, which is down to the CPU and hard drive rather than the 802.11 transmitter and that can cook your privates mostly through conduction, not radiation.
2. bittorrent downloads don't work through an http proxy;
You'll never get bittorrent running through an HTTP proxy - the whole point of P2P is that people can connect to you and download chunks for the file. If you're going through a HTTP proxy people are clearly not going to be able to do this.
True. However, if everyone blocked popups and Flash banners that play music then these forms of advertising would die and be replaced with things that don't get blocked, such as Google's text-only ads. This is a Good Thing.
So to reiterate: blocking all adds - bad, blocking only excessively annoying ads - good.
So all packages I have to maintain (eg, on webservers) are compiled from source with the compile flags I need, into seperate directories to keep it tidier and... yeah, seperate.
If you can afford the time to recompile every piece of software when you need to do a security update then you've got a helluva lot more time to burn than me. I suspect that instead, you're just not keeping ontop of the security updates. For me I'm quite happy with "yum update" happening regularly to keep my packages up to date.
my feeling is that nVidia still provide just about the best support there is for graphics cards on non-windows platforms, and I applaud their efforts at being inclusive rather than taking the snotty pro-windows stance that other developers assume.
Certainly - I don't want to stop nVidia from supporting Linux, they do have about the best support at the moment. But I'm very wary of making it as easy and legal for people to produce binary drivers as it is for them to produce FOSS drivers.
Sure, I would be even happier if their code was open-source, but by far the majority of users are not interested in hacking that code anyway.
Ah, but this is missing the point entirely - you don't need the majority of users to hack it. Look at the Linux kernel, for example: the majority of users don't touch the code, but the few that do make it better for everyone. So even if you have no interest in hacking the code yourself, the very fact that it's open and other people can hack it can lead to improved drivers for you.
People tend to put more effort into code if they are trying to fix a bug that's causing them problems rather than just because their boss told them to.:)
It's worth pointing out that pretty much every remotely mainstream OS *except* Linux manages to work (and work well) with a stable kernel ABI.
Also worth pointing out that much of the stability trouble in Windows is caused by shoddy drivers - FOSS drivers are traditionally more stable than closed drivers (not least because when bugs are found, people with a vested interest in fixing them will often do so rather than waiting for the manufacturer to get their finger out).
Whilest a stable ABI may result in more drivers being made available, I fear it could lead to a lot of "Windows quality" drivers. And if closed drivers are officially legitimised, many companies will refuse to release open drivers since there is very little in it for them. At the moment, many of the open drivers are there because the vendor believes that releasing a binary driver is legally dubious at best - legitimise binary drivers and this motivation goes away.
Anyone who's dealt with bugs in the nVidia drivers will know of the problems of closed development - I've reported bugs that have taken years for nVidia to fix which I would've been happy to try and fix myself if only the code was open.
I like whatever I need to just be there, so whatever I'm doing with harddrives etc, doesn't matter. No more "crap, I can't access this filesystem without module x, which is -on- that filesystem" or anything like that. Simplicity.
Modern distros automagically load the right stuff into the initrd and load the right modules when they are needed. The only thing I've had to modprobe manually in ages is the sctp module, and even that can be fixed by adding the right magic to the modprobe.conf (no, I don't know why it isn't there by default).
In my experience you're more likley to find yourself lacking the right drivers if you muck about with the kernel config yourself rather than just letting the distro do The Right Thing. There is a place for compiling stuff directly into the kernel, and that's embedded systems - for workstations running a standard distro you're far better off just letting the distro do it's thing.
Sure there is. There's just not a consistent ABI, and that's on purpose.
If you're contributing a driver, GREAT. It'll compile against the currently installed kernel just fine.
Untrue I'm afraid. If your modules aren't in-tree then they *will* break every so often because the kernel API is not stable. Especially under the 2.6 development model - under the previous 2.4/2.5 model you were pretty much guaranteed that API breakages would only be happening in the 2.5 tree, now they happen at any point in the 2.6 tree. (Yes, I do know this stuff - I work on out-of-tree kernel code).
There is some arguement that all drivers should be in-tree, and for common hardware it is definately a Good Thing to have the drivers in the tree - as the API changes then the person implementing the API change will fix up all the in-tree code that uses that API.
For very specialist and expensive hardware it poses a problem though: the person who does the API change won't have the hardware to test with, and probably all the people who use that hardware are using enterprise distributions so breakages to the module won't be spotted for a long time. It's hard for the hardware vendor to track these kinds of updates and perform the necessary regression testing.
Did you setup your IPv6 in a similar matter ? how did you set it up ? (im always looking for new ways to do things)
My Fedora Core 4 server has a global scope IPv4 address (I have a/29 global scope subnet on my end of my DSL) and just turned on 6-to-4 which is very easy under Fedora (you basically just set IPV6TO4INIT=yes in your/etc/sysconfig/network-scripts/ifcfg-eth0 file and it Just Works). The machine runs radvd so the rest of my network gets native v6 connectivity.
If you have a wrt and dd-wrt or one of the linux versions you should look into it. Once it's setup on the router it's easy as one command to setup on your clients.
As I already mentioned, I already use IPv6. My point was that the person who's trying to send a file over IM probably doesn't.
Slashdot Mirror
While we're at it, they're just flagging files transfered.. What if someone sets up a relayer in a country where its legal and uses it to send kiddieporn to you via email? Click a message, commit a crime and go to jail. Or if someone defaces a site and puts up CP, or if someone just ups random CP to a public site(4chan), or any number of other ways.
This is what worries me about the "it's illegal to view $foo" laws - it's entirely possible that you don't know you're about to view $foo until it's too late and you've broken the law. Is there a need to go after people who have simply downloaded something dodgy since they may not have intentionally done so? Better to concentrate on people who are *paying* for content since by paying they are financially supporting the continuation of the crime (the people who haven't paid are not supporting the real criminals).
If we make sure The Good Guys (read: us) have 99 times as much nukular weapons as The Bad Guys (read: them), then only 1% of all nukular weapons will be in the hands of the Bad Guys.
Are you sure you're the good guys? Maybe you only think your the good guys because you have enough nukes to prevent anyone suggesting you're the bad guys. I imagine that if China had vastly more nukes than anyone else then they would probably be considered "the good guys" since they'd squash anyone who disagreed.
Assuming you are talking about the US, I would argue that recent actions have put the US firmly in the "bad guys" camp to my mind. Assuming you are right is really arrogant. Hint: both democracy and capitalism are flawed, yet you are forcing them upon the rest of the world. Given these known flaws, who are you to decide that democracy and capitalism it the only "good" system for everyone?
Tell that to the people who just want a router (not hacking it or anything), and had to find out that v5 fails at even fairly basic tasks. They used the cheapest tool for the job
VxWorks is non-free, so I very much doubt it's cheaper to licence than Linux (which costs nothing). Also, VxWorks' stability is well proven (you think they'd run it on the Mars rovers if it wasn't?) - the problems are most likley to be with Cisco's software, not the OS. So blaming the OS and claiming that it would work perfectly if they used Linux is bogus when the problems are almost certainly in Cisco's code.
Don't get me wrong, I'm all in favour of using Linux on devices, but it has to make economic sense and if paying a licence fee for VxWorks and saving money on the hardware works out more economic than running Linux on more costly hardware then I'm not sure how you can claim this is wrong.
Linksys did it the way they did as a backhanded way to cash in on the Free Software crowd. You can tell because the GL is basically the same hardware as the V4, but they increased the price
You need to learn about economies of scale. The v5 is cheaper hardware, thus it is better for the people who don't want to flash it - this is the vast majority of the customer base. They have continued to sell the v4 for the very tiny fraction of the customer base who want to flash them. They will be manufacturing the v4 in (relatively) small factory runs and this increases the manufacturing cost for each unit. Not to mention the costs associated with stocking an extra low-volume product line. Whilest this probably doesn't account for the entire price increase, it will certainly be significant.
If Linksys actually cared about the community they'd have just continued with one version
I'm not sure how becoming uncompetetive in the market place benefits anyone. The vast majority of customers *do not know or care* about hacking these devices, so why should they pay for more expensive hardware just so that a few people can hack them?
or at least continued to use Linux on the crippled "normal" V5.
The v5 has much less resources (RAM/Flash) and VxWorks is much smaller than Linux. They used the best tool for the job. Remember the job _they_ are trying to do is different to what you ware trying to do - they just want to sell an access point, they don't want to include the extra features that you can get by running WhiteRussian or similar.
Cisco is a business who's job is to make money. The fact that they obviously believe that they can make money (or at least not lose money) by selling the GL version to the small number of us who want to be able to flash it is a Good Thing, even if that means we get charged slightly more.
Remember that a proportion of the sales of their more expensive hardware may well be undercut by people running hacked 54GL's - I bought mine so I could flash it with WhiteRussian and turn on 802.1q support, if this hadn't been possible I probably ended up buying something more expensive in order to get the functionality.
The more businesses that realise they can make money by selling what we want instead of ignoring us as a minority the better.
In fact, they have released WRT54GL with linux, specifically for this purpose. They just didn't want people bricking their routers and returning them under warranty.
Well it's actually dead easy to recover a bricked 54GL, they have a very sane design (the bootloader will fire up the NIC on a known IP address and run a tftp server if it can't load the OS so you can upload new firmware).
It seems the real reason why they sell both the 54GL and the 54G-v5 is that the v5 is cheaper hardware (good for the people who want to use the stock firmware) but the market for the people who did want to flash it was considered big enough to continue selling hardware to (at a higher price). I wouldn't be supprised if the support costs on the GL series are much lower too, since most people who buy it will probably have Clue.
I hope this is a lesson to other companies - there is a market for open, hackable devices.
If you think you can turn any WRT54g into a $400 router, you are dead wrong. Those things are unstable as hell, even with Linux on them.
Umm, my WRT54GL running WhiteRussian has only ever crashed when there was a brownout (which also took out my Sky decoder and stereo). I think your argument is bogus.
For one, they just aren't fast enough to satisfy even a couple of users who, say, use BitTorrent or play games or use VoIP.
This rather depends on what you're using it for. The CPU is easilly fast enough to bridge 802.11g traffic onto the switch (which is what it's intended for).
The VxWorks version is downright unusable.
So, umm, flash it with Linux?
buying the GL version is not much of an option for us poor shmucks who already own these pieces of shit with their shitty little OS.
Isn't that kind of your own fault for not researching what you were purchasing - you can't expect to be able to flash just any piece of hardware with an alternative firmware. Besides, stop moaning - if you really want to flash it then now you can.
Practical clothes can be churned out by machines in a matter of seconds, if we set them up and tell them to do it, yet much of what is worn in the so-called first world is made by hand by people leaving in poverty conditions in less-developed countries.
Whilest having people work for a crumby wage is bad, I'm not sure why you think having machines do their job is better - now they've gone from working for a crumby wage to being unemployed... hardly progress.
However this is not the recommended route, and things may be more complex than this (for example requiring you to update yum, rpm and associated packages first). The kernel does not normally need to be updated first, and you run a greater risk of ending up with an unbootable machine if you do so.
I'm hoping these kinds of upgrades become supported at some point, especially now Fedora is using yum at install time too. Although I've usually avoided doing upgrades, preferring complete ground-up reinstalls since most of the upgrades I've done (using Anaconda) have ended up slightly broken at best case or completely trashed at worst case.
Whilest I've used RedHat distributions for years and will likely continue to use Fedora Core in the foreseeable future, the attitude to some of these bugs has at times shocked me. I think it was in my upgrade from Fedora 2 to 3, FireFox didn't exist in Fedora 2 so I had it installed from the Mozilla release instead of in an RPM. The upgrade tried to install the firefox RPM, found an existing firefox directory and failed. Rather than handling this error cleanly and just skipping the (fairly unimportant) RPM Anaconda aborted the whole install, leaving a half upgraded and completely unbootable system. A fairly serious error I thought, so I reported it and got a reply "well don't do that then" and it was marked as NOTABUG. Now I'm sorry, but if an upgrade can completely trash a fully functional system I think that qualifies as quite a serious bug. Interestingly, it got reopened a few months later and I was asked to provide more debugging, which of course I couldn't do since I had long since erased and reinstalled the trashed system.
I do think they've missed a trick with using yum as the installer though - when doing a network install there's still no way to use the fedora-updates repository at install time, you still have to install the system with the old packages and then yum update it later.
I think the market will make them behave just fine.
This has been shown to be untrue time and time again: If a big player in the market throws it's weight around in order to crush the competition the the small businesses just can't survive and become a big threat to the big player. The result - a monopoly (or cartel of corporations) who can do whatever they want. They can pretty much charge what they want and provide a very poor service and make very good profits, even though they are certainly not behaving.
Look at the likes of Microsoft, large telecomms companies, TV companies, etc - all these industries have similar problems. Here in the UK we do at least have regulation, but there are still numerous examples of people like BT, BSkyB, etc using their market positions in an opressive way and benefitting from it.
Clearly the solution for stopping people finding security holes is to make distributing open source hacking tools illegal.
:)
I think gcc, gdb and vim all constitute open source hacking tools... Oh sorry, did you mean cracking tools?
The Challenger would have exploded just as violently if it was powered by Lithium, or any other fuel you care to mention.
Well, energy density and ease of setting of a chain reaction aren't the same thing - you can have a very energy-dense material which is quite stable (think how much energy is stored in a block of C4, yet it's actually quite difficult to detonate it).
Also, Challenger didn't "explode" - it broke up in the hypersonic airstream and the fuel simply ignighted in the air - even if it had very stable fuel it would still have broken up just as violently, you just might not have seen a big fireball at the same time.
SCO should make a reality show.
:)
I don't ever watch reality shows under any circumstances, but I'm waiting for a Big Brother series which puts McBride, Ballmer, Gates, RMS and a few people from the RIAA and MPAA in a house together (probably with a few chairs) - I'd watch that.
that's assuming that the 3rd party ever would download the said data :)
Bittorrent, unlike other P2P systems, only networks clients who are downloading the same torrent, so it's fairly safe to assume that any other client in the swarm will eventually get the chunk you're after. *
(* Admittedly you can exclude specific files from the torrent on some clients, but it would be rare for all clients to exclude the same chunks).
Also, I'd have to ask - what's in it for the people with sensible networks who have to expend their bandwidth to route traffic between people on broken networks? The only people who gain are the people who aren't accepting inbound connections, the rest of the network suffers as a result.
there are quite a lot of places where all inbound traffic is prohibited - ability to download through a bittorrent would reduce load on ftp/http/etc servers - unfortunately, currently i am forced to download everything from the official mirrors.
If you are stuck somewhere where inbound traffic is prohibited then there is no point in downloading from a P2P system anyway. Yes, you reduce the load on the HTTP servers but you increase the load on the bittorrent network so there is no net gain.
The whole point in P2P is that everyone contributes to the network and this increases the performance for everyone, if you have a large chunk of users not contributing then the whole network suffers, becomes a client/server architecture and there's suddenly no advantage in using BitTorrent over a client/server system such as HTTP.
It's worth noting that BitTorrent (and most other P2P technologies) keep track of your up/down ratio and will give you artificially bad download performance if you're not uploading, so you're almost certainly better off just grabbing the data from an official mirror.
first, it is possible to connect to peers who have incoming ports open. that limits available peers and prohibits anybody else from downloading from such a peer.
Whilest some P2P technologies support doing this, I believe that the Bittorrent protocol doesn't since it is considered a Bad Thing (leads to clients doing a lot of downloading but not uploading much).
second, there are protocols/clients who support connecting of two such peers through a third party. that usually limits network connection speed, but allows communication as long as there's that third party.
Again, I believe the Bittorrent protocol doesn't support this mode since it is considered pointless - no point in routing traffic through a 3rd party if you can just wait until that 3rd party has downloaded the chunk you're interested in itself. Doing this kind of routing takes bandwidth away from the rest of the network just because you have a poor network configuration and that's the sort of thing Bittorrent (quite rightly) tries to discourage - don't pander to the people who can't configure their networks correctly at the expense of other users.
Actually they can't even do 1GHz at light speed. But that's why we have pipelining, and current generation have between 10-20 pipeline steps..
:)
Not to mention that signals don't travel at c inside the chips. However, the signal path lengths can be decreased substantially by producing 3D integrated circuits. However, then heat dissipation becomes a real problem since there's more silicon for the heat to pass through before it gets to your heatsink. Of course this may not be a problem if your heatsink has a temperature of 4.5K
I'm curious how silicon reacts to these temperatures though - a lot of stuff becomes superconducting at such low temperatures.
After all, even 802.11 gear runs at 2.4GHz, that's enough to cook ones private parts after extended use of a laptop.
No, it isn't. 802.11 kit has an RF power output of around 100mW - absolute peanuts compared to your 800W microwave oven. The RF radiation from an 802.11 network isn't enough to cook anything.
What you might be referring to is the thermal output produced by a laptop, which is down to the CPU and hard drive rather than the 802.11 transmitter and that can cook your privates mostly through conduction, not radiation.
2. bittorrent downloads don't work through an http proxy;
You'll never get bittorrent running through an HTTP proxy - the whole point of P2P is that people can connect to you and download chunks for the file. If you're going through a HTTP proxy people are clearly not going to be able to do this.
if everybody blocked Google ads, Google would die
True. However, if everyone blocked popups and Flash banners that play music then these forms of advertising would die and be replaced with things that don't get blocked, such as Google's text-only ads. This is a Good Thing.
So to reiterate: blocking all adds - bad, blocking only excessively annoying ads - good.
So all packages I have to maintain (eg, on webservers) are compiled from source with the compile flags I need, into seperate directories to keep it tidier and... yeah, seperate.
If you can afford the time to recompile every piece of software when you need to do a security update then you've got a helluva lot more time to burn than me. I suspect that instead, you're just not keeping ontop of the security updates. For me I'm quite happy with "yum update" happening regularly to keep my packages up to date.
my feeling is that nVidia still provide just about the best support there is for graphics cards on non-windows platforms, and I applaud their efforts at being inclusive rather than taking the snotty pro-windows stance that other developers assume.
:)
Certainly - I don't want to stop nVidia from supporting Linux, they do have about the best support at the moment. But I'm very wary of making it as easy and legal for people to produce binary drivers as it is for them to produce FOSS drivers.
Sure, I would be even happier if their code was open-source, but by far the majority of users are not interested in hacking that code anyway.
Ah, but this is missing the point entirely - you don't need the majority of users to hack it. Look at the Linux kernel, for example: the majority of users don't touch the code, but the few that do make it better for everyone. So even if you have no interest in hacking the code yourself, the very fact that it's open and other people can hack it can lead to improved drivers for you.
People tend to put more effort into code if they are trying to fix a bug that's causing them problems rather than just because their boss told them to.
It's worth pointing out that pretty much every remotely mainstream OS *except* Linux manages to work (and work well) with a stable kernel ABI.
Also worth pointing out that much of the stability trouble in Windows is caused by shoddy drivers - FOSS drivers are traditionally more stable than closed drivers (not least because when bugs are found, people with a vested interest in fixing them will often do so rather than waiting for the manufacturer to get their finger out).
Whilest a stable ABI may result in more drivers being made available, I fear it could lead to a lot of "Windows quality" drivers. And if closed drivers are officially legitimised, many companies will refuse to release open drivers since there is very little in it for them. At the moment, many of the open drivers are there because the vendor believes that releasing a binary driver is legally dubious at best - legitimise binary drivers and this motivation goes away.
Anyone who's dealt with bugs in the nVidia drivers will know of the problems of closed development - I've reported bugs that have taken years for nVidia to fix which I would've been happy to try and fix myself if only the code was open.
I like whatever I need to just be there, so whatever I'm doing with harddrives etc, doesn't matter. No more "crap, I can't access this filesystem without module x, which is -on- that filesystem" or anything like that. Simplicity.
Modern distros automagically load the right stuff into the initrd and load the right modules when they are needed. The only thing I've had to modprobe manually in ages is the sctp module, and even that can be fixed by adding the right magic to the modprobe.conf (no, I don't know why it isn't there by default).
In my experience you're more likley to find yourself lacking the right drivers if you muck about with the kernel config yourself rather than just letting the distro do The Right Thing. There is a place for compiling stuff directly into the kernel, and that's embedded systems - for workstations running a standard distro you're far better off just letting the distro do it's thing.
Sure there is. There's just not a consistent ABI, and that's on purpose.
If you're contributing a driver, GREAT. It'll compile against the currently installed kernel just fine.
Untrue I'm afraid. If your modules aren't in-tree then they *will* break every so often because the kernel API is not stable. Especially under the 2.6 development model - under the previous 2.4/2.5 model you were pretty much guaranteed that API breakages would only be happening in the 2.5 tree, now they happen at any point in the 2.6 tree. (Yes, I do know this stuff - I work on out-of-tree kernel code).
There is some arguement that all drivers should be in-tree, and for common hardware it is definately a Good Thing to have the drivers in the tree - as the API changes then the person implementing the API change will fix up all the in-tree code that uses that API.
For very specialist and expensive hardware it poses a problem though: the person who does the API change won't have the hardware to test with, and probably all the people who use that hardware are using enterprise distributions so breakages to the module won't be spotted for a long time. It's hard for the hardware vendor to track these kinds of updates and perform the necessary regression testing.
Did you setup your IPv6 in a similar matter ? how did you set it up ? (im always looking for new ways to do things)
/29 global scope subnet on my end of my DSL) and just turned on 6-to-4 which is very easy under Fedora (you basically just set IPV6TO4INIT=yes in your /etc/sysconfig/network-scripts/ifcfg-eth0 file and it Just Works). The machine runs radvd so the rest of my network gets native v6 connectivity.
My Fedora Core 4 server has a global scope IPv4 address (I have a
If you have a wrt and dd-wrt or one of the linux versions you should look into it. Once it's setup on the router it's easy as one command to setup on your clients.
As I already mentioned, I already use IPv6. My point was that the person who's trying to send a file over IM probably doesn't.