Společnost Perplexity AI působící v oblasti umělé inteligence (AI) podala nevyžádanou nabídku na převzetí webového prohlížeče Chrome internetové firmy Google za 34,5 miliardy dolarů (zhruba 723 miliard Kč). Informovala o tom včera agentura Reuters. Upozornila, že výše nabídky výrazně převyšuje hodnotu firmy Perplexity. Společnost Google se podle ní k nabídce zatím nevyjádřila.
Intel vydal 34 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20250812 mikrokódů pro své procesory řešící 6 bezpečnostních chyb.
Byla vydána nová verze 1.25 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
Byla vydána beta verze Linux Mintu 22.2 s kódovým jménem Zara. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze novou XApp aplikaci Fingwit pro autentizaci pomocí otisků prstů nebo vlastní fork knihovny libAdwaita s názvem libAdapta podporující grafická témata. Linux Mint 22.2 bude podporován do roku 2029.
Provozovatel internetové encyklopedie Wikipedie prohrál v Británii soudní spor týkající se některých částí nového zákona o on-line bezpečnosti. Soud ale varoval britského regulátora Ofcom i odpovědné ministerstvo před zaváděním přílišných omezení. Legislativa zpřísňuje požadavky na on-line platformy, ale zároveň čelí kritice za možné omezování svobody slova. Společnost Wikimedia Foundation, která je zodpovědná za fungování
… více »Byla vydána verze 2.0.0 nástroje pro synchronizaci dat mezi vícero počítači bez centrálního serveru Syncthing (Wikipedie). Přehled novinek na GitHubu.
Americký prezident Donald Trump se v pondělí osobně setkal s generálním ředitelem firmy na výrobu čipů Intel Lip-Bu Tanem. Šéfa podniku označil za úspěšného, informují agentury. Ještě před týdnem ho přitom ostře kritizoval a požadoval jeho okamžitý odchod. Akcie Intelu v reakci na schůzku po oficiálním uzavření trhu zpevnily asi o tři procenta.
Byl vydán Debian GNU/Hurd 2025. Jedná se o port Debianu s jádrem Hurd místo obvyklého Linuxu.
V sobotu 9. srpna uplynulo přesně 20 let od oznámení projektu openSUSE na konferenci LinuxWorld v San Franciscu. Pokuď máte archivní nebo nějakým způsobem zajímavé fotky s openSUSE, můžete se o ně s námi podělit.
Byl vydán Debian 13 s kódovým názvem Trixie. Přehled novinek v poznámkách k vydání.
. S tou bezpecnosti (a ted ji nechci podcenovat) by me absence "nekolika firewallu" na databazovem serveru zas az tolik nevadila, protoze od toho jsou firewally na jinych serverech. Tento je ciste databazovy.
22.12.2004 09:27
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
22.12.2004 14:53
SYSMAN | skóre: 24
| blog: SYSMAN
| Veselí nad Moravou
)
sem tam patchujete.. rychlo sa na to zvyka a je to koplexny OS ...- (nie jadro + GNU) (Linuxaci nehnevajte sa na mna..)
Behom jedneho dna si pekne na novy OS zvyknete a budete spokojny.. uvidite.
Povedzme, ze chlapik by si uplne zablokoval akekolvek lokalne prihlasovanie a mal pristup len cez ssh (pri niektorych housingoch je to nutnost), a root by bol premenovany inak (napr. matejko UID 0).A co třeba zakázat přihlášení roota přes ssh, než takovéhle kejkle?
Klišé typu "SuSE (Red Hat, Mandrake) se hodí jen na desktop, na server se nehodí" bytostně nesnáším. Je to totiž naprostý nesmysl. Proč třeba Oracle certifikuje své produkty pro Red Hat a SuSE? Že by byly určeny desktopovým uživatelům? Asi ne. Jistě, SLES se na server určitě hodí více než SuSE x.y Professional a RHEL více než Fedora Core. Jenže důvody, proč tomu tak je, by spolehlivě vyřadily ze hry všechny ostatní alternativy, o kterých tu padla zmínka.
A ještě drobnost: váš příklad s přejmenovaným rootem mi připadá poněkud přitažený za vlasy. Můžete mi sdělit jediný praktický důvod, k čemu by to mělo být dobré? Napadá mne leda "zabezpečování" podle hesla security by obscurity. Chápal bych důvody pro zavedení druhého uživatelského účtu s UID 0, ale tam zase nevidím, v čem by měl být problém. A když už o tom přemýšlím, nenapadá mne ani důvod, proč blokovat lokální přihlášení - natož důvod, proč by to snad měla být nutnost.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
22.12.2004 12:22
su nevidím žádnou velkou výhru. Spíš bych chápal zákaz autentizace heslem (autentizace pouze klíčem) nebo restrikci IP adres klientů.
aspon dufam.. ak nie, tak ma opravte..
Ak bez problemov pouzivate suse na serveroch, tak urcite nie s ich jadrami.. ak ano, tak uzrcite nie na raid1+0 s xfs .. pretoze to sa size da vytvorit aj spravit mkfs, ale pri mount toho raidu s xfs kernel spadne..... je to vyriesene az v 2.6.8 - a to je az v suse 9.2
pokial to date na iny mountpoin ( /usr ) tak to v pohode zozerie.. .. potom mi to potvrdili aj po telefone, ked som volal na support.. (nejaka babenka to tam ma nastarosti)
ad 'security by obscurity' - zmena uzivatela root je jednou zo zakladnych veci, ktore treba urobit v ramci lokalneho aj sietoveho zabezpecenia..
2. Úžasné, vy víte lépe než já, na co mne instalační program upozornil. Netvrdil jsem, že to byla verze 9.1. Ale i z jiných náznaků jsem vyrozuměl, že implementace XFS ještě není úplně stoprocentní a v netypických situacích (jako je třeba právě kombinace se SW RAIDem) mohou nastat problémy.
4. To je docela zvláštní názor. Zajímavé je, že jsem se s ním zatím setkal jen u těch, kteří toho jinak o bezpečnosti moc nevěděli. Naopak ti, kteří byli odborně na výši, se na podobné techniky "zabezpečení" dívali s úsměvem nebo opovržením.
Jinak ta verze Apache toho sama o sobě moc neříká, většina linuxových distribucí updaty provádí v naprosté většině formou backportu oprav (ne upgradem na novou verzi s novými featurami a novými chybami), takže pokud v době release SuSE 9.1 (duben 2004) byla aktuální verze Apache 2.0.49 (což je poměrně pravděpodobné), je tam dodnes a bude tam velmi pravděpodobně už pořád. To ale neznamená, že jsou v ní chyby, které byly opraveny v novějších verzích.
Pokud byste udělal analytický benchmark čistě na výkon procesoru (tj. výpočetně náročný algoritmus pracující na malém kousku paměti), nebude mít při algoritmu, nepoužívajícím 64-bitová data, AMD64 nijak zřetelně navrch. Pokud ale bude algoritmus používat často 64-bitová data, bude rozdíl značný. Jako modelový příklad bych uvedl recenzi na http://www.anandtech.com/linux/showdoc.aspx?i=2213&p=8, zejména dva extrémní případy: v John-the-Ripper MD5 je 64-bitová verze dokonce o něco pomalejší (asi nedoladěná optimalizace), ale u OpenSSL RSA-1024 je výkon 64-bitové verze více než dvojnásobný.
uz neviem co pysem.. je 3:18 rano a o 7:00 vstavam, takze majte sa krasne a so sorry za tie security-obscur.. no sak viete.. .. taz zatial papa.. dobru nocku..
Ale vůbec ne. To, že vám taková konfigurace připadá sexy, vůbec neznamená, že je opravdu nejlepší (nebo dokonce nejoptimálnější). Především tu pracujete s jedním velmi dlouhým souborem (nebo několika málo soubory), takže na filesystému zase až tak nezáleží. Pokud tedy nepotřebujete připadat si jako velký borec, který má slavný XFS (a ReiserFS nebo ext3 jsou pod jeho úroveň), není prakticky žádný důvod, proč si s ním komplikovat život. Tím nechcí říct, že jinde XFS nebude přínosem, ale tady nevidím žádný důvod, proč ho nějak preferovat.
A s RAIDem je to také otázka. Viděl jsem mnoho pojednání na téma použití RAID 1 (mirror) vs. databáze a jediný obecný závěr, který bych si dovolil prohlásit za obecně platný, je ten, že názory se různí. V některých případech totiž při provozování databáze nad RAID 1 docházelo i k dost znatelnému zpomalení. Konkrétně v případě Firebirda je alternativou použití shadow files a také není obecně příliš jasné, která z variant je efektivnější - spíš je to třeba posoudit případ od případu.
Vzhledem k vašim relativně krátkým zkušenostem bych vám doporučoval neprezentovat vlastní názory formou jednoznačně dané pravdy. Zvláště v případě, že nejsou podloženy faktickými argumenty, ale pouze pocity.
XFS vykazuje ve (všech co jsem viděl) benchmarcích lepší výsledky než ostatní FS právě při operacích s velkými soubory a ty rozdíly bývají často markantní, takže bych tento faktor určitě nepodceňoval.
Tiskni
Sdílej:
