Linux, Windows, Mac OS X - IX

ladserg · №551

krigstask пишет

Ещё раз поясняю: это никчёмная шляпа для одминов топки локалхоста. Ни для чего серьёзного она не нужна и не удобна: разработка ведётся на чём-нибудь специальном, разворачивание в бой — на чём-нибудь мощном и рабочем. Я готов признать это лучшим решением для старшеклассника, которому нужно за пятнадцать минут развернуть «сервер» в сетке из трёх компов, чтоб перед пацанами попонтоваться, но не более того.

Кстати, о птичках, я не мало видел пых кодеров использующих Денвер. Написали приложение, потестили, и на боевой сервак залили, где уже всё как положено. Пользуются виндой в основном по той же причине, что и я, очень уж игры любят компьютерные Хотя и видел кодеров в боевом облачении, с линуксом на борту, апачем, пыхом и всем остальным, что полагается.

И ещё такие комбайны весьма актуальны для проектов с малым количеством пользователей и там где нет обученного персонала.

Отредактировано ladserg (22-01-2013 15:47:11)

krigstask · №552

ladserg пишет

Кстати, о птичках, я не мало видел пых кодеров использующих Денвер

Меня когда-то к нему склоняли. К счастью, не получилось. Кропать калокод на пыхе для третьесортных сайтиков… Бр-р-р.

ladserg · №553

krigstask пишет

Меня когда-то к нему склоняли. К счастью, не получилось. Кропать калокод на пыхе для третьесортных сайтиков… Бр-р-р.

Хм, PHP - язык как язык, просто есть, популярен и прост в изучении спору нет, но я бы не сказал что пишушие на нем --- калокодеры и проекты на нем --- третьесортные

Отредактировано ladserg (22-01-2013 15:53:25)

krigstask · №554

PHP как ЯП ужасен и отвратителен, и вменяемые люди стараются от него держаться подальше.

ladserg · №555

krigstask пишет

PHP как ЯП ужасен и отвратителен, и вменяемые люди стараются от него держаться подальше.

Но сей форум, написанный на PHP, работает, и я бы не назвал его создателей калокодерами

Вообще я учился еще тогда когда информатика была именно наукой об информации, никак не связанной с компьютерами, и прежде чем перейти к практике на конкретном ЯП - год на бумажке изучаешь алгоритмизацию...

Это я к тому что после этого все языки одинаковы, а вменяемость и отвратительность она от ЯП не зависит, если чел не способен нормально по-русски то изложить алгоритм, то и программу он напишет посредственную, в лучшем случае.

Отредактировано ladserg (22-01-2013 16:23:55)

Lain_13 · №556

ladserg

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.
You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.
You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.
You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.
And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.
Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.
That’s what’s wrong with PHP.

Детали по ссылке.

Отредактировано Lain_13 (22-01-2013 17:16:03)

ladserg · №557

Lain_13 пишет

Детали по ссылке.

Если честно - то попридираться то можно к чему угодно, я всего лишь хочу сказать, что действительно знающий человек может воспользоваться почти любым инструментом для достижения результата.

К тому же PHP, будучи HTML со скриптами, весьма неплохо подходит для разработки веб-приложений. Можно так же и Java, питоне, C/C++, Perl'е, хоть на ассемблере. Если вообще понимаешь что и как делать.

Кстати о непредсказуемости, помню про C/C++ тоже острили вопросами вида:

Дано: C = C++ - C
Задача: чему равно C?

Lain_13 · №558

ladserg

Do not tell me that “good developers can write good code in any language”, or bad developers blah blah. That doesn’t mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.
Do not tell me “that’s how the C API works”. What on Earth is the point of using a high-level language if all it provides are some string helpers and a ton of verbatim C wrappers? Just write C! Here, there’s even a CGI library for it.
Do not tell me “that’s what you get for doing weird things”. If two features exist, someday, someone will find a reason to use them together. And again, this isn’t C; there’s no spec, there’s no need for “undefined behavior”.

Раздел: Don’t comment with these things

