Правоохранительные органы пока совершенно не знают, как бороться с подобными вещами, многие торговцы годами продают свой запрещенный товар. Исчезают они, как правило, когда пытаются продать оружие напрямую, а не через сеть.
Да ну?
Мне вспоминается старое правило торговли оружием:
«Всегда двое из трех участвующих в сделке — сотрудники органов.»(с)
Не вижу проблемы в том, чтобы продавать оружие по таким объявлением и отслеживать покупателей около закладок.
Не вижу проблемы в том, чтобы найти закономерность в действиях определенного продавца и в итоге отследить его. Хотя это и сложнее чем накрыть покупателя.
опастности сведены к минимуму.
И как избавиться от опасности, что тебя ждут у закладки? «Я случайно наткнулся» — не сработает. Потому что попал под подозрение — считай поймали.
О чем и речь.
Если в неуправляемых языка есть шанс, что просто изменится объем выделенной памяти, то на всяких java мы все время будем копировать куски памяти. Хотя могу ошибаться, возможно там все таки внутри есть алгоритмы, которые позволяют в таких ситуациях просто добавить памяти без перемещения данных.
Я помню себя.
Родители не могли контролироать меня на 100% и я делал очень много того, что было под запретом.
Но запреты работали. Они частично ограничивали свободу.
Простой пример: мне было на 100% запрещено играть на компьютере. Но я все равно играл. Однако за счет запрета я занимался и другими вещами — в том числе программированием. НЕ было бы запрета — вероятно я бы жил той жизнью, которой сейчас живут мои племяши: игры, игры, игры.
Тоже самое касается порно. За счет запрета на продажу порно детям — я не мог его сам достать. И доставал через взрослых(ну как взрослых, 20 летних примерно). Но эти пацаны сами не идиоты и фильтровали порно, чтобы мне доставалось что-то достаточно адекватное, а не rape с инцестом. И, это правильно.
Эти запреты в итоге не работали как полный ограничитель, но работали как фильтр. И я вижу в этом большой плюс.
Вероятно я не буду своему ребенку ограничивать доступ к ХХХ контенту, когда он ему станет интересен. Но постараюсь косвенно добиться, чтобы доставался ему контент только определенного вида. Хотя на данный момент я не имею четкого плана, как это будет реализовано.
гугл и запрос Eclipse lags не согласны с вами.
Да даже в гугл не обязательно ходить. Хабр содержит некоторое количество статей описывающих проблемы Эклипса.
А смысл от примеров? Чтобы в ответ можно было сказать «А Эклпис умеет вот это, а ваша IDE — не умеет!». Так всегда можно будет сказать, потому что идеентичных IDE не бывает и у каждой свои особенности.
Ну, все мы знаем как работает Эклипс.
Мне сама IDE очень нравится. Но ее стабильность и потребление памяти — известные проблемы.
Сложно представить, что Эклипс пишут криворучки.
Простите, не хочу затевать холивар, но мимо таких заявлений не могу пройти…
На С++ действительно можно создать себе проблем.
#define TRUE FALSE
Но на С++ можно писать нормальный код, который нормально работает. Достаточно просто не канифолить себе мозг пытаясь конструкцией покороче решить проблему побольше.
Я много пишу на С++. Но вот так навскидку не могу припомнить кода, который бы вызывал проблемы.
Я мало пишу на Java, но легко вспомню пример, который меня просто убил:
GC как-то по особенному работает с Bitmap на Android, и чтобы не получить OOM — надо ручками вызывать Bitmap.recycle(). Хотя казалось бы — язык должен сам следить за работой с памятью и не должен отвлекать от написания алгоритмов…
А в чем, собственно, проблем писать на С/С++ под любую платформу? Как от железа зависит код?
Писал кроссплатформенный фреймворк и единственную проблему примоминаю — это необходимость учитывать BIG_ENDIAN/LITTLE_ENDIAN. В остальном С++ код одинаково компилится под все мне доступные платформы.
Я не могу представить прикладную задачу, которая бы резко стала сложнее от того, что ее надо делать кроссплатформенной.
Всегда думал, что основная фишечка java и аналогов — это GC. Не?
Вот именно. Пока не получается.
ИМХО попытки пока создают проблем больше чем решают.
Возможно во мне говорит любитель не управляемых языков, конечно.
Но в целом впечатление от языков с управлением памятью негативное. Запоминать нюансов работы с GC приходит больше чем правил по работе с указателями в неуправляемых языках.
Введение не соответствует сути статьи.
У вас не HDD быстрее RAM. У вас работа с HDD быстрее чем работа с RAM в некоторых случаях при использовании языков высокого уровня. А если точнее — языков с не прямым управлением памятью.
Конечно работа с оперативкой будет медленней, если на добавление каждого нового байта(или кучки байт) у вас будет realloc. А на всяких java и python у вас именно так и будет.
Если же писать на языке дающим возможность управлять памятью напрямую, то выделяется фиксированный буфер и до его заполнения пишем в него, как заполнился — сбрасываем на жесткий — будет быстрее. Я гарантирую это.
Что характерно искусственная буферизация на уровне кода работает все равно лучше чем решение из ОС. Во всяком случае когда мы проводили тесты на винде — искусственная буферизация в коде давала прирост скорости по сравнению с тупым писанием каждого байта через ОС.
Да ну?
Мне вспоминается старое правило торговли оружием:
«Всегда двое из трех участвующих в сделке — сотрудники органов.»(с)
Не вижу проблемы в том, чтобы продавать оружие по таким объявлением и отслеживать покупателей около закладок.
Не вижу проблемы в том, чтобы найти закономерность в действиях определенного продавца и в итоге отследить его. Хотя это и сложнее чем накрыть покупателя.
И как избавиться от опасности, что тебя ждут у закладки? «Я случайно наткнулся» — не сработает. Потому что попал под подозрение — считай поймали.
Если в неуправляемых языка есть шанс, что просто изменится объем выделенной памяти, то на всяких java мы все время будем копировать куски памяти. Хотя могу ошибаться, возможно там все таки внутри есть алгоритмы, которые позволяют в таких ситуациях просто добавить памяти без перемещения данных.
имел ввиду операцию создания нового блока памяти с копированием туда данных из предыдущего.
Понятно, что возможно это «эфир нашего времени». Но пока без него никак.
Если контролируешь не ты, значит контролирует кто-то другой.
Родители не могли контролироать меня на 100% и я делал очень много того, что было под запретом.
Но запреты работали. Они частично ограничивали свободу.
Простой пример: мне было на 100% запрещено играть на компьютере. Но я все равно играл. Однако за счет запрета я занимался и другими вещами — в том числе программированием. НЕ было бы запрета — вероятно я бы жил той жизнью, которой сейчас живут мои племяши: игры, игры, игры.
Тоже самое касается порно. За счет запрета на продажу порно детям — я не мог его сам достать. И доставал через взрослых(ну как взрослых, 20 летних примерно). Но эти пацаны сами не идиоты и фильтровали порно, чтобы мне доставалось что-то достаточно адекватное, а не rape с инцестом. И, это правильно.
Эти запреты в итоге не работали как полный ограничитель, но работали как фильтр. И я вижу в этом большой плюс.
Вероятно я не буду своему ребенку ограничивать доступ к ХХХ контенту, когда он ему станет интересен. Но постараюсь косвенно добиться, чтобы доставался ему контент только определенного вида. Хотя на данный момент я не имею четкого плана, как это будет реализовано.
Я, вообще, за порно. Но считаю что некий контроль и ограждение малолетних должно быть. И должны быть исследования. Много.
А будут ли?
Да даже в гугл не обязательно ходить. Хабр содержит некоторое количество статей описывающих проблемы Эклипса.
Мне сама IDE очень нравится. Но ее стабильность и потребление памяти — известные проблемы.
Сложно представить, что Эклипс пишут криворучки.
На С++ действительно можно создать себе проблем.
#define TRUE FALSE
Но на С++ можно писать нормальный код, который нормально работает. Достаточно просто не канифолить себе мозг пытаясь конструкцией покороче решить проблему побольше.
Я много пишу на С++. Но вот так навскидку не могу припомнить кода, который бы вызывал проблемы.
Я мало пишу на Java, но легко вспомню пример, который меня просто убил:
GC как-то по особенному работает с Bitmap на Android, и чтобы не получить OOM — надо ручками вызывать Bitmap.recycle(). Хотя казалось бы — язык должен сам следить за работой с памятью и не должен отвлекать от написания алгоритмов…
Писал кроссплатформенный фреймворк и единственную проблему примоминаю — это необходимость учитывать BIG_ENDIAN/LITTLE_ENDIAN. В остальном С++ код одинаково компилится под все мне доступные платформы.
Я не могу представить прикладную задачу, которая бы резко стала сложнее от того, что ее надо делать кроссплатформенной.
Всегда думал, что основная фишечка java и аналогов — это GC. Не?
ИМХО попытки пока создают проблем больше чем решают.
Возможно во мне говорит любитель не управляемых языков, конечно.
Но в целом впечатление от языков с управлением памятью негативное. Запоминать нюансов работы с GC приходит больше чем правил по работе с указателями в неуправляемых языках.
У вас не HDD быстрее RAM. У вас работа с HDD быстрее чем работа с RAM в некоторых случаях при использовании языков высокого уровня. А если точнее — языков с не прямым управлением памятью.
Конечно работа с оперативкой будет медленней, если на добавление каждого нового байта(или кучки байт) у вас будет realloc. А на всяких java и python у вас именно так и будет.
Если же писать на языке дающим возможность управлять памятью напрямую, то выделяется фиксированный буфер и до его заполнения пишем в него, как заполнился — сбрасываем на жесткий — будет быстрее. Я гарантирую это.
Что характерно искусственная буферизация на уровне кода работает все равно лучше чем решение из ОС. Во всяком случае когда мы проводили тесты на винде — искусственная буферизация в коде давала прирост скорости по сравнению с тупым писанием каждого байта через ОС.