right now the ping times don't look too bad (200 ms for crossing the atlantic twice is actually) but I have seen times of double that in the past on freenet6.
The point is for anyone outside north america freenet6 is going to range from poor to terrible and as I said i'm not aware of any other free tunnel providers that work behind nat. And many ISPs don't provide tunnels, don't provide tunnels that will work behind nat or pull stupid shit like only giving out/64's (meaning unless you want to do without the only autoconfiguration system that XP supports you can only have one subnet)
Hm. I wonder what the operational costs of running a free V6-UDP-V4 tunnel broker would be. probablly quite high, especially if you are not a major ISP.
IIRC there are a large number of routers (proper routers, not embedded linux systems that push everything through the CPU) that support IPV6 but only do so in software. Meaning that with a little IPV6 traffic they are fine but if you try and move the bulk of the traffic to V6 they can't cope.
Buisnesses generally already have thier IPs, unless they are rapidly growing the unavailibility of new IPV4 IPs won't effect them much.
And unless they are really huge (there are some cable networks iirc that are too big) they can just use 10.0.0.0/8 for most of thier internal machines with proxies and/or nats providing access to the internet.
The people who will be hit by this are home users who will be placed behind ISP operated nats (most likely with no mechanism for port forwarding) to make way for more lucrative buisness customers.
one big problem is that home nat routers in general don't support acting as the tunnel endpoint and afaict most of the free tunnel services can't be used by a machine that is behind a home nat router.
The one free service I know of that works behind a nat is freenet6 but their service sucks terriblly especially if you are outside the USA.
I think the reason ISPs don't get involved with trying to cache bittorrent is twofold
1: bittorrent is quite awkward to cache unless the client is cooperative. To do it effectively you would have to somehow seperate tracker http traffic from other http traffic and/or seperate tracker wire traffic from other TCP traffic.
2: bittorrent is mostly used for illegal traffic
Also in the UK there is the problem that for ISPs using BT wholesale ADSL (e.g. all but the biggest ISPs) most of the cost of bandwidth is on the BT side not the internet side.
because for some reason they are paraniod about people ripping them despite the fact that the online streams are usually of lower quality than an analog recording made from the TV.
But seriously, why do companies think they can trademark phrases they didn't create? Because they know that sometimes they will get away with it and if they succeed it gives them a nice stick to bully thier competitors with.
Also remember that many of the companies involved are multinationals. That means if they get the trademark in loads of countries even if it is one that wouldn't hold up in court they have a lot of bullying power (see: windows vs lindows).
With Series 60 it's easy to deploy your code That depends on what your code wants to do and where the phone came from.
All apps must be signed. Phones with nokia factory firmware will let you install apps with self signed certs (though finding the docs on how to generate and use them was a PITA) but such apps are limited to a restricted set of "capabilities".
If you need capabilities beyond that or you need to run on more locked down phones then you have to get dev certs for development (IMEI locked) and I can't remember the details of the release signing procedure (I think unless you were a large buisness who they trusted with your own cert you had to send your app to "symbian signed" for aproval and signing)
When I was at 6th form collage in the UK were were allowed such calculators in exams and I belive in theory they were supposed to be reset before the exam but in practice noone ever did.
On the other hand in the department i'm in at uni they restrict students to calculators from a small list of very basic models.
Arm covers a very wide range of processors from microcontrollers with no mmu and very little ram or rom like flash to chips with PCI busses and memory controllers that are capable of running a full linux distro at tollerable speeds.
This chip is firmly at the microcontroller end of the scale. It doesn't have anywhere near enough memory to run linux and I very much doubt it has a mmu either.
your sentance doesn't make much sense but my email address is pretty widely spread now. Mainly from my participation in mailing lists and the debian bugtracker.
there are still arroung 350 rc bugs, the intended release kernel version isn't in testing yet and the installer team haven't produced a release candidate yet.
Given all that I very much doubt they will have the release finished in a month and a half.
Simple physics tells us that bombing it with any bomb we currently have or are likely to have in the forseeable future will make no measurable difference and probablly a lot less difference than the various natural rocks that have hit the moon over the centuries.
In general the desktop install tasks of debian (at least the default gnome one and the kde based one, not sure about the xfce one) do leave a rather bloated install.
If you are at all concerned about disk space it is usually a much better idea to install the base system and then add what you want on top of that yourself.
than to sit staring at pings that have been timing out for the last five minutes (while you think, maybe it's just taking a long time to init... yeah, right!). Often when a linux box hasn't been rebooted for a while it can take a long time to reboot because the boot scripts decide that the filesystems need checking. On a big filesystem this can take quite some time.
Read the readme -- where do I find it? The official instructions for the upgrade including details of known pitfalls will be in the release notes. Afaict the lenny ones haven't been written yet but they should be written and easy to find by the time lenny becomes stable.
Often there are some packages that they advise upgrading first before starting the main upgrade process. and you are likely to have to install the new kernel manually.
If you have a local machine with similar hardware doing a practice upgrade on that first is probablly a good idea.
waiting a while is probablly not a bad idea as the release notes are likely to be updated as new information about possible pitfalls comes in.
If the server does not have a serial console or remote kvm you need to make sure that if something does go wrong someone who knows what they are doing can be got to the server to sort it out. The vast majority of debian upgrades go fine but it pays to be prepared when they don't (say because the new kernel doesn't get on with your hardware).
Obviously test out the software you run on the server under lenny on a test machine before upgrading. Particualarlly if it is something unusual or custom.
If your bootloader has the option to boot a configuration once (I know lilo does and I think grub does) use it so you can fall back to the old kernel with a simple power cycle.
IMO you should always use the release name in your sources.list. There are usually a couple of things that need to be taken care of before upgrading from one release to the next and you need to have time to sort things out if something does go wrong.
debian provides some security update overlap but not all that much. So if you want to continue getting security updates you need to upgrade within about a year.
Slashdot Mirror
right now the ping times don't look too bad (200 ms for crossing the atlantic twice is actually) but I have seen times of double that in the past on freenet6.
The point is for anyone outside north america freenet6 is going to range from poor to terrible and as I said i'm not aware of any other free tunnel providers that work behind nat. And many ISPs don't provide tunnels, don't provide tunnels that will work behind nat or pull stupid shit like only giving out /64's (meaning unless you want to do without the only autoconfiguration system that XP supports you can only have one subnet)
Hm. I wonder what the operational costs of running a free V6-UDP-V4 tunnel broker would be.
probablly quite high, especially if you are not a major ISP.
IIRC there are a large number of routers (proper routers, not embedded linux systems that push everything through the CPU) that support IPV6 but only do so in software. Meaning that with a little IPV6 traffic they are fine but if you try and move the bulk of the traffic to V6 they can't cope.
Buisnesses generally already have thier IPs, unless they are rapidly growing the unavailibility of new IPV4 IPs won't effect them much.
And unless they are really huge (there are some cable networks iirc that are too big) they can just use 10.0.0.0/8 for most of thier internal machines with proxies and/or nats providing access to the internet.
The people who will be hit by this are home users who will be placed behind ISP operated nats (most likely with no mechanism for port forwarding) to make way for more lucrative buisness customers.
one big problem is that home nat routers in general don't support acting as the tunnel endpoint and afaict most of the free tunnel services can't be used by a machine that is behind a home nat router.
The one free service I know of that works behind a nat is freenet6 but their service sucks terriblly especially if you are outside the USA.
there is a replacement for 10.0.0.0/8 btw it is FC00::/7
I think the reason ISPs don't get involved with trying to cache bittorrent is twofold
1: bittorrent is quite awkward to cache unless the client is cooperative. To do it effectively you would have to somehow seperate tracker http traffic from other http traffic and/or seperate tracker wire traffic from other TCP traffic.
2: bittorrent is mostly used for illegal traffic
Also in the UK there is the problem that for ISPs using BT wholesale ADSL (e.g. all but the biggest ISPs) most of the cost of bandwidth is on the BT side not the internet side.
because for some reason they are paraniod about people ripping them despite the fact that the online streams are usually of lower quality than an analog recording made from the TV.
and the fact that china's government is willing and able to do theese things is IMO both very impressive and rather scary.
The satalite stuff seems a little pointless, surely it would be simpler and cheaper to just send one stream over the internet to each ISP.
But seriously, why do companies think they can trademark phrases they didn't create?
Because they know that sometimes they will get away with it and if they succeed it gives them a nice stick to bully thier competitors with.
Also remember that many of the companies involved are multinationals. That means if they get the trademark in loads of countries even if it is one that wouldn't hold up in court they have a lot of bullying power (see: windows vs lindows).
sure but that doesn't solve the second problem which is that the machine that sends the bounce may not be the same machine you sent the mail too.
With Series 60 it's easy to deploy your code
That depends on what your code wants to do and where the phone came from.
All apps must be signed. Phones with nokia factory firmware will let you install apps with self signed certs (though finding the docs on how to generate and use them was a PITA) but such apps are limited to a restricted set of "capabilities".
If you need capabilities beyond that or you need to run on more locked down phones then you have to get dev certs for development (IMEI locked) and I can't remember the details of the release signing procedure (I think unless you were a large buisness who they trusted with your own cert you had to send your app to "symbian signed" for aproval and signing)
When I was at 6th form collage in the UK were were allowed such calculators in exams and I belive in theory they were supposed to be reset before the exam but in practice noone ever did.
On the other hand in the department i'm in at uni they restrict students to calculators from a small list of very basic models.
Arm covers a very wide range of processors from microcontrollers with no mmu and very little ram or rom like flash to chips with PCI busses and memory controllers that are capable of running a full linux distro at tollerable speeds.
This chip is firmly at the microcontroller end of the scale. It doesn't have anywhere near enough memory to run linux and I very much doubt it has a mmu either.
your sentance doesn't make much sense but my email address is pretty widely spread now. Mainly from my participation in mailing lists and the debian bugtracker.
there are still arroung 350 rc bugs, the intended release kernel version isn't in testing yet and the installer team haven't produced a release candidate yet.
Given all that I very much doubt they will have the release finished in a month and a half.
Simple physics tells us that bombing it with any bomb we currently have or are likely to have in the forseeable future will make no measurable difference and probablly a lot less difference than the various natural rocks that have hit the moon over the centuries.
and you will block quite a few legit bounces too for two reasons
1: 12 hours is nowhere near long enough
2: the message may be routed through multiple servers before finally getting bounced.
I use greylisting, it reduced spam to almost zero for a while but then it gradually climbed back to previous levels and more.
In general the desktop install tasks of debian (at least the default gnome one and the kde based one, not sure about the xfce one) do leave a rather bloated install.
If you are at all concerned about disk space it is usually a much better idea to install the base system and then add what you want on top of that yourself.
than to sit staring at pings that have been timing out for the last five minutes (while you think, maybe it's just taking a long time to init... yeah, right!).
Often when a linux box hasn't been rebooted for a while it can take a long time to reboot because the boot scripts decide that the filesystems need checking. On a big filesystem this can take quite some time.
Read the readme -- where do I find it?
The official instructions for the upgrade including details of known pitfalls will be in the release notes. Afaict the lenny ones haven't been written yet but they should be written and easy to find by the time lenny becomes stable.
Often there are some packages that they advise upgrading first before starting the main upgrade process. and you are likely to have to install the new kernel manually.
If you have a local machine with similar hardware doing a practice upgrade on that first is probablly a good idea.
waiting a while is probablly not a bad idea as the release notes are likely to be updated as new information about possible pitfalls comes in.
If the server does not have a serial console or remote kvm you need to make sure that if something does go wrong someone who knows what they are doing can be got to the server to sort it out. The vast majority of debian upgrades go fine but it pays to be prepared when they don't (say because the new kernel doesn't get on with your hardware).
Obviously test out the software you run on the server under lenny on a test machine before upgrading. Particualarlly if it is something unusual or custom.
If your bootloader has the option to boot a configuration once (I know lilo does and I think grub does) use it so you can fall back to the old kernel with a simple power cycle.
IMO you should always use the release name in your sources.list. There are usually a couple of things that need to be taken care of before upgrading from one release to the next and you need to have time to sort things out if something does go wrong.
debian provides some security update overlap but not all that much. So if you want to continue getting security updates you need to upgrade within about a year.
IMO yhe plastic tab IS a key. It sounds like your real problem is a shitty card made with shitty connectors that broke almost immediately.