Skocz do zawartości
Forum Kopalni Wiedzy

Rekomendowane odpowiedzi

Gavin Thomas, który w Microsofcie sprawuje funkcję Principal Security Engineering Manager, zasugerował, że ze względów bezpieczeństwa czas porzucić języki C i C++. Thomas argumentuje na blogu Microsoftu, że rezygnacja ze starszych języków na rzecz języków bardziej nowoczesnych pozwoli na wyeliminowanie całej klasy błędów bezpieczeństwa.

Od 2004 roku każdy błąd naprawiony w oprogramowaniu Microsoftu jest przez nas przypisywany do jednej z kategorii. Matt Miller podczas konferencji Blue Hat w 2019 roku zauważył, że większość tych dziur powstaje wskutek działań programistów, którzy przypadkowo wprowadzają do kodu C i C++ błędy związane z zarządzeniem pamięcią. Problem narasta w miarę jak Microsoft tworzy coraz więcej kodu i coraz silniej zwraca się w stronę oprogramowania Open Source. A Microsoft nie jest jedyną firmą, która ma problemy z błędami związanymi  z zarządzaniem pamięcią, pisze Thomas.

W dalszej części swojego wpisu menedżer wymienia liczne zalety C++, ale zauważa, że język ten ma już swoje lata i pod względem bezpieczeństwa czy metod odstaje od nowszych języków. Zamiast wydawać kolejne zalecenia i tworzyć narzędzia do walki z błędami, powinniśmy skupić się przede wszystkim na tym, by programiści nie wprowadzali błędów do kodu, czytamy.

Dlatego też Thomas proponuje porzucenie C++. Jednym z najbardziej obiecujących nowych języków programistycznych zapewniających bezpieczeństwo jest Rust, opracowany oryginalnie przez Mozillę. Jeśli przemysł programistyczny chce dbać o bezpieczeństwo, powinien skupić się na rozwijaniu narzędzi dla developerów, a nie zajmować się tymi wszystkimi pobocznymi sprawami, ideologią czy przestarzałymi metodami i sposobami rozwiązywania problemów.


