The only way to make yum upgrade to a newer core version is to
download and install the newer version kernel, reboot into that
kernel, then tell yum to update.
Actually updating has zilch to do with the kernel.
You can normally do an online update by manually updating (with the rpm command) the fedora-release packagae, and then using yum to update from there.
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.
There are normally howtos on upgrading using yum available - Seth Vidal typically has notes in his blogs about doing so.
However the recommended and supported upgrade route is to boot from a the new version installation image, and then use anaconda to upgrade - that can do more invasive updates like the udev changes, which are much easier to do with your system being offline.
> BTW, according to Philip Hazel (a message I > recieved to a question I posed on the Exim mailing > list), Exim 4 will offer much more functionality > along these lines
You must be a debian user.... Exim 4 was released more than 3 years ago, and Exim 3 is really really deprecated (except its still the default for Debian).
Please don't use the old Exim system filter - it was great for its time, but now its part of the problem, not the solution. SMTP time reject is the only way to do spam rejection.
I have found a couple of problems with the current (0.9 & 0.9.1) extensions setup:-
You do not appear to be able to install an extension globally. Hence if (as on my home machine) there are 5 users, you have to install the extensions 5 times. This was not the case with Firefox 0.8
Extensions get disabled on upgrades - this works really nicely with the previous point:-(
Add a bunch of extensions and there is a good chance that Firefox gets itself wedged, puts up a "Finishing installing extension" message for ever, and doesn't work quite right until you delete the profile, install a new one and reinstall all the extensions again
The new stuff looks very nice, but its so damn fragile at the moment. This would really scare off those trying to roll out across an organisation...
So, in order for SPF to work, I need to allow email from my domain, and these ISPs.
SPF (and I guess the MS solution) pretty much requires that email from a particular domain comes from a small number of hosts. Or to put it another way, SPF mandates people roaming into using authenticated SMTP or MSA to send their outgoing email from an appropriate outbound relay.
A few years back I worked for an ISP. A big ISP - in fact the biggest in the UK at that time, and possibly still (how you count AOL is an interesting problem).
Microsoft tried to sell us on their mail systems - cost would have been no object as far as software was concerned since they would bury us in software to do this one fairly simple (but large scale function) because they were desparate to get a big ISP on board their bandwagon.
We looked at the stuff, but walked away. Actually we ran away screaming. We just didn't have enough data centre space to handle the number of boxes it would take to run their unproven messaging system for our userbase of 3 million (and expecting growth) users.
Instead we implemented an open-source based mail system - exim as the MTA, a set of pop servers, an open source radius system for authentication - all the normal stuff. Becuase it was better. Because it worked. Because we could fix it when it broke. Because we knew how it scaled, how to make it scale better. Because it didn't have the possibility of us getting a buttload of licensing additional costs at a later date. Because it was better in every way than the MS option other than having a point-and-drool interface that a monkey could use to completely shaft a million users at a time.
Is it really THAT important to you to get the this the instant it's released? If it has bug fixes you need, surely you could download just those from somewhere already. Why not just wait a few days, and your download speeds will be fine.
I run a mirror. Other people are meant to download from my site. Frankly I don't give a toss about getting the distro on the day - normal policy is to wait 3 weeks until other people knock the bugs out of it and then install an updated version. However as a mirror I am providing a significant service to RH/Fedora/Debian/Mandrake and many other projects which is costing my company a buttload of bandwidth. Pissing me off is not a winning strategy for those making distros.
Red Hat have always had a bit of a reputation for lousing up the release process of a distribution when it comes to getting mirrors ready before the release.
Fedora has taken this to new and astounding heights. I got the notification that Fedora was ready to mirror 31 minutes before the supposed official release time. The download.fedora.redhat.com name wasn't in the DNS. The permissions on the repository prvented us rsyncing, and there were no pre-release torrents in place.
So at release time there were no mirrors and no torrents available. Worse, the mirror list their download page points to are the old Red Hat mirrors which use a different directory heirarchy to the new Fedora tree, so those links are both wrong and to machines that don't have the damn software.
Its now 4.5 hours after release time. I have had a torrent client set running for most of that time (as soon as I got a torrent URL), and the torrents have not completed. The immediate throwing open of the release to the general public means I can't get rsync access to the main site. So my mirror, and I guess many other are not anywhere near synced.
Frankly I'm pissed off and will probably not bother to mirror in future.
SMTP is indeed a simple protocol (ignoring extra complications like DSN support and odd ESMTP additions). If you are designing an SMTP relay then things are nice and simple to secure.
The problem comes that users want their mail delivered to them - into their spool or directory, as their UID. So you need to have some method of changing UID to the destination UID, so you need setuid and suddenly any security hole you have loses you the game.
Sendmail & exim are the one big daemon that runs setuid design - so any security holes gives you real problem. Postfix and qmail have better privaledge separation, so you will tend to lose less if they are broken.
To do this properly you also want to collapse all white space to single spaces or some similar transformation to get around mismatches caused by reindenting or tab/space conversion.
Fortunately that can also be done in a line of perl:-)
Last time I looked BT still use exim. Unfortunately they don't appear to have upgraded in close on 4 years (they certainly have some machines running 2.12).
The Freeserve (or rather Energis Squared - the hosting ISP) mail system was the first in the UK, and probably in Europe, supporting over one million individual mail users. All the mail transport was done with exim on Linux, the mailboxes were on NetApp filers (Maildir structure). It was also one of the first mail systems with substantial anti-spam features (mostly on the outgoing side initially - as a toll free ISP Freeserve got more than its fair share of mail bombing jerks and didn't really want to end up with the reputation of having the most clueless users - that was left for AOL).
That overall system sustained serveral millions of incoming and outgoing mails per day (can't remember the exact figures) over a smallish number of Compaq PII based linux servers. The quantity of mail will not have decreased in the 5 years since that system got going.
The UK has a number of services to aid you in switching your energy supplier - these are often online services such as uswitch or saveonyourbills (and you can find even more at switchwithwhich).
So you get a name and address - can do that from the phone book, or use other means.
You create yourself a throwaway email account - ideally based somewhere that would be a complete pain to req any log data from. Maybe you also ensure theres a little more masking here - like covering up your web access.
Then go to a switch web site, enter the property details you are interested in - don't need the right name at present, just the address (postcode and house number - say SW1A2AA, number 10), and set them up for a new energy supplier - theres basically bugger all checking on this at the early stages.
You will then get from the switch website, or sent by email (thats why you need the throwaway account), confirmation of the details to change your electricity supply to the new supplier, and guess what, this includes the electricity meter reference number....
So there you are, name, address, meter reference, their identity is yours for the taking, without all that dumpster diving stuff. Is this neat or what! Whats more, its going to be very hard to get the meter reference changed.
That said, why DON'T we just package the source tarballs instead of the binaries?
Source doesn't fix the packaging problem - it just moves it around a little. You still have basically the same problem removing, replacing or upgrading a package with a source based package as you do with a binary
The killer of this idea for me is that I produce service systems which are designed for a particular (set of) function(s). Part of the philosophy I use is that the systems have only the software I need on them - which makes them more secure (fewer packages to have security bugs, easier to audit). In the case of service boxes they do not have compilers or tool chains on them - don't need anyone fiddling with stuff, if you need to do fixes those are done on a development machine, moved to a test machine and then deployed. Adding a compiler, and the associated tool chain, and the (development - then run times are probably already there) libraries to make stuff build makes my package set much bigger and consequently increases the maintenance task.
I'll try and give you a little background on this - I actually went along there last Sunday and saw Gaak and his brethering then...
First Magna is a "Science Adventure Centre" housed in what was a Steel works near Sheffield - this place is basically a huge shed filled with strange leftovers from the steel making, with long walkways and 4 exhibition areas inside. The whole place is done with a sort of gothic frankenstein science style - lots of sparks etc.
The living robots part is a new exhibit organised by Dr Noel Starkey (of Sheffield University - best known for being a judge on Robot Wars). There are a total of 12 robots, of 2 basic designs (although they are apparently not completely identical within the types). The two types are predator and prey.
Prey robots look like animated inverted wastebins with solar panels on the top. Their aim in life is to avoid being predated upon and to feed. Feeding involves soaking up energy from the light trees (2 sets of lights on the edge of the arena). I assume that the feeding etc is to demonstrate behaviour in that there is no way they could get enough energy from the solar panels on them to actually run for any length of time. The robots have 8 infra-red sensor/emitters around the shell which put out a type recognition code and detect other emitters in the area - so they can recognise other prey and ignore them, and see preditors before they ge t got.
The preditors, of which Gaak is one, look like some form of fork lift truck. Their role in life is to find prey, grab them and lift them off the ground. They then have an arrangement where a probe enguages with a connector on top of the prey and "sucks some energy" out of the prey. Following this feeding process the preditor releases the prey and then goes torpid for a short time.
The "intelligence" is based on some form of neural network - I didn't get details of this. At the end of each day the data on each robot is downloaded along with the neural net configurations. The 2 most successful predators have their neural nets merged to produce a new "evolved" network which is downloaded to all the predators. Similarly for the prey. Theory is that this produces an evolutionary basis for their behaviour.
I find it hard to be convinced of this process having much real scientific value, and the displays have too little violence for a population that watches Robot Wars:-)
I'll try and give you a little background on this - I actually went along there last Sunday and saw Gaak and his brethering then...
First Magna is a "Science Adventure Centre" housed in what was a Steel works near Sheffield - this place is basically a huge shed filled with strange leftovers from the steel making, with long walkways and 4 exhibition areas inside. The whole place is done with a sort of gothic frankenstein science style - lots of sparks etc.
The living robots part is a new exhibit organised by Dr Noel Starkey (of Sheffield University - best known for being a judge on Robot Wars). There are a total of 12 robots, of 2 basic designs (although they are apparently not completely identical within the types). The two types are predator and prey.
Prey robots look like animated inverted wastebins with solar panels on the top. Their aim in life is to avoid being predated upon and to feed. Feeding involves soaking up energy from the light trees (2 sets of lights on the edge of the arena). I assume that the feeding etc is to demonstrate behaviour in that there is no way they could get enough energy from the solar panels on them to actually run for any length of time. The robots have 8 infra-red sensor/emitters around the shell which put out a type recognition code and detect other emitters in the area - so they can recognise other prey and ignore them, and see preditors before they ge t got.
The preditors, of which Gaak is one, look like some form of fork lift truck. Their role in life is to find prey, grab them and lift them off the ground. They then have an arrangement where a probe enguages with a connector on top of the prey and "sucks some energy" out of the prey. Following this feeding process the preditor releases the prey and then goes torpid for a short time.
The "intelligence" is based on some form of neural network - I didn't get details of this. At the end of each day the data on each robot is downloaded along with the neural net configurations. The 2 most successful predators have their neural nets merged to produce a new "evolved" network which is downloaded to all the predators. Similarly for the prey. Theory is that this produces an evolutionary basis for their behaviour.
I find it hard to be convinced of this process having much real scientific value, and the displays have too little violence for a population that watches Robot Wars:-)
Compaq kit works OK if you use vendor (ie stock RH) kernels. The RAID controllers are well supported in mainline kernels.
However the on-board monitoring requires binary closed source modules which crap all over your kernel if its anything other than RH stock - so if (for example) you want some extra drivers and FreeSWAN then using Compaqs monitoring modules you can crash the machine in 3 seconds purely by cat-ing a few/proc files!
The installer is interesting as well - it "fixes up" the modules to load with the current kernel - forget ABI compatibility - this forces modules into an incompatible kernel and modifies the version stamps so you don't notice.
And compaq's packaging stuff is shit - why does no one have any idea how to make rpms - these do really stupid things. The only worse packager than compaq are ibm who have binary rpms which build new rpms on install!
Basically never trust any vendor that uses ServerWorks chipsets (ie both Compaq and IBM) - the big NDAs surrounding those chipsets will come back and bite you hard!
I know of 4 Servers runnig at my most recent employer that have been running 2.4.x Kernels since they were put into service and have never crashed or even hiccuped - over 2 years ago.
2.4.0 appeared to the world on 4 Jan 2001 - 1 year and 13 days ago. Either this guy has a time machine or he is a not very accomplished liar.
I understand that at least one of the root servers is running an alternative DNS implementation produced as commercial licensed software by Nominum (who also produced and maintain the Bind 9.x implementation under contract to the ISC).
Production boxes using vendor kernels?
on
Kernel 2.4.11 Released
·
· Score: 3, Insightful
I believe the truth is that most people that use Linux in production do not roll their own kernels. They use the vendor supplied kernels. Redhat for example will be releasing a 2.2.7-11-AC kernel which uses Rik's VM, it is what they have been testing for months and thus is what they will end up shipping.
Anyone running a production set worth their salt
will be running their own kernel base, tuned for
their own environment. The vendor kernels are a
compromise, trying to please everyone, with every
service you could ever imagine compiled in (and hence every bug/exploit included). Production boxes doing serious work are more likely to have a kernel set built for the purpose.
Vendor kernels are far more likely to be used by people who are not that bothered about kernels and stability
FWIW my production boxes run a 2.2.19 heavily patched.
> If it was a decent system the passwords would all be encrypted, and it would not allow insecure passwords.
I keep seeing this sort of stuff - presumably refering to hashed passwords rather than encrypted. However there is a problem... if you use APOP or CHAP or similar the server end needs to have plaintext equivalent passwords on its end. Typically this means that the RADIUS servers have the plaintext passwords available. This is problematic - you would prefer to keep passwords hashed, but frankly its normally easier to nail down your RADIUS server than it is to nail down all the networking and other stuff to prevent sniffing of authentication sessions (and CHAP etc prevents those sniffs being useful).
So don't assume plaintext passwords on authentication servers is necessarily a bad thing.
For that matter, questions of anonymity online might be best dealt with by an international commission (for uniformity in dealing with supoened server logs, etc.). Of course, considering how much stricter European privacy laws are, that would be bad news for the FBI. I somehow doubt the USA is likely to listen to the rest of the world, but at the very least we should not let a few vigilantes in Wayne County set our privacy policy.
Readng this as a European and someone who has worked for (even setup) a very large ISP, I am a little amused by this. EU data protection legislation is indeed considerably stricter than US legislation (if indeed there is any US equivalent in most cases). However EU access for the LEAs (Law Enforcement Authorities) is probably considerably more liberal - maybe its just better codified.
Take an example like Freeserve - the largest UK ISP, based mostly on a pay-as-you-go model (ie call charges). To be able to use anything other than the most basic access you must disclose (or specifically not withhold), the telephone number you are calling from (this is passed to the ISPs equipment by the telco unless you specifically configure your equipment to withhold it). All mail (at least all SMTP sessions) is forced through the ISP mail servers and hence logged (this was apparently bought in as an anti-spam measure and is effective in that spam from this ISP is negligable compared to many of the smaller competitors).
The T&Cs and privacy policy mention Freeserve.com reserves the right to access and disclose individually identifiable information to comply with applicable laws and lawful government requests, to operate its systems properly or to protect itself or its users.
So the EU may have stronger data protection, but there is a well defined process that any LEA can request this sort of data about anyone if they can come up with approriate requirements and convince the people who issue the papers to obtain this information. It also appears, for example, that web logs, which are caught by the transparent proxy caches, would also count as traffic data and so be very easy for an LEA to request
Is this a bad thing... I've tended to assume that controlled LEA access to basic data is a norm, and so find it strange when US people go orbital about this, but are quite happy about companies selling the stuff off for money with no controls... I guess its a cultural issue to some extent
Personally, with due process and control I am happy about the EU situation, although the LEAs (especially in the UK), do try and push things too far in their favour
And this does what exactly? What do you expect to see? Do you pattern match for something that looks like a dial up or what.
Step 3. Compare IP address and MX address. If they are not equal, bounce mail.
So you have now found a way of bouncing mail from *every* large ISP around - *no-one* running a decent sized installation uses the same machines for incoming and outgoing mail.
And that comment just shows the real problem - every idiot thinks they know how to run an ISP. Go away and come back when you have sucessfully built a 1 million (or larger) user mail system - I have, and it needs plenty of experience and knowledge (and also some luck).
Slashdot Mirror
Utterly pointless. The botnet spam initiator running on your machine will just automatically sign outgoing mail with your signature.
Actually updating has zilch to do with the kernel. You can normally do an online update by manually updating (with the rpm command) the fedora-release packagae, and then using yum to update from there.
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.
There are normally howtos on upgrading using yum available - Seth Vidal typically has notes in his blogs about doing so.
However the recommended and supported upgrade route is to boot from a the new version installation image, and then use anaconda to upgrade - that can do more invasive updates like the udev changes, which are much easier to do with your system being offline.
> BTW, according to Philip Hazel (a message I
> recieved to a question I posed on the Exim mailing
> list), Exim 4 will offer much more functionality
> along these lines
You must be a debian user.... Exim 4 was released more than 3 years ago, and Exim 3 is really really deprecated (except its still the default for Debian).
Please don't use the old Exim system filter - it was great for its time, but now its part of the problem, not the solution. SMTP time reject is the only way to do spam rejection.
- You do not appear to be able to install an extension globally. Hence if (as on my home machine) there are 5 users, you have to install the extensions 5 times. This was not the case with Firefox 0.8
- Extensions get disabled on upgrades - this works really nicely with the previous point
:-(
- Add a bunch of extensions and there is a good chance that Firefox gets itself wedged, puts up a "Finishing installing extension" message for ever, and doesn't work quite right until you delete the profile, install a new one and reinstall all the extensions again
The new stuff looks very nice, but its so damn fragile at the moment. This would really scare off those trying to roll out across an organisation...I suffer from a degree of RSI.
This is seriously aggravated by multiple small movements - for example double-clicking a mouse button.
Microsoft claim they are solely responsible for the concept of double clicking.
I guess they are just dying to contribute to my medical bills....
So, in order for SPF to work, I need to allow email from my domain, and these ISPs.
SPF (and I guess the MS solution) pretty much requires that email from a particular domain comes from a small number of hosts. Or to put it another way, SPF mandates people roaming into using authenticated SMTP or MSA to send their outgoing email from an appropriate outbound relay.
And you can't forget Booble .
A few years back I worked for an ISP. A big ISP - in fact the biggest in the UK at that time, and possibly still (how you count AOL is an interesting problem).
Microsoft tried to sell us on their mail systems - cost would have been no object as far as software was concerned since they would bury us in software to do this one fairly simple (but large scale function) because they were desparate to get a big ISP on board their bandwagon.
We looked at the stuff, but walked away. Actually we ran away screaming. We just didn't have enough data centre space to handle the number of boxes it would take to run their unproven messaging system for our userbase of 3 million (and expecting growth) users.
Instead we implemented an open-source based mail system - exim as the MTA, a set of pop servers, an open source radius system for authentication - all the normal stuff. Becuase it was better. Because it worked. Because we could fix it when it broke. Because we knew how it scaled, how to make it scale better. Because it didn't have the possibility of us getting a buttload of licensing additional costs at a later date. Because it was better in every way than the MS option other than having a point-and-drool interface that a monkey could use to completely shaft a million users at a time.
Is it really THAT important to you to get the this the instant it's released? If it has bug fixes you need, surely you could download just those from somewhere already. Why not just wait a few days, and your download speeds will be fine.
I run a mirror. Other people are meant to download from my site. Frankly I don't give a toss about getting the distro on the day - normal policy is to wait 3 weeks until other people knock the bugs out of it and then install an updated version. However as a mirror I am providing a significant service to RH/Fedora/Debian/Mandrake and many other projects which is costing my company a buttload of bandwidth. Pissing me off is not a winning strategy for those making distros.
Red Hat have always had a bit of a reputation for lousing up the release process of a distribution when it comes to getting mirrors ready before the release.
Fedora has taken this to new and astounding heights. I got the notification that Fedora was ready to mirror 31 minutes before the supposed official release time. The download.fedora.redhat.com name wasn't in the DNS. The permissions on the repository prvented us rsyncing, and there were no pre-release torrents in place.
So at release time there were no mirrors and no torrents available. Worse, the mirror list their download page points to are the old Red Hat mirrors which use a different directory heirarchy to the new Fedora tree, so those links are both wrong and to machines that don't have the damn software.
Its now 4.5 hours after release time. I have had a torrent client set running for most of that time (as soon as I got a torrent URL), and the torrents have not completed. The immediate throwing open of the release to the general public means I can't get rsync access to the main site. So my mirror, and I guess many other are not anywhere near synced.
Frankly I'm pissed off and will probably not bother to mirror in future.
SMTP is indeed a simple protocol (ignoring extra complications like DSN support and odd ESMTP additions). If you are designing an SMTP relay then things are nice and simple to secure.
The problem comes that users want their mail delivered to them - into their spool or directory, as their UID. So you need to have some method of changing UID to the destination UID, so you need setuid and suddenly any security hole you have loses you the game.
Sendmail & exim are the one big daemon that runs setuid design - so any security holes gives you real problem. Postfix and qmail have better privaledge separation, so you will tend to lose less if they are broken.
To do this properly you also want to collapse all white space to single spaces or some similar transformation to get around mismatches caused by reindenting or tab/space conversion.
:-)
Fortunately that can also be done in a line of perl
Last time I looked BT still use exim.
Unfortunately they don't appear to have upgraded in close on 4 years (they certainly have some machines running 2.12).
The Freeserve (or rather Energis Squared - the hosting ISP) mail system was the first in the UK, and probably in Europe, supporting over one million individual mail users. All the mail transport was done with exim on Linux, the mailboxes were on NetApp filers (Maildir structure). It was also one of the first mail systems with substantial anti-spam features (mostly on the outgoing side initially - as a toll free ISP Freeserve got more than its fair share of mail bombing jerks and didn't really want to end up with the reputation of having the most clueless users - that was left for AOL).
That overall system sustained serveral millions of incoming and outgoing mails per day (can't remember the exact figures) over a smallish number of Compaq PII based linux servers. The quantity of mail will not have decreased in the 5 years since that system got going.
The UK has a number of services to aid you in switching your energy supplier - these are often online services such as uswitch or saveonyourbills (and you can find even more at switchwithwhich).
So you get a name and address - can do that from the phone book, or use other means.
You create yourself a throwaway email account - ideally based somewhere that would be a complete pain to req any log data from. Maybe you also ensure theres a little more masking here - like covering up your web access.
Then go to a switch web site, enter the property details you are interested in - don't need the right name at present, just the address (postcode and house number - say SW1A2AA, number 10), and set them up for a new energy supplier - theres basically bugger all checking on this at the early stages.
You will then get from the switch website, or sent by email (thats why you need the throwaway account), confirmation of the details to change your electricity supply to the new supplier, and guess what, this includes the electricity meter reference number....
So there you are, name, address, meter reference, their identity is yours for the taking, without all that dumpster diving stuff. Is this neat or what! Whats more, its going to be very hard to get the meter reference changed.
That said, why DON'T we just package the source tarballs instead of the binaries?
Source doesn't fix the packaging problem - it just moves it around a little. You still have basically the same problem removing, replacing or upgrading a package with a source based package as you do with a binary
The killer of this idea for me is that I produce service systems which are designed for a particular (set of) function(s). Part of the philosophy I use is that the systems have only the software I need on them - which makes them more secure (fewer packages to have security bugs, easier to audit). In the case of service boxes they do not have compilers or tool chains on them - don't need anyone fiddling with stuff, if you need to do fixes those are done on a development machine, moved to a test machine and then deployed. Adding a compiler, and the associated tool chain, and the (development - then run times are probably already there) libraries to make stuff build makes my package set much bigger and consequently increases the maintenance task.
First Magna is a "Science Adventure Centre" housed in what was a Steel works near Sheffield - this place is basically a huge shed filled with strange leftovers from the steel making, with long walkways and 4 exhibition areas inside. The whole place is done with a sort of gothic frankenstein science style - lots of sparks etc.
The living robots part is a new exhibit organised by Dr Noel Starkey (of Sheffield University - best known for being a judge on Robot Wars). There are a total of 12 robots, of 2 basic designs (although they are apparently not completely identical within the types). The two types are predator and prey.
Prey robots look like animated inverted wastebins with solar panels on the top. Their aim in life is to avoid being predated upon and to feed. Feeding involves soaking up energy from the light trees (2 sets of lights on the edge of the arena). I assume that the feeding etc is to demonstrate behaviour in that there is no way they could get enough energy from the solar panels on them to actually run for any length of time. The robots have 8 infra-red sensor/emitters around the shell which put out a type recognition code and detect other emitters in the area - so they can recognise other prey and ignore them, and see preditors before they ge t got.
The preditors, of which Gaak is one, look like some form of fork lift truck. Their role in life is to find prey, grab them and lift them off the ground. They then have an arrangement where a probe enguages with a connector on top of the prey and "sucks some energy" out of the prey. Following this feeding process the preditor releases the prey and then goes torpid for a short time.
The "intelligence" is based on some form of neural network - I didn't get details of this. At the end of each day the data on each robot is downloaded along with the neural net configurations. The 2 most successful predators have their neural nets merged to produce a new "evolved" network which is downloaded to all the predators. Similarly for the prey. Theory is that this produces an evolutionary basis for their behaviour.
I find it hard to be convinced of this process having much real scientific value, and the displays have too little violence for a population that watches Robot Wars
I'll try and give you a little background on this - I actually went along there last Sunday and saw Gaak and his brethering then... First Magna is a "Science Adventure Centre" housed in what was a Steel works near Sheffield - this place is basically a huge shed filled with strange leftovers from the steel making, with long walkways and 4 exhibition areas inside. The whole place is done with a sort of gothic frankenstein science style - lots of sparks etc. The living robots part is a new exhibit organised by Dr Noel Starkey (of Sheffield University - best known for being a judge on Robot Wars). There are a total of 12 robots, of 2 basic designs (although they are apparently not completely identical within the types). The two types are predator and prey. Prey robots look like animated inverted wastebins with solar panels on the top. Their aim in life is to avoid being predated upon and to feed. Feeding involves soaking up energy from the light trees (2 sets of lights on the edge of the arena). I assume that the feeding etc is to demonstrate behaviour in that there is no way they could get enough energy from the solar panels on them to actually run for any length of time. The robots have 8 infra-red sensor/emitters around the shell which put out a type recognition code and detect other emitters in the area - so they can recognise other prey and ignore them, and see preditors before they ge t got. The preditors, of which Gaak is one, look like some form of fork lift truck. Their role in life is to find prey, grab them and lift them off the ground. They then have an arrangement where a probe enguages with a connector on top of the prey and "sucks some energy" out of the prey. Following this feeding process the preditor releases the prey and then goes torpid for a short time. The "intelligence" is based on some form of neural network - I didn't get details of this. At the end of each day the data on each robot is downloaded along with the neural net configurations. The 2 most successful predators have their neural nets merged to produce a new "evolved" network which is downloaded to all the predators. Similarly for the prey. Theory is that this produces an evolutionary basis for their behaviour. I find it hard to be convinced of this process having much real scientific value, and the displays have too little violence for a population that watches Robot Wars :-)
Compaq kit works OK if you use vendor (ie stock RH) kernels. The RAID controllers are well supported in mainline kernels.
/proc files!
However the on-board monitoring requires binary closed source modules which crap all over your kernel if its anything other than RH stock - so if (for example) you want some extra drivers and FreeSWAN then using Compaqs monitoring modules you can crash the machine in 3 seconds purely by cat-ing a few
The installer is interesting as well - it "fixes up" the modules to load with the current kernel - forget ABI compatibility - this forces modules into an incompatible kernel and modifies the version stamps so you don't notice.
And compaq's packaging stuff is shit - why does no one have any idea how to make rpms - these do really stupid things. The only worse packager than compaq are ibm who have binary rpms which build new rpms on install!
Basically never trust any vendor that uses ServerWorks chipsets (ie both Compaq and IBM) - the big NDAs surrounding those chipsets will come back and bite you hard!
our chips (what the americans call fries, but different) are being patented and chip shops will be charged a per-chip royalty.
Ain't it great the way we get all the good ideas from the colonies...
I know of 4 Servers runnig at my most recent employer that have been running 2.4.x Kernels since they were put into service and have never crashed or even hiccuped - over 2 years ago.
2.4.0 appeared to the world on 4 Jan 2001 - 1 year and 13 days ago. Either this guy has a time machine or he is a not very accomplished liar.
I understand that at least one of the root servers is running an alternative DNS implementation produced as commercial licensed software by Nominum (who also produced and maintain the Bind 9.x implementation under contract to the ISC).
I believe the truth is that most people that use Linux in production do not roll their own kernels. They use the vendor supplied kernels. Redhat for example will be releasing a 2.2.7-11-AC kernel which uses Rik's VM, it is what they have been testing for months and thus is what they will end up shipping.
Anyone running a production set worth their salt will be running their own kernel base, tuned for their own environment. The vendor kernels are a compromise, trying to please everyone, with every service you could ever imagine compiled in (and hence every bug/exploit included). Production boxes doing serious work are more likely to have a kernel set built for the purpose.
Vendor kernels are far more likely to be used by people who are not that bothered about kernels and stability
FWIW my production boxes run a 2.2.19 heavily patched.
> If it was a decent system the passwords would all be encrypted, and it would not allow insecure passwords.
I keep seeing this sort of stuff - presumably refering to hashed passwords rather than encrypted. However there is a problem... if you use APOP or CHAP or similar the server end needs to have plaintext equivalent passwords on its end. Typically this means that the RADIUS servers have the plaintext passwords available. This is problematic - you would prefer to keep passwords hashed, but frankly its normally easier to nail down your RADIUS server than it is to nail down all the networking and other stuff to prevent sniffing of authentication sessions (and CHAP etc prevents those sniffs being useful).
So don't assume plaintext passwords on authentication servers is necessarily a bad thing.
Readng this as a European and someone who has worked for (even setup) a very large ISP, I am a little amused by this. EU data protection legislation is indeed considerably stricter than US legislation (if indeed there is any US equivalent in most cases). However EU access for the LEAs (Law Enforcement Authorities) is probably considerably more liberal - maybe its just better codified.
Take an example like Freeserve - the largest UK ISP, based mostly on a pay-as-you-go model (ie call charges). To be able to use anything other than the most basic access you must disclose (or specifically not withhold), the telephone number you are calling from (this is passed to the ISPs equipment by the telco unless you specifically configure your equipment to withhold it). All mail (at least all SMTP sessions) is forced through the ISP mail servers and hence logged (this was apparently bought in as an anti-spam measure and is effective in that spam from this ISP is negligable compared to many of the smaller competitors).
The T&Cs and privacy policy mention Freeserve.com reserves the right to access and disclose individually identifiable information to comply with applicable laws and lawful government requests, to operate its systems properly or to protect itself or its users.
So the EU may have stronger data protection, but there is a well defined process that any LEA can request this sort of data about anyone if they can come up with approriate requirements and convince the people who issue the papers to obtain this information. It also appears, for example, that web logs, which are caught by the transparent proxy caches, would also count as traffic data and so be very easy for an LEA to request
Is this a bad thing... I've tended to assume that controlled LEA access to basic data is a norm, and so find it strange when US people go orbital about this, but are quite happy about companies selling the stuff off for money with no controls... I guess its a cultural issue to some extent
Personally, with due process and control I am happy about the EU situation, although the LEAs (especially in the UK), do try and push things too far in their favour
And this does what exactly? What do you expect to see? Do you pattern match for something that looks like a dial up or what.
Step 3. Compare IP address and MX address. If they are not equal, bounce mail.So you have now found a way of bouncing mail from *every* large ISP around - *no-one* running a decent sized installation uses the same machines for incoming and outgoing mail.
And that comment just shows the real problem - every idiot thinks they know how to run an ISP. Go away and come back when you have sucessfully built a 1 million (or larger) user mail system - I have, and it needs plenty of experience and knowledge (and also some luck).