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.