> Задача: чему равно C?
Оно равно undefined behavior и результат будет разным даже в разных версиях одного и того же компилятора не говоря уже о разных компилятораю, но что нормально для Си ненормально для высокоуровневого ЯП.

Отредактировано Lain_13 (22-01-2013 17:23:30)

ladserg · №559

Lain_13 пишет

ladserg
Do not tell me that “good developers can write good code in any language”, or bad developers blah blah. That doesn’t mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.
Do not tell me “that’s how the C API works”. What on Earth is the point of using a high-level language if all it provides are some string helpers and a ton of verbatim C wrappers? Just write C! Here, there’s even a CGI library for it.
Do not tell me “that’s what you get for doing weird things”. If two features exist, someday, someone will find a reason to use them together. And again, this isn’t C; there’s no spec, there’s no need for “undefined behavior”.
Раздел: Don’t comment with these things

И к какому языку нельзя отнести эти слова? И хотел бы обратить внимание что понятие "хороший код" - очень растяжимое, зато фраза "хорошая программа" более близка к однозначности.

Так что же на PHP нельзя создать хороших программ? Давайте рассмотрим данный вопрос на примере этого форума.

П.С. Про трассировку и дебаг чел там совсем не в тему говорит, его слова - всего лишь один из примеров отсутствия базовых знаний.

Отредактировано ladserg (22-01-2013 17:26:08)

Lain_13 · №560

ladserg

Do not tell me that Facebook and Wikipedia are built in PHP. I’m aware! They could also be written in Brainfuck, but as long as there are smart enough people wrangling the things, they can overcome problems with the platform. For all we know, development time could be halved or doubled if these products were written in some other language; this data point alone means nothing.

Так что этот форум тоже мог бы быть написан даже на брэйнфаке и при этом замечательно работать. Тут ведь не в качестве кода дело, а в самом инструменте. А дебаг в пыхе действительно ужасный, я когда в институте учился с ним имел дело и уже тогда был не рад. Особенно эта его особенность тупо замолчать ошибку и продолжать работать даже если всё пошло не так. Может сейчас ситуация изменилась к лучшему, может. Я сейчас не приведу уже примеров из собственного опыта - я его забыл уже.

И вот ещё: http://www.flickr.com/photos/raindrift/ … 492908038/
Что может быть лучшим подтверждением, чем слова одного из разработчиков Вики?

Отредактировано Lain_13 (22-01-2013 17:48:22)

ladserg · №561

Lain_13 пишет

ladserg
Так что этот форум тоже мог бы быть написан даже на брэйнфаке и при этом замечательно работать. Тут ведь не в качестве кода дело, а в самом инструменте. А дебаг в пыхе действительно ужасный, я когда в институте учился с ним имел дело и уже тогда был не рад. Особенно эта его особенность "тупо замолчать и продолжать работать даже если всё пошло не так". Может сейчас ситуация изменилась к лучшему, может. Я сейчас не приведу уже примеров из собственного опыта - я его забыл уже.

Я думаю чел просто предвзят, плюс имеет недостаточно базовых знаний. С такой же предвзятостью можно говорит (да и говорят) о любом языке, одни хают тех кто пишет на Visual Basic, другие считают что пишущие на "дельфях" - недопрограммеры и недочеловеки, третьи считают что на C/C++ написать можно только шлак...

Всё это детские споры. Если приспичит то сей форум можно написать и на bash,

Про дебаг в PHP... А можно реальный пример когда нужен именно дебаг (пошаговое исполнение) и недостаточно трассировки значений?

Кста по поводу замолчать, у PHP нужно настраивать вывод ошибок, обычно по умолчанию он настроен для боевого сервера, когда "выдавать секреты нельзя". Его можно настроить так что он будет материться и переставать работать даже при безобидных предупреждениях.

А удобство - это вкус и цвет каждого, я например до сих пор пишу код в nano, и компилю/выполняю его в отдельном окне. Мне так удобнее. У меня есть знакомые программисты, они до сих пор в качестве файлового менеджера используют какой то древний однопанельный коммандер написанный под DOS еще до появления Norton Commander... привыкли.

