Linus Torvalds geeft Linux 3.7-kernel vrij
Linus Torvalds heeft versie 3.7 van de Linux-kernel vrijgegeven. De kernel bevat onder andere verbeterde ondersteuning voor een breder aantal ARM-processors inclusief support voor 64bit-ARMv8-processors. Ook kan er network address translation toegepast worden op ipv6-verkeer.
Een belangrijke verbetering in de 3.7-kernel voor met name serverbouwers en -beheerders is de ondersteuning voor AArch64, de 64bit-ARM-architectuur. De eerste processors met AArch64-support zijn in aantocht in de vorm van Cortex A53- en A57-processorontwerpen volgens de ARMv8-architectuur. In combinatie met de 3.7-kernel kunnen de 64bit-mogelijkheden worden gebruikt. Zo kan er meer werkgeheugen worden aangesproken, een must voor servers die worden uitgerust met energiezuinige ARM-cpu's. Overigens ondersteunt de 3.7-kernel ook een groter aantal 32bit-ARM-chipontwerpen ten opzichte van oudere kernels.
De verse Linux-kernel biedt ook ondersteuning voor smap, ofwel supervisor mode access prevention. Via smap kunnen delen van het geheugen beschermd worden. De beveiligingstechniek is afkomstig van Intel en zal zijn terug te vinden in Haswell-processors.
Linux-kernel 3.7 poogt ook de energiezuinige functies van hardware beter te benutten, bijvoorbeeld door de besparingsfeatures van hd audio-chips efficiënter in- en uit- te schakelen. Verder zijn er opnieuw verbeteringen doorgevoerd in het nog altijd niet voltooide btrfs-bestandssysteem en in de netwerk-stack is network address translation mogelijk op ipv6-verbindingen. Hoewel nat door het grote aantal ipv6-adressen in eerste instantie niet direct noodzakelijk lijkt, kan het voor ipv4 breed gebruikte mechanisme wel gebruikt worden om achterliggende netwerken te maskeren voor de buitenwereld.
Reacties (71)
Mooi om te zien dat er weer verbetering is toegevoegd, vooral de 64-bit ARM ondersteuning zal prettig zijn voor gebruikers daarvan.
Wat ik me af vraag, de nummering gaat weer redelijk snel, zullen we weer hetzelfde verhaaltje krijgen als met 2.x waardoor ze uiteindelijk op 3.0 overgestapt waren? Wie weet toevallig hoe/wanneer de huidige nummering naar 4.0 springt?
Wat ik me af vraag, de nummering gaat weer redelijk snel, zullen we weer hetzelfde verhaaltje krijgen als met 2.x waardoor ze uiteindelijk op 3.0 overgestapt waren? Wie weet toevallig hoe/wanneer de huidige nummering naar 4.0 springt?
Versie 2.6 ging tot 39, dus dat duurt nog wel even. Daarbij krijgen we dan waarschijnlijk eerst weer een versie 3.2.x, 3.4.x etc.
Edit: Wat is er nou weer offtopic aan mijn reactie dan?
Edit: Wat is er nou weer offtopic aan mijn reactie dan?
[Reactie gewijzigd door ClementL op 11 december 2012 19:45]
Versie 3.2.x en 3.3.x zijn bugfixes van 3.2 en 3.3, die nummers zullen nooit gebruikt worden voor nieuwe kernels. (het zou sowieso maar raar zijn, van 3.24 ofzo naar 3.2.1?)
Waarschijnlijk als Linus weer stemmen in zijn hoofd hoort die hem vertellen dat er een 4.0 moet komen 
Maar serieus.. dat was serieus, alleen linux bepaald dat, en de vorige keer was het redelijk ad-hoc met 'we gaan nu naar 3.0 over'. Dus ik verwacht dat ergens rond 3.40 we wel weer naar 4.0 overgaan (3.33 is natuurlijk ook een mooie laatste)
Maar serieus.. dat was serieus, alleen linux bepaald dat, en de vorige keer was het redelijk ad-hoc met 'we gaan nu naar 3.0 over'. Dus ik verwacht dat ergens rond 3.40 we wel weer naar 4.0 overgaan (3.33 is natuurlijk ook een mooie laatste
)
Persoonlijk vond ik deze overstap dan ook echt nergens op slaan. Of begin met een nieuwe methode om te tellen, of ga pas op 3.0 over als er echt wat mee is om op een nieuw getal over te gaan. Maar goed, zolang de kernel blijft werken hebben we natuurlijk weinig te klagen over welk getal er bij hangt.
Met de Linux kernel heb je de vrijheid om deze te forken en een eigen nummering aan toe toe voegen die je zelf logisch vind! 
Ze zijn toch met een nieuwe methode om te tellen begonnen ipv. 2.6.x is het 3.x, aangezien de test versie 2.5.x er toch uit ging zijn ze bij 3.x begonnen.
Of nog beter, vanaf versie 3.14 het versienummer π laten benaderen, zoals Donald Knuth doet met TeX.Dus ik verwacht dat ergens rond 3.40 we wel weer naar 4.0 overgaan (3.33 is natuurlijk ook een mooie laatste )
Kernel versie 3 was gekozen omdat Linux de 3e decennia in ging. Zo random was het niet.
Er zijn nog helemaal geen ARMv8 chips, laat staan apparaten.
Er is wel al een ARMv8 / Aarch64 emulator / simulator. Zie http://www.cnx-software.c...nux-on-armv8-fast-models/ voor een instructie.
Ik heb daarmee al Linux-voor-Aarch64 gedraaid op mijn Ubuntu. Grappig.
Ik heb daarmee al Linux-voor-Aarch64 gedraaid op mijn Ubuntu. Grappig.
zonder kernel gedraaid dus?
Waarom dat? Een CPU kan vandaag perfect gevirtualiseerd worden. qemu doet het al jaren. Als je op surfert zijn pagina kijkt dan zie je dat er een uitlezing gedaan word van /proc/cpuinfo en dat er een AArch64 CPU gerapporteerd word.
De "final" 3.7 build is nu vrij gegeven, maar er waren al een aantal Release Candidates. Bijvoorbeeld: http://www.h-online.com/o...able-kernels-1761731.html
Nummer drie kwam er vooral wegens de 20e verjaardag van de linux-kernel..
Ik dacht vooral om één digit te kunnen schrappen:
Achter 2.6.36 werden sub-nummers geplaatst (door mensen die eigen trees bijhielden?), en had je 2.6.36.17. Teveel nummers.
Dus daarom over naar 3.0. Communiceert makkelijker.
En Linus heeft dat juist plots-klaps gedaan om te voorkomen dat mensen 3.0 als iets heftigs gingen zien en er tegenaan ging hikken of juist allemaal dingen erin gingen hengelen.
Achter 2.6.36 werden sub-nummers geplaatst (door mensen die eigen trees bijhielden?), en had je 2.6.36.17. Teveel nummers.
Dus daarom over naar 3.0. Communiceert makkelijker.
En Linus heeft dat juist plots-klaps gedaan om te voorkomen dat mensen 3.0 als iets heftigs gingen zien en er tegenaan ging hikken of juist allemaal dingen erin gingen hengelen.
De jump naar 3.0 was omdat ze in het derde decennium van linux aanbeland waren of zoiets. Hele vage reden iig.
Mooi dat de nieuwe releases snel achter elkaar komen, er word veel werk verricht.
Voor degene die Ubuntu gebruikt kan hier de 3.7 mainline kernel vinden: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-raring/
Voor degene die Ubuntu gebruikt kan hier de 3.7 mainline kernel vinden: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-raring/
Eigenlijk gebeurd het even snel als vroeger, maar volgens de oude telling zou 3.7 eigenlijk 3.0.7 zijn geweest.
Het lijkt door de nieuwe vernummering idd sneller te gaan, maar heb ook het idee dat er meer gewerkt word aan de linux kernel.
ARMv8 support is leuk voor de toekomst, maar die chips zijn er nog niet. Veel interessanter (tenminste, voor de liefhebbers van heel, heel erg snelle servers) is de introductie in 3.7 van ondersteuning voor de SPARC architectuur, dit opent de deur voor Oracle om uit het ivoren Solaris torentje te stappen en de concurrentie aan te gaan met x86 servers in de (heel grote) Linux server markt.
Edit: ja de SPARC T4, maar das ook logisch, met T3 machines ga je anno 2012 geen deuk meer in een pakje boter slaan. Volgende (relatief kleine) stap is dan support op Oracle Enterprise Linux en ondersteuning voor de T5 en M4, en dan gaan we echt eens zien of de miljarden van Larry een beetje peper in de reet van het oude Sun SPARC team hebben kunnen steken. Zou wel eens goed zijn, een beetje concurrentie voor Intel.
Edit: ja de SPARC T4, maar das ook logisch, met T3 machines ga je anno 2012 geen deuk meer in een pakje boter slaan.
Volgende (relatief kleine) stap is dan support op Oracle Enterprise Linux en ondersteuning voor de T5 en M4, en dan gaan we echt eens zien of de miljarden van Larry een beetje peper in de reet van het oude Sun SPARC team hebben kunnen steken. Zou wel eens goed zijn, een beetje concurrentie voor Intel.
[Reactie gewijzigd door Dreamvoid op 11 december 2012 20:37]
Ondersteuning voor de SPARC-T4 bedoel je danVeel interessanter (tenminste, voor de liefhebbers van heel, heel erg snelle servers) is de introductie in 3.7 van ondersteuning voor de SPARC architectuur, dit opent de deur voor Oracle om uit het ivoren Solaris torentje te stappen en de concurrentie aan te gaan met x86 servers in de (heel grote) Linux server markt.
Oudere SPARC modellen werden natuurlijk al lang ondersteund!
Dacht dat de sparc architectuur al een tijdje ondersteund werd ? Altands wel voor de UltraSparc reeks .ARMv8 support is leuk voor de toekomst, maar die chips zijn er nog niet. Veel interessanter (tenminste, voor de liefhebbers van heel, heel erg snelle servers) is de introductie in 3.7 van ondersteuning voor de SPARC architectuur, dit opent de deur voor Oracle om uit het ivoren Solaris torentje te stappen en de concurrentie aan te gaan met x86 servers in de (heel grote) Linux server markt.
SPARC zat al in versie 1.2, uit 1995. Best wel een tijdje dus
Gatver, NAT terug met IPv6. Doe dat nu niet. NAT-oplossingen zijn vies, ranzig en smerig tegelijk.
Dat is jouw mening. Ik persoonlijk ben er dol op om redenen die in de OP staan.
Wat voor voordeel biedt NAT boven een goed geconfigureerde firewall?
Dat je vanbuiten niet kunt zien hoeveel apparaten er binnen zijn aangesloten. Kan bijvoorbeeld interessant zijn als je met je mobiel wilt tetheren terwijl je provider daar niet blij mee is.
NAT mag dan wel geen ideale oplossing zijn, maar het is broodnodig, wil je meerdere computers in een lokaal netwerk beheren met één uitgaand IP adres. Ook is erg veel firewall-technologie op NAT gebaseerd.
Ik vind de reactie een beetje onzinnig, dat er een mogelijkheid voor NAT-support is, is erg handig voor vele toepassingen. Het is volgens mij zelfs essentiëel voor brede invoer van het systeem. Natuurlijk zijn er gevallen waarbij NAT irritant is, en het hosten van dingen bemoeilijkt, maar dat zegt niet dat NAT slecht is, dat zegt dat NAT soms niet gebruikersvriendelijk gebruikt wordt.
Ik vind de reactie een beetje onzinnig, dat er een mogelijkheid voor NAT-support is, is erg handig voor vele toepassingen. Het is volgens mij zelfs essentiëel voor brede invoer van het systeem. Natuurlijk zijn er gevallen waarbij NAT irritant is, en het hosten van dingen bemoeilijkt, maar dat zegt niet dat NAT slecht is, dat zegt dat NAT soms niet gebruikersvriendelijk gebruikt wordt.
Juist die situatie zal in ipv6 niet voorkomen, omdat eindgebruikers per rfc meerdere subnetten toegewezen dienen te krijgen. Oorspronkelijk was de eis zelfs 2^80 adressen per gebruiker, maar dan heeft men afgezwakt naar meerdere subnetten. Een subnet is 2^64 adressen dus je kunt prima meerdere computers in je netwerk hebben.wil je meerdere computers in een lokaal netwerk beheren met één uitgaand IP adres
Desondanks is het een goede zaak dat ipv6 nat krijgt. Ik voorzie toch nog situatie waar gebruikers ondanks alles met 1 ip-adres zitten opgescheept (DHCP-servertje die er maar 1 uitdeelt of zo) en bovendien zit NAT zo diep geworteld in het netwerkdenken van mensen dat ze zich onthand voelen als ze geen NAT meer hebben. Ofwel gebrek aan NAT is een reden voor mensen om niet naar ipv6 over te stappen en dat is een slechte zaak.
NAT is gewoon handig in bepaalde situaties. Aan het overstappen naar IPV6 gaat nog goed geld verdient worden, dat wordt een spektakel denk ik.
Zoveel computers zijn er niet op de wereld!Een subnet is 2^64 adressen dus je kunt prima meerdere computers in je netwerk hebben.
en 640 kB is ook meer dan genoeg.
Ik dacht hetzelfde. Toen IPv4 ontwikkeld werd hadden ze ook nooit gedacht dat er schaarste zou ontstaan, maar tegenwoordig is alles aangesloten op het internet. Je mobieltje,, je televisie, je tablet, je PC.
Straks je magnetron, koffiezetapparaat, je bankstel, je tafel, je koelkast, je douche, je bril enz, enz. en het is natuurlijk wel zo handig als je alles op afstand wilt kunnen bedienen en dan zit NAT toch maar in de weg.
Noem al je apparaten, meubels etc op waar internet handig zou zijn dan kom je al verekte snel op 30+ devices.
Ik denk dat het rap zal gaan met die adressen hoewel je met IPv6 waarschijnlijk wel genoeg adressen zult hebben tot de aarde vergaat, maar er is ook vast wel weer een wereld na IPv6, met nog meer verbeteringen dus ook IPv8 zal vast wel een keer komen.
Er is zijn zelfs al concepten hiervoor maar dan gaat het niet meer om de adres space maar om andere verbeteringen.
http://www.ipv6area.com/2011/12/what-is-ipv8.html
Straks je magnetron, koffiezetapparaat, je bankstel, je tafel, je koelkast, je douche, je bril enz, enz. en het is natuurlijk wel zo handig als je alles op afstand wilt kunnen bedienen en dan zit NAT toch maar in de weg.
Noem al je apparaten, meubels etc op waar internet handig zou zijn dan kom je al verekte snel op 30+ devices.
Ik denk dat het rap zal gaan met die adressen hoewel je met IPv6 waarschijnlijk wel genoeg adressen zult hebben tot de aarde vergaat, maar er is ook vast wel weer een wereld na IPv6, met nog meer verbeteringen dus ook IPv8 zal vast wel een keer komen.
Er is zijn zelfs al concepten hiervoor maar dan gaat het niet meer om de adres space maar om andere verbeteringen.
http://www.ipv6area.com/2011/12/what-is-ipv8.html
Ik zie IPv6 nooit zonder adresruimte vallen. Dat men over een halve eeuw met iets nieuws komt is mogelijk, maar dan zal men toch echt andere noodzaken hebben voor de invoering ervan.
Stel je even voor dat jouw inschatting te laag is en iedereen gemiddeld 100 network enabled apparaten heeft en dat in de industrie nog eens een gelijk aantal machines in dienst zijn, dan zitten we op 1400 miljard network enabled apparaten. Hoeveel IPv6 adressen zijn er? 340,282,366,920,938,000,000,000,000,000 miljard adressen. neem er daar 1400 vanaf en je hebt in essentie nog niets verbruikt.
Stel je even voor dat jouw inschatting te laag is en iedereen gemiddeld 100 network enabled apparaten heeft en dat in de industrie nog eens een gelijk aantal machines in dienst zijn, dan zitten we op 1400 miljard network enabled apparaten. Hoeveel IPv6 adressen zijn er? 340,282,366,920,938,000,000,000,000,000 miljard adressen. neem er daar 1400 vanaf en je hebt in essentie nog niets verbruikt.
Het gaat er vooral om hoe efficient je die ruimte alloceert. We dachten ook ooit dat IPv4 niet op kon, en er werden kwistig gigantische ranges uitgedeeld aan bedrijven en instellingen. Daardoor hebben we nu te weinig vrije adresruimte. Nu gaat in feite hetzelfde gebeuren, door te eisen dat elke eindgebruiker meerdere blokken van 2^64 adressen tot zijn beschikking krijgt. Waar is dat goed voor? Is voor een normale eindgebruiker 2^16 als standaard niet ruim voldoende? Daar kan je nog steeds 65k apparaten een eigen IP mee geven...
Je onderschat hoe groot IPv6 is. Als we iedere wereldbewoner een paar honderd /64 blokken geven dan gebruiken we nog (veel) minder dan 1% van de beschikbare ruimte. Ik geloof niet dat deze adressen ooit nog op gaan.
Ik zie wel een probleem ontstaan met versnippering. Onze routers hebben nu al grote problemen doordat er zo ontzettend veel aparte netwerken moeten worden bijgehouden. In theorie kan IPv6 dat versimpelen maar in praktijk lijkt het alleen maar erger te worden.
Ik zie wel een probleem ontstaan met versnippering. Onze routers hebben nu al grote problemen doordat er zo ontzettend veel aparte netwerken moeten worden bijgehouden. In theorie kan IPv6 dat versimpelen maar in praktijk lijkt het alleen maar erger te worden.
Om te beginnen wil je MAC-based adres toewijzing mogelijk maken. Een MAC adres zelf is 48 bits. Neem dan nog 16 bits extra voor prive-subnetten en je zi aan de 64. Ja, je zou ook 8 bits kunnen toewijzen voor subnetten, maar dat maakt niet significant uit.
straks zijn en krijgen we als klant zo veel ip adressen, dat je ze nooit meer op kan maken. Dat lijkt me dus geen motivatie. inderdaad voor IPv4 is het op het moment broodnodig maar voor IPv6 totaal onnodig.
Ik vind NAT-IPv6 wel interessant, tenminste als ik er dit mee kan doen:
<mijn-IPv6-prefix><gateway-systeem><RFC1918-IPv4-adres-op-mijn-LAN>
Ik kan dan vanaf Internet rechtstreeks mijn IPv4-only systemen (zoals mijn HDX1000, Xbox, PS3, etc) benaderen. Handig.
<mijn-IPv6-prefix><gateway-systeem><RFC1918-IPv4-adres-op-mijn-LAN>
Ik kan dan vanaf Internet rechtstreeks mijn IPv4-only systemen (zoals mijn HDX1000, Xbox, PS3, etc) benaderen. Handig.
als het goed is beheer je je eigen ip6blok. Dus dat kan.
Dat kun je prima doen maar daar heb je geen NAT voor nodig.
Inderdaad, gadver NAT-oplossingen zijn vies, ranzig en smerig. Maar tegelijk ook bijzonder nuttig! Het is namelijk ook inzetbaar:
Eigenlijk denk ik ook dat als dit er niet had gekomen, dat Linux buitenspel was komen te staan. M'n allereerste Linux-servertje zette ik in 1998 neer omdat het op netwerkgebied kon wat windows niet kon. Zonder een volledige netwerk toolkit had Linux fans en firmwareontwikkelaars ingeleverd aan het eerstvolgende OS wat het wel kan.
- voor transparante proxying/virusscanning (dnat)
- om een dienst tijdelijk naar een andere server te verhuizen zonder tegen DNS-TTL aan te lopen (dnat+snat)
- om load-balancing uit te voeren (dnat)
- om de interne netwerkstructuur te verbergen (snat)
- [vul maar in]
Eigenlijk denk ik ook dat als dit er niet had gekomen, dat Linux buitenspel was komen te staan. M'n allereerste Linux-servertje zette ik in 1998 neer omdat het op netwerkgebied kon wat windows niet kon. Zonder een volledige netwerk toolkit had Linux fans en firmwareontwikkelaars ingeleverd aan het eerstvolgende OS wat het wel kan.
Dus jij zou een heel datacenter open en bloot aan het internet hangen voor iedereen?
Ja je kan beargumenteren dat je met een goede firewall(s) je servers kan beschermen, maar dan zou je dat op iedere server moeten implementeren wat een hoop resources kost.
Daarbij zoals al gezegt is kan je dus je servers afschermen van de rest van het internet, niemand hoeft namelijk te weten welke servers er allemaal in je datacenter draaien. NAT is niet echt als security feature bedoeld maar bied wel enige bescherming tegen de buitenwereld. Daarnaast kan je dus nog steeds een firewall draaien.
Voor een thuis netwerk zie ik dit zeker als voordeel, ik zou persoonlijk zelf nooit een computer direct aan het internet hangen. Daarbij nog dat de meeste "firewalls" die je in huis tuin en keuken routers ziet zijn niks meer dan een stukje software wat poorten dicht houd en zo het gros van alle hackers buiten houd, maar doet geen package inspection dus inbreken is nog steeds mogelijk.
Ja je kan beargumenteren dat je met een goede firewall(s) je servers kan beschermen, maar dan zou je dat op iedere server moeten implementeren wat een hoop resources kost.
Daarbij zoals al gezegt is kan je dus je servers afschermen van de rest van het internet, niemand hoeft namelijk te weten welke servers er allemaal in je datacenter draaien. NAT is niet echt als security feature bedoeld maar bied wel enige bescherming tegen de buitenwereld. Daarnaast kan je dus nog steeds een firewall draaien.
Voor een thuis netwerk zie ik dit zeker als voordeel, ik zou persoonlijk zelf nooit een computer direct aan het internet hangen. Daarbij nog dat de meeste "firewalls" die je in huis tuin en keuken routers ziet zijn niks meer dan een stukje software wat poorten dicht houd en zo het gros van alle hackers buiten houd, maar doet geen package inspection dus inbreken is nog steeds mogelijk.
Even los van het hele NAT-argument (waar ik persoonlijk ook een voorstander van ben), maar dit slaat natuurlijk nergens op. Omdat iedereen zijn eigen externe IP heeft, heeft iedere machine ook zijn eigen firewall nodig? Totale onzin. Zo'n firewall hang je gewoon direct achter de gateway (die je nog steeds hebt, of denk je dat iedere PC zijn eigen fysieke lijntje naar de buitenwereld heeft?)maar dan zou je dat op iedere server moeten implementeren wat een hoop resources kost.
Ja. In fact, al mijn servers in het datacenter zijn al full IPv6.
Een standaard ip6tables configuratie op basis van "deny all" en daarna poort-voor-poort toestaan kost nauwelijks resources noch tijd om te implementeren.
Ten tweede, als je een wat groter netwerk hebt en je wilt dat van buiten vandaan wat beter beschermen, dan doe je dat toch met een hardware-firewall. En of je dat nou een nat-doos hebt of een hardware-firewall, dat maakt voor de complexiteit totaal niet uit.
Wanneer het echt om heel vertrouwelijke data gaat, moet je apparatuur per definitie niet aan het internet hangen, ook niet via NAT. De generatie van het gebruikte IP protocol maakt hierin niet zoveel uit.
Ten eerste moet je toch altijd een firewall op elk apparaat plaatsen, want zélfs apparaten in je "vertrouwde" netwerk kunnen wel eens geinfecteerd zijn. Zeker als je hosting voor klanten doet (IAAS/PAAS) moet je er maar niet teveel vanuit gaan dat de buur-host friendly is. Dat moet nu met IPv4 ook al, dus feitelijk verandert daar weinig aan.Ja je kan beargumenteren dat je met een goede firewall(s) je servers kan beschermen, maar dan zou je dat op iedere server moeten implementeren wat een hoop resources kost.
Een standaard ip6tables configuratie op basis van "deny all" en daarna poort-voor-poort toestaan kost nauwelijks resources noch tijd om te implementeren.
Ten tweede, als je een wat groter netwerk hebt en je wilt dat van buiten vandaan wat beter beschermen, dan doe je dat toch met een hardware-firewall. En of je dat nou een nat-doos hebt of een hardware-firewall, dat maakt voor de complexiteit totaal niet uit.
Wanneer het echt om heel vertrouwelijke data gaat, moet je apparatuur per definitie niet aan het internet hangen, ook niet via NAT. De generatie van het gebruikte IP protocol maakt hierin niet zoveel uit.
inderdaad zeg, het ontgaat me totaal waarom Torvalds dit nu weer doet...
Torvalds schrijft dit niet, hij merged alleen maar. Grote kans dat dit van een routerfabrikant komt.
Goh en iedere ADSL, kabel en glasvezel router gebruikt NAT om het interne en externe netwerk te scheiden. Het is een eenvoudige methode om je interne netwerk onbereikbaar van buitenaf te maken. Gelukkig heeft IPv6 ook een interne (private) address range die als het goed is niet via internet gerouteerd wordt: http://en.wikipedia.org/w...rk#Private_IPv6_addresses
Nee, dat zie je verkeerd. Iedere ADSL en kabelrouter gebruikt NAT om te besparen op IP-adressen. Beveiliging is een leuke bijkomstigheid maar geen hoofddoel. Eindgebruikers denken dat misschien, maar de providers zien dat niet als hun probleem.
Helaas, ook het btrfs-bestandssysteem heeft net als ZFS nog geen ''Online Capacity Expansion'' en ''Online Raid Level Migration'' functionaliteit, zie niet echt een reden om over te stappen zonder dat.
Waarom hebben de beste bestandssysteem systemen geen ''Online Capacity Expansion'' functie?
Waarom hebben de beste bestandssysteem systemen geen ''Online Capacity Expansion'' functie?
Omdat dat lastig te implementeren is? Maar als je een goede patch indient, zit het vast in 3.8
ExtX kan gewoon online geresized worden hoor. Gewoon fdisk starten, partitie weggooien en opnieuw aanmaken op hetzelfde startblok, devblock -rereadpt aanroepen en daarna afmaken met resize2fs.
Dat je Ext kan resizen weet ik wel, maar Ext3 en 4 hebben ook hun beperkingen zo.
ZFS kun je gewoon online laten groeien door er vdevs bij te voegen of je disks te vervangen door grotere disks. Online Raid level migration gaat op een bepaalde manier met ZFS: vdevs vervangen door vdevs die bestaan uit disks in je gewenste raid level.
Je kunt wel geen RAIDZ omtoveren tot een triple mirror oid, maar waarom zou je zoiets willen doen? Het enige dat het doet is complexiteit en dus potentiële bugs toevoegen.
Je kunt wel geen RAIDZ omtoveren tot een triple mirror oid, maar waarom zou je zoiets willen doen? Het enige dat het doet is complexiteit en dus potentiële bugs toevoegen.
Nee, je kan niet net als bij raid 5 en 6 even zeggen, hier is een extra HDD, neem die op in je array.
Bij ZFS kan je niet even een extra HDD toevoegen met fout controle, dat moet altijd met minimaal twee of meerdere HDDs gebeuren, met het verlies van extra parity check schijf.
ZFS en BtrFS zijn wat dat betreft heel oneconomisch.
Bij ZFS kan je niet even een extra HDD toevoegen met fout controle, dat moet altijd met minimaal twee of meerdere HDDs gebeuren, met het verlies van extra parity check schijf.
ZFS en BtrFS zijn wat dat betreft heel oneconomisch.
Inderdaad, je kunt geen extra disks aan je RAIDZ of RAIDZ2 toevoegen, maar dat zou gewoon een hel zijn als je dat wilt implementeren ZFS, ZFS is altijd consistent op je schijf. Op geen enkel moment mag een stroomuitval, crash, ... er voor zorgen dat je pool inconsistent is. RAID5 en 6 kunnen dit niet eens als je niet bezig bent met schijven toe te voegen (zoek maar eens op google naar "raid write hole").
Je kunt wel bijvoorbeeld een vdev van 3 schijven in RAIDZ toevoegen aan je al bestaande pool die ook bestaat uit 3 schijven in RAIDZ. Je pool zal dan bestaan uit 2 raidz vdevs in raid0 (andere combinaties zijn natuurlijk ook mogelijk, maar meestal niet gewenst).
Je kunt wel bijvoorbeeld een vdev van 3 schijven in RAIDZ toevoegen aan je al bestaande pool die ook bestaat uit 3 schijven in RAIDZ. Je pool zal dan bestaan uit 2 raidz vdevs in raid0 (andere combinaties zijn natuurlijk ook mogelijk, maar meestal niet gewenst).
Een grotere reden tegen BTRFS is geen Raid 5+, dus dan heb je aan die expansion ook niet veel.
ZFS is al vrij perfect, maar die online expansion mist inderdaad nog, tenzij je een nieuwe vdev er naast hangt. Dat kan dan weer wel (maar is niet wat je wilt als kleine gebruiker).
ZFS is al vrij perfect, maar die online expansion mist inderdaad nog, tenzij je een nieuwe vdev er naast hangt. Dat kan dan weer wel (maar is niet wat je wilt als kleine gebruiker).
Uhm dit kan in ieder geval allemaal on-line
#!/bin/bash
deviceadd="/dev/sdb"
mountpoint="/"
# Create a filesystem across drive 2 (metadata mirrored, data striped)(defaults)
mkfs.btrfs $deviceadd
btrfs device add $deviceadd $mountpoint
btrfs filesystem balance $mountpoint
Je kan dus partities toevoegen en wissen on-line. Komt eigenlijk op het zelfde neer, al is het met een omweg.
#!/bin/bash
deviceadd="/dev/sdb"
mountpoint="/"
# Create a filesystem across drive 2 (metadata mirrored, data striped)(defaults)
mkfs.btrfs $deviceadd
btrfs device add $deviceadd $mountpoint
btrfs filesystem balance $mountpoint
Je kan dus partities toevoegen en wissen on-line. Komt eigenlijk op het zelfde neer, al is het met een omweg.
Wtf wtf
Een gigantisch voordeel van ipv6 is dat elk apparaat zijn eigen IP kan krijgen, nooit meer gezeik met routers en NAT enzo. Alles lekker verbinden met switches en dan wordt deze feature toch toegevoegd, waarom?en in de netwerk-stack is network address translation mogelijk op ipv6-verbindingen
Je kunt het zo ook zien: Doordat elk apparaat een eigen IP address heeft:
1. Moet er op elk apparaat met eigen IP address een goede firewall staan, want de firewall van de router is niet meer. Er wordt dus 1 barricade weggehaald.
2. Je activiteiten zijn beter te tracken. Waar organisatie X enkel ongewenste activiteiten 'vond' bij 1 gezin, blijkt het bij IPv6 het zoontje van 12 jaar te zijn.
1. Moet er op elk apparaat met eigen IP address een goede firewall staan, want de firewall van de router is niet meer. Er wordt dus 1 barricade weggehaald.
2. Je activiteiten zijn beter te tracken. Waar organisatie X enkel ongewenste activiteiten 'vond' bij 1 gezin, blijkt het bij IPv6 het zoontje van 12 jaar te zijn.
1. De router heeft nog steeds een firewall.. nu ook voor ipv6. Dat hoeft echt niet per apparaat.
2. Daar zijn ipv6 privacy extensions voor uitgevonden.
2. Daar zijn ipv6 privacy extensions voor uitgevonden.
Ad 1. En residential gateway kan ook in een situatie waar geen NAT toegepast wordt nog steeds dezelfde packets filteren dat ie nu doet, het vereist natuurlijk wel een andere configuratie. Een prima modus zou zijn zoals het nu met UPnP Gateway aansturing gaat, packets worden gefilterd tenzij er via UPnP een open poort wordt gevraagd.
De beveiliging van clients is met of zonder NAT even belangrijk, aangezien een belangrijke vector nog steeds niet door firewalls wordt gevangen, namelijk verkeer dat vanaf de client wordt geïnitieerd.
De beveiliging van clients is met of zonder NAT even belangrijk, aangezien een belangrijke vector nog steeds niet door firewalls wordt gevangen, namelijk verkeer dat vanaf de client wordt geïnitieerd.
1 gaat niet op natuurlijk. Als er straks IPv6 gebruikt wordt betekent dat niet dat er op eens N internetpijpen naar je huis lopen, waarbij N het aantal apparaten in je huis is wat verbinding met internet maakt.
Je zult dus nog steeds een modem / router of iets in die trant houden, waar al het verkeer doorheen moet. Deze kan natuurlijk zonder filtering alles doorsturen naar het betreffende IP-adres, maar de standaard instelling van consumenten PC's zal natuurlijk een set instellingen ongeveer gelijk zijn aan wat je nu al met NAT ziet: uitgaand verkeer nagenoeg ongeblokkeerd, maar inkomend verkeer wordt standaard afgewezen, tenzij het een ACK of een respons is op een verzonden pakketje. Met andere woorden: de router kan (en zal) nog steeds voor firewall spelen, het enige wat hij niet meer hoeft de doen is de adressen vertalen.
Punt 2 is wel waar, echter wordt op veel besturingssystemen bij het gebruik van IPv6 al gerouleerd met het IP-adres uit een flinke set, een implementatie van RFC 4941, bedoeld om dit probleem te verhelpen.
Je zult dus nog steeds een modem / router of iets in die trant houden, waar al het verkeer doorheen moet. Deze kan natuurlijk zonder filtering alles doorsturen naar het betreffende IP-adres, maar de standaard instelling van consumenten PC's zal natuurlijk een set instellingen ongeveer gelijk zijn aan wat je nu al met NAT ziet: uitgaand verkeer nagenoeg ongeblokkeerd, maar inkomend verkeer wordt standaard afgewezen, tenzij het een ACK of een respons is op een verzonden pakketje. Met andere woorden: de router kan (en zal) nog steeds voor firewall spelen, het enige wat hij niet meer hoeft de doen is de adressen vertalen.
Punt 2 is wel waar, echter wordt op veel besturingssystemen bij het gebruik van IPv6 al gerouleerd met het IP-adres uit een flinke set, een implementatie van RFC 4941, bedoeld om dit probleem te verhelpen.
Routers zal je altijd nodig hebben. Je verkeer zal toch gerouteerd moeten worden.
De reden waarom men NAT zou willen toepassen op IPv6 ontgaat mij ook even.
De reden waarom men NAT zou willen toepassen op IPv6 ontgaat mij ook even.
Ik kan zo een aantal redenen bedenken waar NAT ook bij ipv6 nog een uitkomst kan zijn:
- Er is een router enkele hops verderop die jou interne subnet niet heeft opgenomen in zijn routing tabel en deze kan om wat voor reden dan ook niet door jou aangepast worden
- Je wilt je interne subnets niet bekend maken aan de buitenwereld.
Ik vind het verder wel een flinke voorruitgang om straks grotendeels van NAT te zijn verlost. Scheelt ook een hoop applicatie problemen
- Er is een router enkele hops verderop die jou interne subnet niet heeft opgenomen in zijn routing tabel en deze kan om wat voor reden dan ook niet door jou aangepast worden
- Je wilt je interne subnets niet bekend maken aan de buitenwereld.
Ik vind het verder wel een flinke voorruitgang om straks grotendeels van NAT te zijn verlost. Scheelt ook een hoop applicatie problemen
Heb deze kernel geinstalleerd onder ubuntu 12.10, merk inderdaad dat hij iets langer werkt op een accu lading.
Ben erg benieuwd naar 3.8, die zou echt grote verbetering m.b.t. energie verbruik gaan leveren.
Ben erg benieuwd naar 3.8, die zou echt grote verbetering m.b.t. energie verbruik gaan leveren.
Ik ben erg blij met de ondersteuning voor TRIM voor verschillende RAID-niveau's.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Apple Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
