yaworski

Jeszcze jest używany w kilku miejscach w bibliotece standardowej. Np w std::sync::atomic, czy std::cell, czyli w implementacjach struktur, które używane są do interior mutability. Pisząc coś, jeżeli potrzebuję odwołać się przez FFI do jakiejś biblioteki, staram się jednak wydzielić obsługę tej biblioteki do oddzielnego crate'a (wszystkie unsafe mam w jednym miejscu). Dzięki temu w kodzie aplikacji czy biblioteki, którą piszę, nigdy nie używam unsafe bezpośrednio. Crate odpowiedzialny za komunikację z zewnętrzną biblioteką łatwiej przetestować niezależnie od pozostałego kodu. Jeżeli chodzi o Rust, to zacząłem relatywnie niedawno w nim pisać. Wcześniej głównie programowałem w Pythonie, w mniejszym stopniu w C/C++, Lua i Go. Nie wiem, czemu tak długo zwlekałem z nauczeniem się Rusta, bo naprawdę bardzo mi się spodobał. Mam tylko nadzieję, że jego rozwój pójdzie w dobrym kierunku. Trochę rzeczy jeszcze w std brakuje. Sporo jest dostępne tylko w nightly. No ale to w końcu bardzo młody język.

Polecam przeczytać oficjalny manual Rusta. Jest napisany całkiem zwięźle i zrozumiale. W uproszczeniu jest tak jak napisałeś. Dochodzi jeszcze kwestia tzw lifetime, która jest bardzo ważna przy pożyczaniu. Pożyczona referencja nie może mieć dłuższego lifetime'u niż obiekt, z którego pożycza. Właśnie tego pilnuje kompilator. Czasami nawet trzeba mu w tym pomóc (np jeśli funkcja przyjmuje więcej niż jedną referencję jako argumenty i zwraca jakąś referencję, przez zadeklarowanie lifetime'ów tych referencji). Dodatkowo możesz mieć wiele niemutowalnych referencji jednocześnie, ale tylko jedną mutowalną (przy czym nie możesz mieć jednocześnie niemutowalnych). Oprócz tego są pewne ułatwienia w bibliotece standardowej, jak np Rc (reference counter), czy jego wersja thread safe czyli Arc (atomic Rc), które przejmują własność obiektu. Można je klonować, co zwiększa licznik referencji trzymanego obiektu i dropowanie kopii powoduje zmniejszenie licznika. Jak licznik dojdzie do zera, to obiekt też jest dropowany. Są też inne techniki, jak np internal mutability, które trochę obchodzą wewnętrzne zabezpieczenia w sposób w miarę bezpieczny. Obecnie kompilator nie jest jednak w stanie wyłapać błędnego użycia niektórych z tych technik, więc użycie ich jest zalecane tylko jeśli nie da się czegoś zrobić inaczej.

Ale wiemy też, że ta zupa nie była też jednolita. Musiały występować jakieś fluktuacje, co doprowadziło do takiego, a nie innego rozkładu materii we wszechświecie. Jeżeli się mylę, to mnie poprawcie, ale nadal dużym problemem dla nauki jest asymetria w ilości materii i antymaterii po BB. Założenie jest chyba takie, że obecna materia, to jest i tak pozostałość po anihilacji i to co zostało to różnica pomiędzy początkową ilością materii i antymaterii. A jeśli jednak nie cała antymateria anihilowała z materią w początkowym stadium wszechświata i przez fluktuacje w "zupie" oba typy materii podzieliły się na strefy, które potem zaczęły się i tak oddalać od siebie? Przy ciągle powiększającym się i przyspieszającym wszechświecie nie widzielibyśmy wiele zderzeń obiektów zbudowanych z materii i antymaterii. Nie wiem czy Kacper miał mnie tym zniechęcić, czy kogoś innego, ale ja się tak łatwo nie zniechęcam .

Chyba chodziło o pozytron? Już dawno mnie zastanawiało, że skoro teoretycznie właściwości fizyczne antymaterii powinny być identyczne jak materii, to dlaczego np część galaktyk nie mogłaby być zbudowana właśnie z antymaterii? Może podczas big bangu nie cała antymateria anihilowała i oba typy materii oddzieliły się od siebie i część wszechświata jest właśnie zbudowana z antymaterii.