« powrót do artykułu

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Pytanie dla programistów (głównie), może ktoś się orientuje, na czym polega ta specyfika Rusta jeśli chodzi o zarządzanie pamięcią (w porównaniu np. z Java/C#)? Nie udało mi się znaleźć w necie żadnego krótkiego omówienia, z tego co zrozumiałem, kompilator śledzi przynależność obiektów tworzonych dynamicznie na stercie do zmiennych, na etapie kompilacji jest rozstrzygane, kiedy zwolnić pamięć, możliwe są dwa rodzaje takich jakby referencji do obiektu na stercie, jedna to "na własność" (czyli, gdy zmienna trzymająca "na własność" jakiś kawałek pamięci przestaje być potrzebny, to ta pamięć jest zwalniana), drugi to referencja "pożyczająca od właściciela", która pozwala odwoływać się do obiektu nie zwalniając pamięci (czyli gdy np. jakaś funkcja "pożyczy" sobie obiekt, to może wykonać na nim jakieś  manipulacje, np. odczytać wartość pola, ale nie może zwrócić obiektu jako wynik, a poza tym, tak długo jak obiekt jest "pożyczony" funkcji, żaden kod spoza tej funkcji nie może na nim wykonywać żadnych operacji i to też jest sprawdzane przez kompilator)? I nic więcej (np. żadnych innych rodzajów referencji)?

Czy dobrze zrozumiałem?

P.S. Chyba jednak czegoś nie zrozumiałem, bo przychodzi mi do głowy, że przy takiej interpretacji nie ma przeszkód, żeby kilku "pożyczkobiorców" mogło "pożyczyć" naraz ten sam obiekt od "właściciela", jedyne ograniczenie, że "właściciel" nie może zwolnić pamięci obiektu dopóki ktoś go "pożycza".

Edytowane przez darekp

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

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.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Pozwolę sobie zacytować:

Cytat

Rust has all the low-level things you would expect but with restrictions on how they are used. If you really need to go native then you can code using, say, raw pointers, but you have to mark the code as unsafe. In principle, if you don't write any unsafe code, or if you write unsafe code correctly, it is claimed that Rust avoids all of the race hazards inherent in other languages.

Can this be true?

The researchers looked at code in GitHub to find out how Rust is used and what sort of errors actually occurred. The first observation was that there are a lot of unsafe tags. Ironically it is Mozilla's Servo project that used unsafe most often. It seems that Rust is restrictive enough to force developers to turn to unsafe code to get the job done.

Źródło: https://www.i-programmer.info/news/98-languages/12552-is-rust-really-safe.html

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
52 minuty temu, pskosinski napisał:

The researchers looked at code in GitHub to find out how Rust is used and what sort of errors actually occurred. The first observation was that there are a lot of unsafe tags. Ironically it is Mozilla's Servo project that used unsafe most often. It seems that Rust is restrictive enough to force developers to turn to unsafe code to get the job done. 

Trzeba mieć na uwadze, że unsafe jest wymagane do wywołania funkcji zewnętrznych (nie napisanych w języku Rust) przez FFI. Servo korzysta z wielu komponentów napisanych w C++ jak np. silnik JavaScript z Gecko. Stąd nie dziwi mnie, że w tym projekcie często sięgają do bloków `unsafe`.

Dla porównania, w repozytorium Libry ( https://github.com/libra/libra ) na 145 tys. linii kodu blok `unsafe` jest użyty 6 razy.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
30 minut temu, beczek napisał:

Trzeba mieć na uwadze, że unsafe jest wymagane do wywołania funkcji zewnętrznych (nie napisanych w języku Rust) przez FFI. Servo korzysta z wielu komponentów napisanych w C++ jak np. silnik JavaScript z Gecko. Stąd nie dziwi mnie, że w tym projekcie często sięgają do bloków `unsafe`.

Dla porównania, w repozytorium Libry ( https://github.com/libra/libra ) na 145 tys. linii kodu blok `unsafe` jest użyty 6 razy.

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.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
18 godzin temu, KopalniaWiedzy.pl napisał:

rezygnacja ze starszych języków na rzecz języków bardziej nowoczesnych pozwoli na wyeliminowanie całej klasy błędów bezpieczeństwa

Tylko, że te błędy to nie wina technologii, tylko czynnika ludzkiego. Od czego dziesiątki lat rozwoju analizatorów kodu, by nie „strzelić sobie w stopę”.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
W dniu 23.07.2019 o 04:46, wilk napisał:

Od czego dziesiątki lat rozwoju analizatorów kodu, by nie „strzelić sobie w stopę”.

Te analizatory kodu nie są tak dobre, jak mogłoby się wydawać. Wygląda na to, że zamiast zaawansowanych analizatorów nieraz lepiej działają proste narzędzia, które "przeskakują" większość analizowanego kodu i wyszukują tylko pewne charakterystyczne konstrukcje w kodzie z dużym prawdopodobieństwem będące błędami: http://lambda-the-ultimate.org/node/5348 (np. odwołanie do x.pole występujące przed sprawdzeniem czy x != null).

Pierwsza myśl może być taka, że jeśli zrobić potężny parser, który bardzo dokładnie przeanalizuje kod programu i wygeneruje dla niego wielkie drzewo z bardzo dużą ilością informacji o szczegółach działania (tak robią duże firmy piszące analizatory), to da się przeprowadzić bardziej dokładną analizę i znaleźć więcej błędów. Ale napisać funkcję, która chodzi po takim wielgachnym drzewie z mnóstwem atrybutów i znajduje błędy to jest "mordęga".

Z drugiej strony, ta sytuacja jest w pewnym sensie "fajna", bo wychodzi na to, że - jeśli chodzi o języki programowania, analizatory kodu itp. - pojedynczy programista (albo niewielki zespół) może konkurować z wielkimi koncernami. I tak chyba jest w praktyce - języki programowania to w większości dzieło pojedynczych ludzi (jeden język -> jeden autor, Lua to chyba wyjątek, jakiś większy zespół z jakiegoś katolickiego uniwersytetu w Brazylii, ale nie jestem pewien), firma JetBrains, która tworzy IDE takie jak IntelliJ, PyCharm, ReSharper, jest o wiele mniejsza od Microsoftu czy Google :) Trzeba "tylko" być zdolnym programistą;)

 

P.S. Zapomniałem napisać, ale jest jest język programowania, który tak dokładnie sprawdza kod na etapie kompilacji, że w praktyce niemal nie występują błędy runtime'u. To Elm (https://elm-lang.org/). Co prawda tylko dla frontendu na przeglądarce (i chyba trudno sobie wyobrazić pisanie np. systemu operacyjnego w ten sposób), ale z drugiej strony chyba fajna sprawa (dopiero się go uczę, nie maiłem okazji jeszcze wykorzystać w praktyce) :)

Edytowane przez darekp

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się

  • Podobna zawartość

    • przez KopalniaWiedzy.pl
      Od lat 70. XX wieku wykonywane są testy zderzeniowe z wykorzystaniem manekinów. Służą one do oceny efektywności systemów zabezpieczeń, ogólnego bezpieczeństwa pojazdu czy ryzyk związanych z różnymi rodzajami wypadków. Problem jednak w tym, że najczęściej używany manekin bazuje na średniej budowie i wadze ciała mężczyzny.
      Tymczasem kobiety równie często jeżdżą samochodami i są bardziej narażone na odniesienie obrażeń. Używane w testach manekiny, mające odpowiadać kobietom, to po prostu przeskalowane do wzrostu 12-latki manekiny męskie. Mają one 149 cm wzrostu i ważą 48 kg. Już w połowie lat 70. taka waga i wzrost reprezentowały zaledwie 5% najdrobniejszych kobiet.
      Szwedzcy specjaliści pracują nad manekinem bardziej reprezentatywnym dla kobiecej budowy ciała. Ma on 162 cm wzrostu i waży 62 kg. Powstanie manekina bardziej reprezentatywnego dla przeciętnej kobiety jest niezwykle ważne. Z danych amerykańskiej Narodowej Rady Bezpieczeństwa Transportu Drogowego wynika na przykład, że przy uderzeniach z tyłu kobiety 3-krotnie częściej niż mężczyźni odnoszą obrażenia kręgosłupa szyjnego. Co prawda rzadko są one śmiertelne, ale mogą prowadzić do trwałego kalectwa.
      "Ze statystyk wiemy, że przy zderzeniach z niewielką prędkością, kobiety częściej odnoszą obrażenia. Dlatego też, jeśli chcemy sprawdzić, jakie zabezpieczenia najlepiej chronią ludzi, musimy uwzględnić tę część populacji, która jest bardziej narażona na zranienie", mówi Astrid Linder, dyrektor ds. bezpieczeństwa ruchu w Szwedzkim Narodowym Instytucie Badawczym Dróg i Transportu. Doktor Linder kieruje programem testów zderzeniowych prowadzonym w laboratorium w Linköping.
      Kobiety są przeciętnie niższe i lżejsze niż mężczyźni, mają słabsze mięśnie, inaczej rozłożoną tkankę tłuszczową. To wszystko wpływa na zachowanie się ciała podczas wypadku. Istnieją między nami różnice w kształcie tułowia, umiejscowieniu środka ciężkości, budowie bioder i miednicy, wyjaśnia Linder.
      Specjalistka zauważa jednocześnie, że nie wystarczy wyprodukowanie odpowiedniego manekina. Konieczne są też zmiany prawne dotyczące testów zderzeniowych. Obecnie nie ma w nich bowiem mowy o wymogu używania manekinów odpowiadających budowie przeciętnej kobiety.
      Szef amerykańskiej firmy Humanetics, największego na świecie producenta manekinów do testów zderzeniowych przyznaje, że mimo coraz większego zaawansowania systemów bezpieczeństwa w samochodach, podczas ich opracowywania nie brano pod uwagę różnic pomiędzy kobietami a mężczyznami. Nie można przetestować kobiety i mężczyzny za pomocą tego samego urządzenia. Nie określimy miejsc powstawania urazów, dopóki nie umieścimy czujników na manekinie i tego nie zbadamy, stwierdza. Dodaje, że dopiero testy z udziałem manekinów reprezentatywnych dla kobiet pozwolą na opracowanie systemów równie dobrze chroniących obie płci.
      Od pewnego czasu trwają też prace nad manekinami lepiej reprezentującymi dzieci, osoby starsze czy otyłe.

      « powrót do artykułu
    • przez KopalniaWiedzy.pl
      Zakaz poruszania się po mieście elektrycznych hulajnóg i rowerów może zmniejszyć zagęszczenie na chodnikach i zwiększyć bezpieczeństwo pieszych oraz użytkowników elektrycznych pojazdów, jednak ma też swoje negatywne konsekwencje, informują naukowcy z Georgia Institute of Technology.
      W 2019 roku Atlanta zakazała poruszania się elektrycznymi hulajnogami i rowerami w godzinach od 21 do 4 rano. Zakaz wprowadzono po tym, jak cztery osoby korzystające z takich pojazdów zginęły w wyniku kolizji z samochodami. Naukowcy z GaTech postanowili sprawdzić, jakie były skutki zakazu. Okazało się usunięcie tych pojazdów spowodowało, że przeciętny czas podróży po mieście wydłużył się przeciętnie o około 10%. Dla mieszkańców Atlanty oznacza to, że w godzinach, w których obowiązuje zakaz, stracą dodatkowych 784 000 godzin na przemieszczanie się. Gdyby zakaz rozszerzono na godziny szczytu, straty byłyby jeszcze większe, ostrzega główny autor badań, Omar Asensio. W Atlancie godziny szczytu trwają od 6 do 10 rano i od 15 do 19 po południu.
      Naukowcy z Georgii szacują, że w skali całego kraju elektryczne hulajnogi, rowery i inne podobne środki lokomocji oszczędzają obywatelom około 17,4% czasu przeznaczonego na podróże. Mają więc one duży wpływ na zmniejszenie ruchu na drogach, co odczuwają wszyscy z nich korzystający.
      Wcześniej prowadzono już co prawda podobne badania, jednak były to badania ankietowe. Asensio i jego zespół oparli się na rzeczywistych danych o ruchu i skorzystali przy tym z faktu, że miasto zastosowało geo-fencing, co całkowicie uniemożliwiło korzystanie z zakazanych pojazdów w wyznaczonych godzinach. Mamy tutaj świetną okazję, by przeprowadzić badania, gdyż w wyniku działań miasta i policji mamy niemal 100-procentowe przestrzeganie zakazu. Powstało pytanie, co zrobią ludzie, którzy nagle nie mogą wypożyczyć hulajnogi lub użyć własnej. To wielki naturalny eksperyment, który pozwolił nam zbadać warunki na drogach przed i po jego wprowadzeniu. Pozwoliło nam to przetestować teorie dotyczące zmiany zachowań, dodaje Asensio. Naukowcy uzyskali też dostęp do danych Ubera, które pozwoliły im na ocenę czasu przemieszczania się po mieście.
      Z badań wynika, że o ile rzeczywiście zakaz używania hulajnóg zmniejsza liczbę wypadków z ich udziałem, to jednocześnie wydłuża czas podróży po mieście, zwiększa korki na drogach, a co za tym idzie, zanieczyszczenie powietrza w mieście, co również negatywnie wpływa na zdrowie mieszkańców.
      Możliwość łatwego wypożyczenia elektrycznej hulajnogi czy roweru i pozostawienia pojazdu w mieście przyczynia się do zmniejszenia korków i zanieczyszczeń, gdyż część mieszkańców rzadziej korzysta z własnego samochodu i transportu publicznego. Skraca się więc czas podróży po mieście samochodem. Zespół Asensio wylicza, że wartość zaoszczędzonego w ten sposób czasu wynosi, w skali całego kraju, 536 milionów dolarów. Naukowcy mówią, że dla lepszego planowania miast i życia w nich potrzebne jest lepsze zrozumienie wpływu różnych środków transportu oraz motywów stojących za decyzjami o wykorzystaniu danego pojazdu. Sądzę, że kolejnym etapem tego typu badań mogłoby być modelowanie wpływu zanieczyszczeń, mówi Asensio.

      « powrót do artykułu
    • przez KopalniaWiedzy.pl
      W ciągu ostatnich kilku dni ze stanowisk redakcyjnych w recenzowanym piśmie Vaccines zrezygnowało co najmniej 6 wirusologów i wakcynologów, w tym współzałożycielka pisma Diane Harper z University of Michigan. Do rezygnacji uczonych doszło po tym, jak w piśmie ukazał się artykuł, którego autorzy stwierdzili, że na każde 3 zgony na COVID19, którym szczepionki zapobiegły, przypadają 2 zgony spowodowane przez szczepionki.
      Z pracy dla Vaccines zrezygnowali m.in. Florian Krammer, wirusolog z Icahn School of Medicine, immunolog Katie Ewer z University of Oxford, która brała udział w pracach nad szczepionką AstraZeneca czy Helen Petousis-Harris, wakcynolog stojąca na czele Vaccine Datalink and Research Group na University of Auckland.
      Dane zostały nieprawidłowo zinterpretowane, gdyż wynika z nich, że każdy zgon, który nastąpił po szczepieniu został spowodowany szczepieniem. Teraz artykuł ten jest wykorzystywany przez antyszczepionkowców i osoby zaprzeczające istnieniu pandemii, jako argument, że szczepionki nie są bezpieczne. Publikacja takiego artykułu jest wysoce nieodpowiedzialna, szczególnie ze strony pisma specjalizującego się w publikacjach na temat szczepionek, stwierdziła Katie Ewer.
      Fala rezygnacji rozpoczęła się w piątek, po opublikowaniu artykułu zatytułowanego The Safety of COVID-19 Vaccinations—We Should Rethink the Policy. Jego autorami są Harald Walach z Uniwersytetu Medycznego w Poznaniu, Rainer J. Klement ze Szpitala Leopoldina w Niemczech oraz Wouter Aukema z Holandii. Żaden z autorów nie jest wirusologiem, wakcynologiem czy epidemiologiem.
      Harald Walach to psycholog kliniczny i historyk nauki, Rainer Klement specjalizuje się w diecie ketogenicznej w leczeniu nowotworów, zaś Wouter Aukema jest niezależnym specjalistą od analizy danych. Ich artykuł był recenzowany przez trzech naukowców. Dwoje z nich jest anonimowych. Trzecim recenzentem jest Anne Ulrich, chemik z Instytutu Technologii w Karlsruhe.
      W swojej recenzji pani Ulrich napisała, że analiza wykonana przez autorów artykułu jest odpowiedzialna, bez błędów metodologicznych, a wnioski zostały sformułowane z odpowiednimi zastrzeżeniami. Z kolei jeden z anonimowych recenzentów napisał, że artykuł jest bardzo ważny i powinien być pilnie opublikowany. To niemal cała recenzja.
      Z recenzji tych jasno wynika, że recenzenci nie mają żadnego doświadczenia na polu, którego dotyczy artykuł. Również autorzy artykułu takiego doświadczenia nie posiadają, komentuje Petousis-Harris.
      Autorzy artykułu obliczyli liczbę zgonów, którym zapobiegły szczepionki przeciwko COVID-19, biorąc pod uwagę wcześniejsze badania nad 1,2 milionami Izraelczyków, z których połowa otrzymała szczepionkę Pfizera, a połowa była niezaszczepiona. Z obliczeń wynikało, że średnio konieczne było zaszczepienie 16 000 osób, by zapobiec jednemu zgonowi. Krytycy zauważają, że wyliczenia są błędne, gdyż w miarę, jak coraz więcej osób jest zaszczepianych, trzeba zaszczepić coraz więcej, by zapobiec każdemu dodatkowemu przypadkowi śmierci.
      Kolejny błąd popełniono przy obliczaniu liczby zgonów spowodowanych przez szczepionki. Autorzy badań wzięli bowiem pod uwagę holenderską narodową bazę danych dotyczącą niepożądanych skutków przyjmowania środków medycznych. Baza ta, Lareb, jest podobna do amerykańskiego systemu VAERS, który opisywaliśmy przed kilkoma miesiącami.
      Do Lareb, podobnie jak VAERS, każdy może wpisać wszelkie niepokojące objawy, jakich doświadczył po przyjęciu szczepionki. To jednak nie oznacza, że sygnalizowany problem rzeczywiście został spowodowany przez lek czy szczepionkę. Dlatego też tego typu baz nie wykorzystuje się do oceny ryzyk spowodowanych przez środki medyczne, a do poszukiwania wczesnych sygnałów ostrzegawczych o tego typu ryzykach. Sygnały takie są następnie weryfikowane pod kątem ich związku z przyjętą szczepionką czy lekiem. Zresztą w bazie Lareb wyraźnie zawarto informację, że umieszczenie w niej wpisu nie oznacza, iż istnieje rzeczywisty związek pomiędzy szczepionką lub lekiem, a raportowanymi objawami.
      Mimo to autorzy badań stwierdzili w artykule, że w bazie tej znaleźli 16 poważnych skutków ubocznych na 100 000 zaszczepionych oraz 4,11 śmiertelnych skutków ubocznych na 100 000 zaszczepionych. Zatem na każde trzy zgony, którym szczepionki zapobiegły, przypadają 2 zgony, które spowodowały.
      Eugene van Puijenbroek, dyrektor ds. naukowych i badawczych Lareb już dzień po publikacji kontrowersyjnego artykułu napisał do redakcji Vaccines, krytykując artykuł i domagając się jego poprawienia lub wycofania. Zgłoszone do bazy wydarzenie, do którego doszło po zaszczepieniu, niekoniecznie musi być spowodowane przez szczepienie. Tymczasem autorzy zaprezentowali nasze dane tak, jakby istniał związek przyczynowo-skutkowy. Sugerowanie, że we wszystkich wpisach, w których poinformowano o zgonie po szczepieniu, istnieje związek przyczynowo-skutkowy, jest dalekie od prawdy.
      Co więcej, van Puijenbroek zauważa, że w artykule pada stwierdzenie, że dane z holenderskiego rejestru, szczególnie informacje dotyczące zgonów, zostały potwierdzone przez specjalistów. To po prostu nieprawda. Wydaje się, że autorzy artykułu mają tutaj na myśli opublikowane przez nas zasady tworzenia Lareb. Tymczasem w zasadach tych nigdzie nie pada stwierdzenie, że wpisy znajdujące się w bazie są certyfikowane przez specjalistów, mówi van Puijenbroek.
      Harald Walach broni artykułu. Mówi, że szczepionki zostały dopuszczone do użytku w trybie przyspieszonym, a liczba osób uczestnicząca w testach klinicznych nie była wystarczająco duża, a testy nie trwały wystarczająco długo, by ocenić bezpieczeństwo. Wszyscy trzej autorzy stoją na stanowisku, że ich artykuł nie zawiera błędów.

      « powrót do artykułu
    • przez KopalniaWiedzy.pl
      W tworzywach sztucznych używana jest olbrzymia liczba środków chemicznych, z których znaczna część nie została dobrze przebadana, a wiele potencjalnie szkodliwych związków jest dopuszczonych do kontaktu z żywnością. Do takich wniosków doszli naukowcy ze Szwajcarskiego Federalnego Instytutu Technologii w Zurichu (ETH Zurich), którzy stworzyli pierwszą dużą bazę danych monomerów, dodatków i związków ułatwiających produkcję wykorzystywanych w plastikach.
      Szwajcarzy zidentyfikowali w tworzywach sztucznych około 10 500 związków chemicznych. Wśród nich 2489 używanych jest w opakowaniach, do tekstyliów trafia 2429 środków, kontakt z żywnością ma 2109 związków chemicznych, a 522 różne związki są wykorzystywane do produkcji zabawek. Z kolei w urządzeniach medycznych, w tym maseczkach, znajdziemy 247 związków chemicznych.
      Co więcej, spośród wspomnianych 10 500 substancji aż 2480 (24%) to związki o potencjalnie szkodliwym wpływie na zdrowie. To oznacza, że niemal 1/4 wszystkich chemikaliów używanych w plastikach to albo związki wysoce stabilne, albo akumulują się w organizmie, albo są toksyczne. Są to często substancje toksyczne dla zwierząt wodny, powodujące nowotwory lub uszkadzające konkretne narządy, mówi główna autorka badań, Helene Wiesinger. Uczona dodaje, że niemal połowa z tych potencjalnie szkodliwych substancji jest masowo produkowana w Unii Europejskiej lub Stanach Zjednoczonych.
      Najbardziej uderzający jest fakt, że wiele z tych potencjalnie niebezpiecznych substancji podlega bardzo słabym regulacjom lub nie są dokładnie opisane, mówi Wiesinger. Z badań wynika, że aż 53% potencjalnie niebezpiecznych substancji w ogóle nie podlega żadnym regulacjom ani w USA, ani w UE, ani w Japonii. Jeszcze bardziej zaskakujący jest fakt, ze 901 potencjalnie niebezpiecznych substancji zostało zatwierdzonych do kontaktu z żywnością. A dla około 10% takich substancji Szwajcarzy nie znaleźli żadnych opracowań naukowych.
      Tworzywa sztuczne wytwarzane są z organicznych polimerów zbudowanych z powtarzających się monomerów. W czasie produkcji dodaje się wiele różnych związków chemicznych, jak przeciwutleniacze, plastyfikatory, opóźniacze spalania itp. itd., które nadają plastikom pożądne właściwości. Ponadto używa się katalizatorów, rozpuszczalników i innych związków ułatwiających sam proces produkcyjny oraz obróbkę plastiku.
      Badacze, ustawodawcy i sam przemysł skupiają się głównie na niewielkiej liczbie niebezpiecznych chemikaliów, o których wiadomo, że znajdują się w plastikach, mówi Wiesinger. Tymczasem wiemy, że plastikowe opakowania to główne źródło organicznych zanieczyszczeń żywności, a ftalany i bromowane opóźniacze spalania wykrywane są w kurzu i powietrzu w pomieszczeniach. Coraz częściej ukazują się też badania dowodzące, że w tworzywach sztucznych znajduje się znacznie więcej niebezpiecznych substancji niż przypuszczano.
      Jednak Szwajcarów najbardziej zaskoczył i zmartwił fakt, że wykorzystuje się tak wiele potencjalnie niebezpiecznych substancji. Kontakt z takimi substancjami może mieć negatywny wpływ na zdrowie konsumentów, pracowników fabryk plastiku oraz na środowisko. Wpływają one też negatywnie na proces recyklingu, jego bezpieczeństwo i jakość przetworzonego plastiku.
      Nie można jednak wykluczyć, że potencjalnie niebezpiecznych jest znacznie więcej substancji. Szwajcarzy zauważają, że 4100 (39%) chemikaliów, które zidentyfikowali w plastikach, nie zostało nigdzie zakwalifikowanych pod względem bezpieczeństwa.
      Uczeni zbierali dane do swojej pracy przez ponad 2,5 roku. W tym czasie przeanalizowali ponad 190 publicznie dostępnych źródłem informacji z instytucji badawczych, przemysłu oraz źródeł urzędowych. Znaleźliśmy wiele luk w tych danych. Braki dotyczyły szczególnie opisu substancji i ich konkretnych zastosowań. To zaś negatywnie wpływa na możliwość podjęcia przez konsumenta decyzji, co do plastiku, jaki chce używać.
      Wyniki badań zostały opisane w artykule Deep Dive into Plastic Monomers, Additives, and Processing Aids.

      « powrót do artykułu
    • przez KopalniaWiedzy.pl
      FBI, Europol i agencje z 18 krajów świat aresztowały ostatnio ponad 800 członków zorganizowanych grup przestępczych, przejęły ponad 48 milionów USD w gotówce, 250 sztuk nielegalnej broni, 22 tony marihuany oraz jej pochodnych, 8 ton kokainy oraz inne narkotyki. A wszystko dzięki specjalnej aplikacji, które same stworzyły i podsunęły kryminalistom.
      W 2019 roku FBI i Australijska Policja Federalna stworzyły firmę ANOM, która rozwijała bezpieczne urządzenia i oprogramowanie do szyfrowanej komunikacji. Komunikator ANOM był specjalnie przystosowany do potrzeb zorganizowanych grup przestępczych. Służby, dzięki temu, że kontrolowały całą platformę, zyskały z czasem dostęp do 27 milionów wiadomości wysłanych za jej pomocą.
      Aplikację ANOM podsunęli przestępcom agenci działający pod przykryciem w strukturach kryminalnego półświatka. Była ona zainstalowana na specjalnych telefonach, z których nie można było ani wysyłać maili, ani wykonywać połączeń głosowych. Telefony takie dostępne są były wyłącznie na czarnym rynku. Kryminaliści, którym ANOM sie spodobała, polecali ją swoim kolegom po fachu.
      FBI mówi, że wiele gangów zaczęło korzystać z ANOM po tym, jak służbom udało się wyłączyć serwis Sky EEC, z którego korzystali. W końcu platforma ANOM trafiła na ponad 12 000 szyfrowanych urządzeń, z których korzystało ponad 300 grup przestępczych w ponad 100 krajach, w tym włoskie grupy przestępcze, gangi motocyklowe czy międzynarodowe siatki przemytników. Komunikacja pomiędzy użytkownikami ANOM przechodziła przez serwery kontrolowane przez służby i była tam zapisywała.
      Szyfrowane urządzenia były i wciąż są bezpieczną przystanią dla organizacji przestępczych, szczególnie dla kierownictwa tych organizacji. Nie mamy dostępu do takich systemów, mówi agent specjalny Jamie Arnold z San Diego. To było kreatywne, innowacyjne śledztwo, które pozwoliło nam zajrzeć za kulisy działalności kierownictwa zorganizowanych grup przestępczych, dodał.
      Aresztowań dokonano w 18 krajach, w tym w USA, Wielkiej Brytanii, Niemczech, Szwecji, Nowej Zelandii, Holandii i Australii. Szefostwo australijskiej policji poinformowało, że dzięki ANOM udało się udaremnić próby 21 zabójstw, w tym i takiego, w którym miała zginąć 5-osobowa rodzina. Niektóre z osób aresztowane w Australii to członkowie gangów motocyklowych, mafii, azjatyckich syndykatów przestępczych i innych zorganizowanych grup, mówi Reece Kershaw, szef australijskiej policji.
      Niemiecka policja poinformowała o aresztowaniu u siebie 70 osób. Grupy przestępcze używające szyfrowanej komunikacji nie mogą już czuć się bezpiecznie, dodaje agent Arnold. Mamy nadzieję, że od tej pory przestępcy na całym świecie zaczną się obawiać, że platforma komunikacyjna, której używają, została założona przez FBI lub jakąś inną agencję.

      « powrót do artykułu
  • Ostatnio przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników przeglądających tę stronę.

×
×
  • Dodaj nową pozycję...