Резет в процессе загрузки довольно таки часто выбивает системный реестр на уровне файловой системы. Который потом приходится вытаскивать из точек восстановления, путем загрузки с лайв CD
Тоже стало любопытно.
В архиве дамп сервера ColdFusion.
Интересный финт в том, что внутри архива информация дубируется.
В /packages/qwerty лежит архив qwerty.war в котором более 95% совпадает с контентом основного архива.
Скорее всего метод взлома предполагал выполнения задания по запаковке контента сервера в архив. В итоге задание выполнилось не один раз.
К слову, в этой же папке находится конфиг проекта-задания по которому запаковывался контент — build.xml.
Но можно же было перед выкладыванием в сеть проконтролировать этот момент. Т.о. 33508 файлов объемом ~3Gb, в распакованном виде, продублированы.
Как я понимаю, основной контент (578Mb) находится здесь: /new_wwwroot/content/pub
./ascii
./gifs
./html
./pdf
./press
./sheets
Тут есть ряд документов в pdf и прочей сопроводиловки департамента. В английском не силен, посему судить критичность контента не берусь.
Для читаемости кода хорошо помогает правильное именование переменных.
Я раньше тоже сторонился var, но постепенно втянулся и сейчас использую повсеместно.
Хочу отметить, что var, не отменяет четкую типизацию.
оператор лишь избавляет вас от избыточности кода. Если не использовать Var, то избыточность очень наглядна в следующем примере:
Dictionary<int,string> dic = new Dctionary<int,string>();
В случае с методами, переменная var примет тот тип, который возвращает функция.
var result = Function.SomeMethod();
Очень удобно использовать var с длинными сигнатурами типов и в купе с LINQ.
Если датчик положения коленвала/распредвала выйдет из строя совсем, т.е. данных от него компьютер получать не будет совсем, то завести такой двигатель не получится.
Если же такой датчик будет немного привирать, то работа ДВС вполне возможна.
Кстати врать датчик может элементарно от воды, которая порой попадает в его корпус.
Я занимаюсь разработкой ПО для корректировок констант в прошивках автомобильных компьютеров.
Ну и помимо этого, в своем гараже, собрал не один мотор. Но не смотря на это почерпнул из статьи много полезного.
Хотя конечно «углубления» в теорию, по прежнему, требую! :)
Вы когда нибудь видели «лопнувшие стенки цилиндров»? Если так, то снимаю шляпу.
Мне казалось, что основная проблема выхода из строя «надутых» ДВС — температура, превышение которой приводит к оплавлению поршней и вылета их через выхлопную трубу.
Да, я посмотрел варианты использования AGI интерфейса asterisk. Но я не понимаю какие преимущества этого метода по сравнению с тем, который описан выше?
Касательно .net на linux я пока отношусь довольно скептически. К тому же сколько же надо поставить пакетов и библиотек mono для поддержки .net платформы? На сколько я помню размеры там от 30мегабайт. Дополнительные пакеты это большой минус решению.
В архиве дамп сервера ColdFusion.
Интересный финт в том, что внутри архива информация дубируется.
В /packages/qwerty лежит архив qwerty.war в котором более 95% совпадает с контентом основного архива.
Скорее всего метод взлома предполагал выполнения задания по запаковке контента сервера в архив. В итоге задание выполнилось не один раз.
К слову, в этой же папке находится конфиг проекта-задания по которому запаковывался контент — build.xml.
Но можно же было перед выкладыванием в сеть проконтролировать этот момент. Т.о. 33508 файлов объемом ~3Gb, в распакованном виде, продублированы.
Как я понимаю, основной контент (578Mb) находится здесь:
/new_wwwroot/content/pub./ascii
./gifs
./html
./pdf
./press
./sheets
Тут есть ряд документов в pdf и прочей сопроводиловки департамента. В английском не силен, посему судить критичность контента не берусь.
Проверил. Действительно нет источников с 100% ресурсом…
ребята не стоят на месте, это радует.
так же в сети были статейки по перепрошивке ядра андроид с поддержкой FTDI. но так зморачиваться не стал )
Жаль конечно что не 'n' стандарта
проблема кроется в урезанном ядре.
к примеру был опыт в прикручивании com2usb на чипе FTDI. безуспешный.
Я раньше тоже сторонился var, но постепенно втянулся и сейчас использую повсеместно.
оператор лишь избавляет вас от избыточности кода. Если не использовать Var, то избыточность очень наглядна в следующем примере:
Dictionary<int,string> dic = new Dctionary<int,string>();
В случае с методами, переменная var примет тот тип, который возвращает функция.
var result = Function.SomeMethod();
Очень удобно использовать var с длинными сигнатурами типов и в купе с LINQ.
Если же такой датчик будет немного привирать, то работа ДВС вполне возможна.
Кстати врать датчик может элементарно от воды, которая порой попадает в его корпус.
Ну и помимо этого, в своем гараже, собрал не один мотор. Но не смотря на это почерпнул из статьи много полезного.
Хотя конечно «углубления» в теорию, по прежнему, требую! :)
Очень хорошая статья, спасибо за труды.
Мне казалось, что основная проблема выхода из строя «надутых» ДВС — температура, превышение которой приводит к оплавлению поршней и вылета их через выхлопную трубу.
This recipient is currently unable to receive money.
Прикрыли акк?
т.о.
var c = new List (1) { Color.Green };
решит проблему
Касательно .net на linux я пока отношусь довольно скептически. К тому же сколько же надо поставить пакетов и библиотек mono для поддержки .net платформы? На сколько я помню размеры там от 30мегабайт. Дополнительные пакеты это большой минус решению.