Никто же не заставляет писать именно на PHP.

А по поводу непредсказуемости, что пишет автор - увы ему просто нужно читать мануалы внимательнее, да и не про язык он там говорит а про функции в основном, которым по боку на язык.

PHP is full of surprises

Если внимательно читать руководство, то не будет никаких сюрпризов, и разные операции сравнения никак не будут смущать, особенно если ты понимаешь почему и как. Ну и мат часть конечно. PHP - безтиповый язык, автор почему то не захотел принимать это в расчёт.

Отредактировано ladserg (22-01-2013 17:54:44)

Lain_13 · №562

ladserg
Почему-то я уверен, что автор, написавший ту статью, очень внимательно читал руководство. Причём от многих версий пыха (он на него даже ссылается несколько раз). И если учесть, что его слова подтверждает разработчик вики с десятилетним стажем программирования на пыхе, то я склонен верить его словам.
И что значит "да и не про язык он там говорит а про функции в основном, которым по боку на язык" когда он вполне чётко говорит, например, про функции mysql_escape_string и mysql_real_escape_string. Да что не так должно быть с языком программирования, чтоб в нём было как минимум две функции экранирования служебных символов в строке, причём одна из них сломана так, что вместо исправления первой сделали вторую?

Отредактировано Lain_13 (22-01-2013 18:06:55)

ladserg · №563

Lain_13 пишет

ladserg
Почему-то я уверен, что автор, написавший ту статью, очень внимательно читал руководство. Причём от многих версий пыха (он на него даже ссылается несколько раз). И если учесть, что его слова подтверждает разработчик вики с десятилетним стажем программирования на пыхе, то я склонен верить его словам.
И что значит "да и не про язык он там говорит а про функции в основном, которым по боку на язык" когда он вполне чётко говорит, например, про функции mysql_escape_string и mysql_real_escape_string. Да что не так должно быть с языком программирования, чтоб в нём было как минимум две функции экранирования служебных символов в строке, причём одна из них сломана так, что вместо исправления первой сделали вторую?

Если он читал, то почему задает такие вопросы, если в мануале написано:

Функция идентична mysql_real_escape_string(), исключая тот факт, что mysql_real_escape_string() принимает параметром ещё и идентификатор соединения и экранирует строку с учетом текущей кодировки. mysql_escape_string() не делает этого и результат работы не зависит от кодировки, в который вы работаете с БД.

???

RTFM, и все ответы на его вопросы найдутся.

Отредактировано ladserg (22-01-2013 18:10:18)

Lain_13 · №564

Ну да, да, а в результате у нас две функции, одна из которых не работает как нужно и в пятом пыхе наконец помеченная как устаревшая, а вторая реально нужна потому, что при выполнении запроса подставляемая в него строка самим пыхом автоматически не валидируется из-за чего имеем кучу форумов и блогов по всему интернету, уязвимых для SQL-иньекций - там не применили ни одну из этих двух функций. Просто прекрасно.
Или может ты объяснишь почему "133" == "0133", но 133 != 0133 и "0x10" == "16"? Мало того, что придурошный пых конвертирует строки в числа, когда его об этом не просят, так ещё и делает это не всегда правильно, а как бог на душу положит!

Отредактировано Lain_13 (22-01-2013 18:28:19)

ladserg · №565

Lain_13 пишет

Ну да, да, а в результате у нас две функции, одна из которых не работает как нужно и в пятом пыхе наконец помеченная как устаревшая, а вторая реально нужна потому, что при выполнении запроса подставляемая в него строка самим пыхом автоматически не валидируется из-за чего имеем кучу форумов и блогов по всему интернету, уязвимых для SQL-иньекций - там не применили ни одну из этих двух функций. Просто прекрасно.

Обе они работают как нужно, просто кто то не читает внимательно мануалы. А помечены как устаревшии вовсе не эти функции, а сам модуль, к коему они относятся, т.к. не смену модулю MySQL пришел модуль MySQLi.

Чего это я, там же так и написано:

Данное расширение устарело, начиная с версии PHP 5.5.0, и будет удалено в будущем. Используйте вместо него MySQLi или PDO_MySQL. Смотрите также инструкцию MySQL: выбор API и соответствующий FAQ для получения более подробной информации. Альтернативы для данной функции:

mysqli_escape_string()
PDO::quote()

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

Отредактировано ladserg (22-01-2013 18:29:39)

Lain_13 · №566

Только вот PHP 5.5 ещё не существовал когда статья была написана. Впрочем, в MySQLi, на сколько я понял, наступили на те же грабли и эскейпить строку всё одно нужно.
Кстати, из спеки: mysqli_escape_string — Alias of mysqli_real_escape_string()

Отредактировано Lain_13 (22-01-2013 18:33:51)

krigstask · №567

ladserg пишет

Это я к тому что после этого все языки одинаковы, а вменяемость и отвратительность она от ЯП не зависит, если чел не способен нормально по-русски то изложить алгоритм, то и программу он напишет посредственную, в лучшем случае.

Хороший плотник может всё сделать одним топором, плохому не поможет и полный набор плотницких инструментов. Но из этого не следует, что без разницы, чем работать.
PHP — плохой, негодный инструмент. И если нелогичность и корявость описаны в руководстве, это не делает их логичностью и прямотой.

okkamas_knife пишет

ты начинаешь сравнивать промышленный карьерный экскаватор и обычный трактор с ковшом

Давайте-ка будем говорить по существу, а не погрязать в пучинах убогих сравнений. Я от них устал ещё во времена бразуерных войн.

krigstask пишет

Ещё раз поясняю: это никчёмная шляпа только для одминов топки локалхоста. Ни для чего серьёзного она не нужна и не удобна: разработка ведётся на чём-нибудь специальном, разворачивание в бой — на чём-нибудь мощном и рабочем. Я готов признать это лучшим решением для старшеклассника, которому нужно за пятнадцать минут развернуть «сервер» в сетке из трёх компов, чтоб перед пацанами попонтоваться, но не более того.

Повторяю: если критична скорость развёртывания этого всего комбайна, и только — ставьте и радуйтесь. Но это уровень админов локалхоста. Для реального применения это не подходит ну никак. И прежде чем рваться опять в сравнения типа «пушкой по воробьям», расскажи мне, для чего это может пригодиться. На деле. Ну, кроме как на форуме написать.

ladserg · №568

Lain_13 пишет

Только вот PHP 5.5 ещё не существовал когда статья была написана. Впрочем, там наступили на те же грабли и эскейпить строку всё одно нужно.

Зато существовал мануал. Ну судя по тому, автор считает обе функциями одинаковыми, то конечно одна из них у него будет работать не так как ему надо, т.к. они не разу идентичны.

А где не надо эскейпить plain-строку запроса для СУБД, можно указать такой ЯП?

Добавлено 22-01-2013 18:40:06

krigstask пишет

Хороший плотник может всё сделать одним топором, плохому не поможет и полный набор плотницких инструментов. Но из этого не следует, что без разницы, чем работать.
PHP — плохой, негодный инструмент. И если нелогичность и корявость описаны в руководстве, это не делает их логичностью и прямотой.

Приведи примеры нелогичности PHP и логичности того языка на котором пишешь веб-приложения ты сам. Ну и про корявости, описанные в руководстве, тоже хотелось бы уточнений.

Хочу обратить внимание, что язык программирования и его функции - это всё же разные вещи, glibc тому пример, библиотеки функций PHP можно можно подключить к питону или C/C++, вызывать их оттуда и так же плеваться.

Отредактировано ladserg (22-01-2013 18:41:07)

Lain_13 · №569

ladserg
На сколько я знаю Ruby это умеет делать правильно самостоятельно, без необходимости вызывать эскейп руками. Если пятый пых весь такой объектный, то что мешало сделать объект запроса, в который можно было бы передать строку запроса и отдельно параметры, которые в неё следует подставить? И чтоб этот объект самостоятельно сделал эскейп всем параметрам. Причём при правильной реализации это позволило бы использоваться идентичный запрос и передавать параметры самой базе - это позволяет базе повторно использовать план запроса вместо парсинга его каждый раз заново. Но нет, оказывается запрос нужно собирать руками самостоятельно и если не заэскейпил, то ССЗБ.

