Это понятно и вопросов не вызывает. Но, если купить нельзя (или очень сложно), то факт пиратства не влияет на доход автора. Без пиратства книга просто не была-бы прочитана. Но автор денег не получает в любом случае.
судя по тому, что говорят сами писатели, нихрена не влияет пиратство на доходы. Те, кто покупает бумажные книги — они все равно покупают. А кто не покупает — они и не будут покупать. Читают не потому, что хотят читать и выбирают наиболее дешевый (бесплатный) вариант, а посто потому, что халява. Не будет халявы — просто не будут читать коммерческую литературу. Будут читать самиздат, public domain и прочее бесплатное. Халявы хватает.
Естественно, есть некая прослойка, которая таки пиратит потому, что можно, а иначе платили-бы бабки. Но их мало и в общем зачете они не интересны.
Вероятность, что от конструктора отвалится одновременно два магнита уж очень мала. А уж то, что оба отвалившихся ребенок проглотит — и того меньше.
Проблемы все-таки с игрушками, где эти магниты существуют сами по себе, россыпью. А если магнит приклеен и еще сверху прикручен шурупом, то это совсем другое дело.
И у Гугла и у Амазона есть офисы за пределами Штатов. И, подозреваю, что человека, прошедшего интеншип в головном офисе, таки с региональный офис возьмут без особых проблем.
Очень рекомендую на произвольном линуксе (в других системах вроде SGI не уверен в результате) выполнить команду
cat `which fsck.xfs`
— думаю, что Вам понравится :)
P.S. я догадываюсь, что вы про xfs_check хотели сказать. Но все-таки check — это только check. А мы про восстановление. И таки xfs_repair хоть и жрет меньше памяти, чем xfs_check, но жрет.
Я, собственно, упомянутую статью читал и таки, если вы заметили, там методику тестирования не критиковал. В том числе и вопросы фрагментации. Потому как, как вы правильно заметили, фрагментация данных самих по себе на флеш-носителях не имеет решающего значения. В случае-же файловых систем, мне кажется, ситуация несколько меняется. Возникает вопрос не только фрагментации самих данных, но и увеличения количества чтений метаданных, дабы собрать информацию о том, какие блоки вообще надо читать.
Что касается специфики — возможно имело смысл в таком случае в начале статьи описать данную специфику и объяснить причины выбора именно этих и только этих вариантов для тестирования. Хотя лично мне кажется, что раз уж вы имеете возможность провести толковое тестирование, то имело-бы смысл провести хорошее сравнение производительности различных популярных файловых систем. Оно было-бы многим полезно почитать. Особенно учитывая, что флеш-накопители в любом случае уже плотно входят в нашу повседневную жизнь и проблемы файловых систем становятся все более заметными на фоне всё более быстрых физических носителей.
Создание 16 файлов и потом запись/чтение из них — это имеет весьма малое отношение к файловой системе. Особенно если файлы создались заранее и фрагментация отсутствует.
При тестировании файловой системы куда более интересный сценарий это создание и удаление в произвольном порядке 10 миллионов файлов разного размера. Вот тогда разница разных fs будет видна. Как быстро файлы создаются, как быстро удаляются, как система справляется с фрагментацией.
Ну и таки хотелось бы чуть большего разнообразия файловых систем в тестировании.
А непредсказуемо. В наше время 10 тб дисков может оказаться на виртуалке с 512 мегами. Но дело не в этом, а в том, что полтора гига — это совершенный минимум для раздела без файлов вообще. А если эти 10тб забить мелкими файлами, то требования к памяти сильно возрастут. Как, впрочем, и время восстановления.
Не подумайте, что я агитирую против xfs. Я сам её почти везде пользую. Но и в деда мороза я уже не верю. :)
несколько секунд — это когда всё хорошо. Так и если на ext4 всё хорошо, то она тоже не несколько дней чекается.
Проблема начинается когда на fs всё плохо. Тогда xfs_repair может не только долго работать, но еще и памяти требует нереальное количество.
10Тб под XFS потребует минимум полтора гига памяти. И это абсолютный минимум. А уж далее зависит от ситуации. xfs.org
у меня на 300+ пользователей я один. И никакой инфраструктуры. Собственно я тут и есть ради этого. Ибо из 10.000+ человек в организации с жесткой инфраструктурой несколько подразделений общим числом человек 300-400 решили, что не хотят они этой жесткой структуры. Наняли меня и сидят расслабляются в свое удовольствие. Так вот, основная нагрузка у меня — это анекдоты читать и прочие новости.
закрыть без санкции руководства выходы куда-либо? Ну-ну…
я понимаю, что хочется порядка и удобства. Но все-таки решения должно принимать руководство. Пусть и после советов «нижнего звена».
по дороге ко мне не шейпится — wget serverclub.com/100mb.bin
--2014-08-13 23:58:29-- serverclub.com/100mb.bin
Resolving serverclub.com… 188.42.241.4
Connecting to serverclub.com|188.42.241.4|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: “100mb.bin”
100%[======================================>] 104,857,600 26.7M/s in 6.6s
Taк что скорее со своим провом разбираться надо, а не с хостером.
От парохода зависит. Титаник в свое время обошелся меньше, чем в 8 миллионов. Что есть всего 80кг наличкой. Но это на 50 лет раньше. И это Титаник. А пароходик поменьше, мне думается, вполне можно было за наличку прикупить.
Естественно, есть некая прослойка, которая таки пиратит потому, что можно, а иначе платили-бы бабки. Но их мало и в общем зачете они не интересны.
Проблемы все-таки с игрушками, где эти магниты существуют сами по себе, россыпью. А если магнит приклеен и еще сверху прикручен шурупом, то это совсем другое дело.
Очень рекомендую на произвольном линуксе (в других системах вроде SGI не уверен в результате) выполнить команду — думаю, что Вам понравится :)
P.S. я догадываюсь, что вы про xfs_check хотели сказать. Но все-таки check — это только check. А мы про восстановление. И таки xfs_repair хоть и жрет меньше памяти, чем xfs_check, но жрет.
Что касается специфики — возможно имело смысл в таком случае в начале статьи описать данную специфику и объяснить причины выбора именно этих и только этих вариантов для тестирования. Хотя лично мне кажется, что раз уж вы имеете возможность провести толковое тестирование, то имело-бы смысл провести хорошее сравнение производительности различных популярных файловых систем. Оно было-бы многим полезно почитать. Особенно учитывая, что флеш-накопители в любом случае уже плотно входят в нашу повседневную жизнь и проблемы файловых систем становятся все более заметными на фоне всё более быстрых физических носителей.
При тестировании файловой системы куда более интересный сценарий это создание и удаление в произвольном порядке 10 миллионов файлов разного размера. Вот тогда разница разных fs будет видна. Как быстро файлы создаются, как быстро удаляются, как система справляется с фрагментацией.
Ну и таки хотелось бы чуть большего разнообразия файловых систем в тестировании.
Не подумайте, что я агитирую против xfs. Я сам её почти везде пользую. Но и в деда мороза я уже не верю. :)
Проблема начинается когда на fs всё плохо. Тогда xfs_repair может не только долго работать, но еще и памяти требует нереальное количество.
10Тб под XFS потребует минимум полтора гига памяти. И это абсолютный минимум. А уж далее зависит от ситуации.
xfs.org
p.s. государства у нас разные, проблемы очень похожие :)
я понимаю, что хочется порядка и удобства. Но все-таки решения должно принимать руководство. Пусть и после советов «нижнего звена».
--2014-08-13 23:58:29-- serverclub.com/100mb.bin
Resolving serverclub.com… 188.42.241.4
Connecting to serverclub.com|188.42.241.4|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: “100mb.bin”
100%[======================================>] 104,857,600 26.7M/s in 6.6s
Taк что скорее со своим провом разбираться надо, а не с хостером.