Akurat Tesla nie ma 4 silników. Ma 1 lub 2 w zależności od modelu. W przypadku jednego silnika napęd jest na tylnej osi. Wersje 2-silnikowe są też dwie. Model standard ma z przodu i z tyłu identyczne, mniejsze silniki - mniejsze niż model z 1 silnikiem. Model Performance ma znacznie większy tylny silnik (taki, jak model jednosilnikowy) + mniejszy z przodu. Przy obu silnikach musi być układ różnicowy, który przenosi napęd na koła.

Oryginalny artykuł: http://www.ky3.com/content/news/Self-driving-Tesla-SUV-saves-the-day-389392262.html BBC trochę podkoloryzowało i niestety tutaj wyszedł trochę głuchy telefon. W Tesli nie ma opcji podania celu dla Autopilota. Autopilot Tesli to po prostu bardzo zaawansowany asystent pasa ruchu i zmiany pasa (zmiana wymaga aktywności użytkownika - kierowca musi samemu włączyć kierunkowskaz). W oryginale nawet nie ma mowy o tym, że kierowca wydał polecenie zawiezienia go do szpitala. Kierowca sam wiedział, kiedy musi zjechać z autostrady. Musiał wtedy wyłączyć Autopilota i resztę drogi przejechać samodzielnie. Autopilot nadaje się tylko do jazdy autostradami i drogami szybkiego ruchu.

Osiągnięcie 0,1 c nie oznacza, że sonda dotarłaby do celu w dziesięciokrotność czasu, jaki potrzebuje światło, żeby przebyć taką samą drogę. Trzeba jeszcze wziąć pod uwagę przyspieszenie. Osiągnięcie 0,1 c będzie raczej długotrwałym procesem. Samo przyspieszanie zajmie pewnie co najmniej kilka lat. Jeżeli sonda miałaby też coś tam zbadać i przesłać dane z powrotem, musiałaby też być w stanie zwolnić. A to zajęłoby pewnie co najmniej tyle samo czasu, co przyspieszanie (do początkowego przyspieszenia można wykorzystać technologie o dużo większym ciągu + asysta grawitacyjna w układzie słonecznym co by pozwoliło na uzyskanie jakiejś tam prędkości początkowej przed uruchomieniem nowego typu napędu).

W takich sytuacjach dobrze mieć włączone uwierzytelnianie dwustopniowe. Gdyby nawet dane do konta znalazły się w takim wycieku, to znacznie utrudni lub wręcz uniemożliwi to nieautoryzowany dostęp do konta.

A czy sekwencjonowanie DNA nie wymaga zniszczenia części próbki? W takim wypadku ograniczeniem byłaby liczba odczytów danych z takiego zarchiwizowanego filmu, bo za każdym razem zniszczeniu ulegałaby część próbki z danym filmem. Po jakimś czasie trzeba by było pewnie ją uzupełnić.

Wychodzi na to, że jednak nie uczelnia i Apple nie ma jednak pojęcia jaki był wektor ataku. Nie wiadomo też nic, czy na ten atak są podatne tylko stare wersje systemu, czy aktualne też.

http://kopalniawiedzy.pl/Apple-FBI-terroryzm-San-Bernardino-atak-iPhone,24231 Niedawno pisałem w komentarzu, że to się tak właśnie skończy.

Jeżeli FBI uda się skutecznie zastosować alternatywną metodę, to będą mieli opcję odblokowania każdego iPhone'a. Gdyby Apple się zgodziło pomóc przy tej jednej sprawie, mogliby przekazać FBI oprogramowanie działające jedynie na tym jednym telefonie (w oprogramowaniu mogłoby być zaimplementowane sprawdzenie po Apple ID (czy czego tam iPhone używa do unikalnego identyfikowania siebie) - czyli Apple nadal by miało jako taką kontrolę nad tym. Podejrzewam, że FBI się pewnie nie podzieli z Apple swoją metodą, jeżeli będzie skuteczna, więc Apple nie będzie wiedziało jaki był wektor ataku na ich zabezpieczenia.

Z tego, co czytałem, to FBI nie żąda od Apple odblokowania telefonu jako takiego, a przygotowania wersji systemu, która nie posiada limitu na liczbę prób wprowadzenia pinu/hasła, żeby mogli próbować do skutku - bez tego po kilku nieudanych próbach telefon zostanie zablokowany albo nawet automatycznie się sformatuje, jeżeli były właściciel tak go skonfigurował. Nawet w sytuacji uzyskania takiego oprogramowania dostanie się do telefonu będzie pracochłonne, ktoś lub coś będzie musiało wprowadzać kolejne kombinacje 4-cyfrowego kodu. W sumie Apple mogłoby tak przygotować obraz systemu, żeby był on w stanie zadziałać tylko i wyłącznie na tym jednym telefonie. Nie wiem czy to by wystarczyło, ale żeby ustrzec się przyszłych sytuacji z podobnymi żądaniami w sprawach bardziej błahych i nie tworzyć niebezpiecznego precedensu, sąd mógłby nakazać taką modyfikację z warunkiem, że robi to tylko dlatego, że były właściciel już nie żyje i był terrorystą (czego udowadniać nie trzeba - wiadomo kto strzelał).

Haha od razu mi się przypomniała anty-gmailowa reklama stworzona przez Microsoft: Może Microsoft nie skanuje całej poczty online (kto ich tam wie), ale aktywnie skanują zawartość One Drive na obecność plików niezgodnych z EULA usługi. Nawet pliki, które nie są nigdzie dalej udostępniane.

W oryginalnej wiadomości jest: "Because Arc includes Google Play Services, it’s possible to run many apps on the desktop." Zostało to błędnie zinterpretowane jako: "Zawiera ono m.in. Google Play Services, dzięki czemu możliwe jest jednoczesne uruchomienie wielu aplikacji." Nie chodzi o jednoczesne uruchomienie wielu aplikacji, a o samą możliwość ich uruchomienia w ogóle, ponieważ wiele aplikacji wymaga obecności Google Play Services w systemie.

Cały ten artykuł jest do poprawy. UEFI Secure Boot jest stosowany już od premiery Windows 8. Microsoft wymaga Secure Boot dla Win8/8.1 w wersji OEM (w wersji Box nie jest wymagane). Po wielu protestach środowisk OpenSource Microsoft dodał w wymaganiach UEFI dla Win8 zapis, że użytkownik musi mieć możliwość ręcznego wyłączenia Secure Boot (oczywiście powoduje to, że Windows w wersji OEM preinstalowany na tym sprzęcie przestawał działać do czasu ponownego włączenia SB). Niektórzy producenci dodali również tryb Custom, gdzie użytkownik mógł dodawać dodatkowe klucze. Nowa specyfikacja UEFI dla Win10 przerzuca jednak decyzję odnośnie opcji wyłączenia Secure Boot na producentów sprzętu. Czyli to producent będzie decydował, czy w jego sprzęcie użytkownik będzie mógł wyłączyć SB i zainstalować inny system czy nie. Istnieją jednak obawy, że Microsoft może wprowadzić 2 cenniki systemów OEM: droższy dla producentów, którzy pozostawią opcję wyłączenia SB i tańszy dla tych, którzy ją usuną. Problem nie dotyczy jedynie komputerów stacjonarnych, ale przede wszystkim laptopów. Z komputerami stacjonarnymi problem dotyczy jedynie tych firmowych. Zawsze pozostanie możliwa opcja złożenia swojej konfiguracji i zainstalowania systemu w wersji Box, która Secure Boot nie wymaga. Co do sprzętu mobilnego (telefony, tablety) z Windows 8 (i 10 w przyszłości) to Secure Boot jest na nich wymagany i nie ma możliwości jego wyłączenia.

Oczywiście, że nie wszystkie cechy nowych ras psów są pożądane. Takie krzyżówki nigdy nie będą wystarczająco precyzyjne. Dodatkowo pula genów w takich hodowlach jest zwykle bardzo mała i po uzyskaniu czegoś, co można uznać za nową rasę rozród zaczyna się od bardzo małej populacji, więc wszelkie nieprawidłowości są dziedziczone dalej nawet przez całą powstałą rasę. W przypadku roślin celuje się w konkretnie wybrane geny. Owszem, nadal może się zdarzyć, że wprowadzając jakiś gen, oprócz cech pozytywnych doda się jakieś cechy negatywne, ale takiej odmiany nie wprowadza się przecież od razu do użytku i przeprowadza się masę testów. Barszcz Sosnowskiego nie jest GMO, ale rozumiem powód do niepokoju. Roślina genetycznie zmodyfikowana, żeby była bardziej odporna na niekorzystne warunki może zyskać przewagę nad innymi roślinami w warunkach naturalnych, jeżeli zacznie rosnąć dziko.

Moim zdaniem strach przed GMO jest spowodowany głównie brakiem zrozumienia technologii. Jak zwykle jak ludzie czegoś nie rozumieją to się tego boją. W zasadzie to modyfikacje genetyczne były już stosowane od bardzo dawna - od kiedy ludzie nauczyli się tworzyć krzyżówki różnych gatunków. Dotyczy zarówno roślin, jak i zwierząt - w końcu jak nazwać stworzenie nowej rasy psa przez selektywne krzyżowanie innych raz jak nie modyfikacją genetyczną? GMO to po prostu bardziej precyzyjne włączanie genów jednego gatunku do innego w celu uzyskania pożądanej cechy. Niektórzy ludzie w podobny sposób boją się mikrofalówek. Usłyszą coś o promieniowaniu mikrofalowym i panikują. W ogóle słowo "promieniowanie" samo w sobie już jest powodem do paniki wielu osób .

W pierwszym zdaniu brakuje dwóch przecinków: przed słowem "mózg" oraz po słowie "mięśnie". Bez tych przecinków zdanie nie ma w ogóle sensu. Szkoda, że nie mam National Geographic Channel, bo program brzmi ciekawie.

Chciałem napisać to samo . Bardzo mnie ciekawi, jak wygląda sytuacja w przypadku Paperwhite. W zasadzie jest również oświetlany światłem emitowanym przez LED-y i różni się jedynie tym, że światło się odbija od powierzchni wyświetlacza e-ink zamiast świecić bezpośrednio w oczy. To jednak nie powinno mieć wielkiego wpływu na spektrum światła, które dociera do oczu użytkownika, więc wszystko zależy od zastosowanych LED-ów.

Zwracam honor. Myślałem, że poprawiłeś pogo z "dużą literą" na "wielką literą" i nie sprawdziłem, że chodziło o "z wielkiej litery" .

Sam zawsze również uważałem, że to jest jedyna prawidłowa forma. Jednak niedawno zostałem z tego błędu wyprowadzony. Otóż obie formy (duża i wielka) są poprawne. http://sjp.pwn.pl/poradnia/haslo/;443 Nawet prof. Miodek uważa, że powinno używać się określenia "duża litera": http://www.gazetawroclawska.pl/artykul/704179,jan-miodek-nonsensowne-wielkie-litery,id,t.html (ostatni akapit)

Może warto byłoby dopisać, że aplikacji nie ma w Google Play i wymaga zainstalowania jej z "innych źródeł", które nie są w żaden sposób weryfikowane. Dodatkowo Angry Birds Transformers jeszcze nie miało premiery.

Zgadza się. Nie twierdzę, że problem nie jest realny. Uważam jednak, że jest wyolbrzymiany przez twierdzenie, że każdy komputer i urządzenie, które mają niezałataną wersję basha są podatne na atak, bo tak nie jest. Musi być spełnionych kilka warunków jednocześnie: 1. Podatna na atak wersja basha. 2. Możliwość zdalnego ustawienia zmiennej środowiskowej. 3. Możliwość zdalnego utworzenia instancji basha, która odziedziczy środowisko z wprowadzoną w pkt 2 zmienną środowiskową. Punkty 2 i 3 są spełnione w przypadku wykorzystania skryptów CGI, ale tylko gdy serwer uruchamiający skrypt CGI lub sama aplikacja uruchamiają nową instancję basha. Może się zdarzyć, że urządzenie posiada zainstalowanego basha w podatnej wersji, ale domyślnie korzysta z innego shella jak np zsh, ash czy wbudowana powłoka w BusyBox. Nowsze technologie jak FastCGI nie są już podatne na tego typu atak ponieważ nie tworzą nowej instancji aplikacji przy każdym żądaniu i instancje są tworzone w inny sposób, niezależny od danych z żądania (żądanie zwykle jest przekazywane przez gniazda do działającej już instancji aplikacji).

Takie trochę straszenie. ShellShock jest owszem niebezpieczny, ale nie powoduje automatycznie, że każdy serwer, na którym jest podatna wersja basha jest od razu podatny na ataki zdalne. Taki serwer musiałby mieć chociaż jedną aplikację CGI, a serwer HTTP, który tę aplikację uruchamia musiałby uruchamiać instancję basha przy każdym uruchomieniu skryptu CGI. Na szczęście CGI nie jest już zbytnio popularne, co mocno utrudnia możliwość ataku. Np na serwerach, które mam pod swoją opieką nie mam żadnej aplikacji CGI, która pozwalałaby wykorzystać lukę w bashu.