Отредактировано Lain_13 (22-01-2013 18:52:30)

ladserg · №570

Lain_13 пишет

ladserg
На сколько я знаю Ruby это умеет делать правильно самостоятельно, без необходимости вызывать эскейп руками. Если пятый пых весь такой объектный, то что мешало сделать объект запроса, в который можно было бы передать строку запроса и отдельно параметры, которые в неё следует подставить? И чтоб этот объект самостоятельно сделал эскейп всем параметрам.

А если почитать мануал?

mysqli::prepare, mysqli_stmt::bind_param и mysqli_stmt::execute.

Опять RTFM

Отредактировано ladserg (22-01-2013 18:53:42)

krigstask · №571

ladserg пишет

Приведи примеры нелогичности PHP и логичности того языка на котором пишешь веб-приложения ты сам. Ну и про корявости, описанные в руководстве, тоже хотелось бы уточнений.

скрытый текст

array_search, strpos и другие похожие функции возвращают 0, если находят вхождение на нулевой позиции, но false если не находят его вообще.

Дайте-ка мне чуть расширить последний пункт.
В C, такие функции как strpos возвращают -1, если элемент не был найден. Если вы не проверите этот вариант и попытаетесь использовать результат в качестве индекса, вы попадёте в мусорную память и ваша программа упадёт. (Скорее всего. Это же C. Хрен его знает. Я уверен, что для этого как минимум есть инструменты.)
В Python'е например эквивалентные методы .index бросят исключение, если элемент не найден. Если вы не проверите этот случай, ваша программа упадёт.
В PHP эти функции возвращают false. Если вы используете FALSE как индекс, или сделаете с ним почти всё что угодно кроме сравнения с помощью ===, PHP спокойно сконвертирует его в 0 за вас. Ваша программа не упадёт; она вместо этого будет работать неправильно без предупреждения, если конечно вы не забудете вставить нужный шаблонный код вокруг каждого места где вы используете strpos и некоторые другие функции.

ladserg пишет

А где не надо эскейпить plain-строку запроса для СУБД, можно указать такой ЯП?

Ну вот как сделано в psycopg2. Стрелять в ногу, конечно, можно, но сложнее, чем делать правильно, запомнив один раз.

Lain_13 · №572

ladserg
Оно работает с уже готовой строкой, которую ты должен подготовить сам или позволяет подставлять параметры? Если есть функция подстановки параметров - она выполняет эскейп самостоятельно?

А, сам нашёл mysqli_stmt::bind_param. Осталось понять эскейпит ли он.
...и всего этого не было в пыхе 4...

Похоже эскейпит самостоятельно.
Но при этом в том же самом модуле сделали: http://php.net/manual/en/mysqli.real-escape-string.php
Сделали функцию экейпа строк и возможность выполнять запросы в обход prepare() через query(). Причём даже показали как выстрелить себе в коленку этим способом и как этого избежать. Зачем он вообще нужен - загадка.
Причём помимо mysqli::query... они сделали ещё и mysqli::real_query.
Причём в случае query чем real_query отличается от query - загадка и мануал мне эту разницу понят не помог. Фейспалм.жпг.

krigstask
Там, кстати, специально для идиотов написали:
Warning Never, never, NEVER use Python string concatenation (+) or string parameters interpolation (%) to pass variables to a SQL query string. Not even at gunpoint.

Отредактировано Lain_13 (22-01-2013 19:19:20)

ladserg · №573

krigstask пишет

В PHP эти функции возвращают false. Если вы используете FALSE как индекс, или сделаете с ним почти всё что угодно кроме сравнения с помощью ===, PHP спокойно сконвертирует его в 0 за вас. Ваша программа не упадёт; она вместо этого будет работать неправильно без предупреждения, если конечно вы не забудете вставить нужный шаблонный код вокруг каждого места где вы используете strpos и некоторые другие функции.

Чего тут не логичного? В C так же надо проверять на значение -1, в питоне исключение не опишешь будет бяда, в PHP надо проверять на значение FALSE.

Всё вроде логично, сначала проверил найдено ли вхождение, а потом уже действуешь в зависимости от результатов проверки, или не?

Добавлено 22-01-2013 19:21:18

Lain_13 пишет

ladserg
Оно работает с уже готовой строкой, которую ты должен подготовить сам или позволяет подставлять параметры? Если есть функция подстановки параметров - она выполняет эскейп самостоятельно?
А, сам нашёл mysqli_stmt::bind_param. Осталось понять эскейпит ли он.
...и всего этого не было в пыхе 4...
Похоже эскейпит самостоятельно.

Чот фиг его знает на сей счёт, тоже присмотрелся к этому, может и не эскейпит ничего, а просто юзает API самого MySQL, в котором нет необходимости эскейпить параметры, т.к. они тупо вставляются как есть.

Lain_13 пишет

Но при этом в том же самом модуле сделали: http://php.net/manual/en/mysqli.real-escape-string.php
Сделали функцию экейпа строк и возможность выполнять запросы в обход prepare() через query(). Причём даже показали как выстрелить себе в коленку этим способом и как этого избежать. Зачем он вообще нужен - загадка.
Причём помимо mysqli::query... они сделали ещё и mysqli::real_query. Фейспалм.жпг.

Ну, типа - разные варианты .

Отредактировано ladserg (22-01-2013 19:21:18)

Dzirt · №574

Lain_13 пишет

А, сам нашёл mysqli_stmt::bind_param. Осталось понять эскейпит ли он.

Видишь ли, _параметры_ (те, которые задаются через ?) вообще не нужно эскейпить. То есть абсолютно Потому, что они параметры. И при таком использовании никакой SQL-инъекции не сделать в принципе. Только вот большинство кодеров на PHP об этом то ли не знают, то считают себя выше этого

Lain_13 · №575

ladserg
Питон упадёт без проверки, С выйдет за рамки массива и скорее всего скрашится, а если даже нет, то ему можно творить что угодно - это низкоуровневый язык и там полно таких моментов. Одно управление памятью чего стоит. Пых будет работать будто так и наужно и не скрашится. Программа будет работать _неправильно_, а не прекратит выполнение с ошибкой, как это сделает Питон, и в результате ты о наличии ошибки можешь никогда не узнать.
Неужели непонятно в чём проблема?
Я там выше уже приводил другой пример из статьи аналогично идиотского поведения пыха:

Или может ты объяснишь почему "133" == "0133", но 133 != 0133 и "0x10" == "16"? Мало того, что придурошный пых конвертирует строки в числа, когда его об этом не просят, так ещё и делает это не всегда правильно, а как бог на душу положит!

Почему он конвертирует строку с шестнадцатиричным числом в шестнадцатиричное, а с весьмеричным в десятичное? В этом нет ни логики, ни предсказуемости, ни, даже, смысла как такового. Зачем он вообще конвертирует строку в число если сравнивает её со строкой?!

Dzirt
Я там ниже написал уже. Там предусмотрен метод query (в двух непонятно чем отличающихся вариантах), который буквально специально придуман для того, чтоб стрелять себе в коленку и про который в документации не сказано, что им лучше не пользоваться и есть нормальный способы сделать то же самое. Разве что если комментарии почитать к документации (в частности к real_escape_string), то можно наткнуться на упоминание того, что лучше использовать prepare. Замечательно, самая важная информация не в самой документации, а в комментариях к ней.
И вся эта красота c prepare появилась только в пыхе 5.

Кстати, в примерах кода к query escape_string вообще не упоминается. Так что если программист искал как сделать запрос на базу и не вникал в подробности, то он возьмёт из документации худший вариант из всех возможных. Благо хоть в самом описании параметров функции об этом говорится и, опять же, в комментариях (!!!) есть ровно один пример кода с эскейпом.

Отредактировано Lain_13 (22-01-2013 20:08:04)

Полезная информация

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Re: Linux, Windows, Mac OS X - IX

Board footer