Un exemple, tu as une application web qui sert des données sensibles et tu souhaites te protéger au maximum. Tu vas monter un serveur /nginx/Linux et un serveur */Apache/FreeBSD, si un des couples serveur Web/noyau est victime d'une faille de sécurité, tu peux facilement le déconnecter du réseau, attendre la mise à jour de sécurité, mettre à jour et reconnecter sans interrompre ton service Web.
Bien entendu la partie application () sera victime des mêmes failles (à moins que tu aies un psychopathe qui décide, par exemple, de faire une version Perl et un version PHP de l'application ... ça reste possible), mais ta partie serveur Web et noyau est suffisamment hétérogène pour avoir une sécurité "supplémentaire".
Ensuite il y'a débat pour savoir lequel de FreeBSD ou de Linux est plus performant pour le réseau/accès disque/nombre de processus/..., on pourrait imaginer avoir deux serveurs concurrents identiques derrière un proxy. Chaque requête est transmise aux deux serveurs et la requête la plus rapide est servie au client, la plus lente est supprimée. À la fin d'un période de test, on peut aisément déterminer lequel des deux systèmes est le plus adéquat pour le travail en question.
On peut aussi imaginer le cas où tu te retrouves avec du matériel supporté que par l'un (genre tu as plusieurs machines différentes et un de ces machines à du matériel uniquement supporté (ou mieux supporté) par FreeBSD).
Mais sinon si on isole les noyaux, il ne reste plus de différence entre les deux, c'est bien le but du projet.
Comme pour l'administration ça reste une Debian, tu peux beaucoup plus facilement mettre en place ce genre de solutions. Ça reste encore une hypothèse, mais c'est le genre de choses que j'ai imaginé quand j'ai appris le naissance du projet kFreeBSD, mais je n'ai pas encore eu le temps de mettre en pratique mes délires :)
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: linuxo-centré.
Posté par Etienne Bagnoud . En réponse au journal systemd est un "bloat". Évalué à 4.
Un exemple, tu as une application web qui sert des données sensibles et tu souhaites te protéger au maximum. Tu vas monter un serveur /nginx/Linux et un serveur */Apache/FreeBSD, si un des couples serveur Web/noyau est victime d'une faille de sécurité, tu peux facilement le déconnecter du réseau, attendre la mise à jour de sécurité, mettre à jour et reconnecter sans interrompre ton service Web.
Bien entendu la partie application () sera victime des mêmes failles (à moins que tu aies un psychopathe qui décide, par exemple, de faire une version Perl et un version PHP de l'application ... ça reste possible), mais ta partie serveur Web et noyau est suffisamment hétérogène pour avoir une sécurité "supplémentaire".
Ensuite il y'a débat pour savoir lequel de FreeBSD ou de Linux est plus performant pour le réseau/accès disque/nombre de processus/..., on pourrait imaginer avoir deux serveurs concurrents identiques derrière un proxy. Chaque requête est transmise aux deux serveurs et la requête la plus rapide est servie au client, la plus lente est supprimée. À la fin d'un période de test, on peut aisément déterminer lequel des deux systèmes est le plus adéquat pour le travail en question.
On peut aussi imaginer le cas où tu te retrouves avec du matériel supporté que par l'un (genre tu as plusieurs machines différentes et un de ces machines à du matériel uniquement supporté (ou mieux supporté) par FreeBSD).
Mais sinon si on isole les noyaux, il ne reste plus de différence entre les deux, c'est bien le but du projet.
Comme pour l'administration ça reste une Debian, tu peux beaucoup plus facilement mettre en place ce genre de solutions. Ça reste encore une hypothèse, mais c'est le genre de choses que j'ai imaginé quand j'ai appris le naissance du projet kFreeBSD, mais je n'ai pas encore eu le temps de mettre en pratique mes délires :)
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell