Portál AbcLinuxu, 7. května 2025 19:53
Pak je obecně interpretace taková, že ndiswrapper je část celku, kde druhou částí celku je binární ovladač
Řekl bych, že tohle byste u soudu obhajoval velmi těžko i s velmi zručným právníkem. Jestliže je ndiswrapper vytvořen autorem AA pro platformu PA, licencován licencí LA a distribuován kanálem CA, zatímco příslušný driver je vytvořen autorem AB pro platformu PB, licencován licencí LB a šířen kanálem CB (zcela nezávisle na ndiswrapperu), pak považovat jejich potenciální kombinaci (která vznikne až v počítači uživatele na základě jeho osobního rozhodnutí a jeho akce) za "celek" podléhající licenci LA, mi připadá hodně přitažené za vlasy.
no ona na tom asi nebude AMD-ATI lépe
fglrx
, ale to už je teď minulostí - byla to špatná volba, ale tenkrát jiný NTB se "solidní" GK nebyl r300
a jsem spokojen. To k čemu potřebuji 3D akceleraci běží a když pomůžu vývoji tohoto ovladače, tak mě to bude jen a jen těšit.
Tebe snad někdo či něco nutí mít a používat právě takovou grafickou nebo bezdrátovou kartu? Je to otázka priorit.Ekonomické faktory nejsou dostatečným tlakem? A co třeba výkon u grafických karet? Někde se dá najít alternativa relativně snadněji, třeba u zmíněných grafických karet o možnosti nahrazení zatím nevím.
No pak je právě otázka, jestli by bylo víc lidí, kteří by si pro elektrárnu bez zplodin, iPod bez DRM a cigarety bez kouře byli ochotni "svinit kernel binárním svinstvem" než těch, kteří by byli radši svinili ŽP, používali drm a kouřili ostatním pod nosem. Jak by hodnotil obě alternativy na příslověčnách vahách?Tuhle konstrukci jsem nějak nepochopil. Já jsem chtěl tím příměrem pouze poukázat na to, že se to odvíjí jen od toho, jak moc člověku na daném principu záleží. Když si někdo chce koupit hardware, který bude fungovat se svobodnými ovladači, není to problém.
Při zachování všech legislativních a licenčních požadavků ale spotřebitel používat proprietární ovladače můžeJá reagoval pouze na zmínku o nedostupnusti určitého hardwaru. Co se týče ostatních věcí diskutovaných v tomto vlákně, tak tam se přikláním spíše k tomu, co je řečeno už v článku: zakazovat natahování ndiswrapperu je nesmysl, protože NDIS ovladače nelze ani omylem považovat za odvozeniny jádra. Takže z hlediska GPL je vše v pořádku.
Ekonomický faktor? To by mě zajímalo, co člověka _nutí_ si kupovat takový hardware. U výkonu grafických karet je to stejné. Když někdo tvrdí, že _musí_ mít kartu s určitým výkonem, tak IMHO zapomíná, že např. hraní her není žádná nutnost. Jen záliba.Tebe snad někdo či něco nutí mít a používat právě takovou grafickou nebo bezdrátovou kartu? Je to otázka priorit.Ekonomické faktory nejsou dostatečným tlakem? A co třeba výkon u grafických karet? Někde se dá najít alternativa relativně snadněji, třeba u zmíněných grafických karet o možnosti nahrazení zatím nevím.
hardware se zrovna u notebooku ovlivňuje docela špatně - hlavně vzhledem k rozpočtu
3D používám třeba ve VariCADu a to moc hraní není
Já chtěl poukázat na to, že jak wifi@5GHz tak elektrárny bez zplodin můžou být pro některé (nebudu si vymýšlet čísla) důležitější než čistota kernelu i když to pak nejde pouze s gpl ovladači. Nenapsal jsem to ale vůbec jasně a hlavní z mého pohledu je, že se v otázce NDISwrapperu shodujeme. O vztahu nutnosti a záliby zde myslím nemá cenu debatovat. Určitě ne u překladu LKML.No pak je právě otázka, jestli by bylo víc lidí, kteří by si pro elektrárnu bez zplodin, iPod bez DRM a cigarety bez kouře byli ochotni "svinit kernel binárním svinstvem" než těch, kteří by byli radši svinili ŽP, používali drm a kouřili ostatním pod nosem. Jak by hodnotil obě alternativy na příslověčnách vahách?Tuhle konstrukci jsem nějak nepochopil. Já jsem chtěl tím příměrem pouze poukázat na to, že se to odvíjí jen od toho, jak moc člověku na daném principu záleží. Když si někdo chce koupit hardware, který bude fungovat se svobodnými ovladači, není to problém.
Linux vdaci za svoje rozsirenie a "kvalitu" a mnozstvo vyvojarov prave GPL.
Máte toto tvrzení něčím podloženo? Proč konkrétně tvrdíte, že Linux za své rozšíření a vývojářskou základnu vděčí zrovna GPL? Osobně si myslím, že to bylo spíš tím, že se objevil v nejvhodnější možné době, která jeho modelu vývoje nahrávala.
objevil v nejvhodnější možné době, která jeho modelu vývoje nahrávala.On ten "model vývoje" do značné míry vychází právě z použité licence, ne?
big-endian (nejdůležitější bajt první)Spíš by se hodilo nejvýznamnější.
Důkazem budiž skutečnost, že Evgeniy Polyakov přišel s novou verzí,...V jaderných novinách z 31.5.2006 je jméno Evgenij Poljakov. Možná by bylo dobré to nějak sjednotit.
V jaderných novinách z 31.5.2006 je jméno Evgenij Poljakov.Dík za upozornění.
Ja som za kazde efektivnejsie/rychlejsie/viac super riesenie, ale co sa tyka toho userspace network stacku, vie mi niekto vysvetlit, ako to moze byt az o tolko rychlejsie?Dobrá otázka. Přesně tu samou si položili nejchytřejší linuxoví síťoví vývojáři taky a jejich odpověď je, že by nemělo. A pokud skutečně je, je možné upravit stack v kernelu tak, aby už nebylo. A nebo je tam zrada někde jinde (jako že se zdá, že je, viz dále). To je právě důvod, proč jsou síťové kanály (po počátečním nadšení) nyní přijímány už jen vlažně. Konkrétně se zdá, že kernelová implementace není tak rychlá, jak by teoreticky mohla být, protože nefilter. Linux má totiž velmi chytré možnosti nastavení filtrování (někteří si myslí, že až příliš). Pokud je odbouráme, to to pofrčí! Vy chcete mít ale kernel bez podpory iptables?
Dalsia vec - ked je ten stack nejaka kniznica, ako sa da ochranit proti zneuzitiu?Nijak. Máte prý používat SSL či obdobné technologie.
Ja som za kazde efektivnejsie/rychlejsie/viac super riesenie, ale co sa tyka toho userspace network stacku, vie mi niekto vysvetlit, ako to moze byt az o tolko rychlejsie?Dobrá otázka. Přesně tu samou si položili nejchytřejší linuxoví síťoví vývojáři taky a jejich odpověď je, že by nemělo.
Jenze je tu jedna vec, ktera bude vzdy vadit: prepinani kontextu. To je tak osklive draha operace, ze se vyplati zustat v kernel space.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.