throughtheether

nfdump+nfsen

import urllib, json

url_members = 'https://api.vk.com/method/groups.getMembers?group_id=67824212'
response_url_members = urllib.urlopen(url_members)
data = json.loads(response_url_members.read())
members = data['response']['users']
print(members)

в первом варианте у вас три раза запрашивается урл
во втором урл запрашивается один раз, первый вызов read забирает все данные, и на втором уже убудет пустая строка, которая не является валидным json, отсюда ошибка.
При этом у вас на каждой итерации цикла вызывается преобразование одних и техже данных в json.
помимо этого сам цикл вообще бесполезный поскольку в переменную members, будет на каждой итерации записываться значение и затираться следующим, будет проще обратится по индексу сразу. members = data['response']['users'][2]

Ну как минимум нужно адрес указывать на dsw01 сразу windows-сервера (172.16.0.11)

www.codecademy.com/en/tracks/python

Посчитать те, которые делятся хотя бы на одно. При этом надо учитывать, что некоторые числа будут посчитаны несколько раз. Надо воспользоваться формулой включений-исключений.
Итого делящихся хотя бы на одно из этих чисел:
240/2 + 240/3 + 240/5 - 240/(2*3) - 240/(2*5) - 240/(3*5) + 240/(2*3*5) = 176
Значит, неделящихся 240 - 176 = 64

Проверяем:

ghci> length $ filter (\x -> 0 `notElem` [x `mod` 2, x `mod` 3, x `mod` 5]) [1..240]
64

Вы что бы изобрели, предложили вместо капчи

Я бы предложил обязательную сертификацию для доступа к компу в принципе и в интернет в частности +расстрел за рассылку спама, ботоводство и прочие штуки, из за которых собственно капчи и появились.

По факту - придумают другую капчу. Совсем другую. Или сделают доступ более закрытым - по хардварному ключу.

Интересный вопрос, захотелось самому поковыряться)

Если кратко, то стандарт PPPoE отличается от стандарта PPP в части полей Address и Control. А остальные поля привнесла одна известная американская контора Microsoft. Подробнее ниже.

Открываем RFC 1661, там описано, как должен инкапсулироваться PPP. Видим, что поле Protocol Information может быть размером 8-16 бит. В частности, в PPPoE и есть только 8 бит, в чистом PPP - 16.

Классический PPP должен поддерживать те же самые заголовки, что и более ранний HDLC, для этого протокола необходимы поля Address и Control. Эти же поля успешно перекочевали в PPP, хотя формально они в нем не нужны.

Копаем дальше. В реализации протокола PPP определен механизм синхронизации LCP, у него есть опция Address-and-Control-Field-Compression. Так вот в RFC 2516 (PPPoE, не такое уж оно и большое) явно говорится, эту опцию не использовать, и вполне логично выплюнуть поля Address и Control. Как используется эта опция в PPP можно почитать здесь.

Итак, разобрались с Address и Control, займемся флагом 0x7e. Явно в стандарте PPP вы нигде не найдете такое поле, зато оно имеется в описании стандарта для win-систем. Это ни что иное, как простая переделка протокола под себя конторой MS)

Ну и напоследок несколько картиночек простых ICMP-echo пакетов.

Вот вам пример дампа PPP.
Как видите, в нем нет полей flags, FCS. Зато есть Control и Address.

А вот вам картинка с дампом PPPoE.
В нем тоже нет этих полей, как нет и Control и Address. PPPoE в таком виде не нужна совместимость с HDLC, зато нужно больше параметров синхронизации. Эти параметры идут в заголовке PPP-Over-Ethernet-Session.

Ну и напоследок картинка с дампом PPTP. Address и Control присутствуют, хотя также не обязательны, зато в начале есть заголовок GRE.

Итог - не надо читать вики просто так без оглядки, верить всему что там написано.

P. S. дампы можете сами посмотреть на packetlife, просматривать их можно сразу в браузере через cloudshark