Как удалить winginx с компьютера

Обновлено: 07.07.2024

Тема этой статьи — локальные сервера. Расскажу о применении и удобстве использования. Порекомендую несколько популярных локальных серверов — Опен Сервер, Winginx, Денвер.

Если вы занимаетесь разработкой собственного сервиса или сайта, то совсем необязательно делать это «вживую» — покупать домен и хостинг. Также необязательно тестировать изменения функциональности или дизайна сайта в режиме реального времени, на работающем проекте.

Более того, у вас может быть нестабильный интернет или вы вообще не хотите выкладывать сайт в интернет, а сделать небольшой проект для себя или интранет… Все это можно сделать и на локальном ПК.

Но как? На этот вопрос отвечает локальный сервер, который избавит вас от всех вышеобозначенных проблем. Задача локальных серверов — обеспечить удобство работы с сайтами, предоставить возможность разработки на локальном ПК.

Локальный сервер — что это такое?

Локальный сервер — программа, создающая на вашем ПК среду полноценного веб хостинга.

То есть на вашем домашнем компьютере создается мини-хостинг, на котором будут успешно функционировать все серверные движки, скрипты, CMS (WP, Joomla и другие). Вам даже не нужно будет подключаться к интернету — у вас будет свой мини-интернет с одним или несколькими сайтами.

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

Большая часть сайтов современного интернета динамические и работают в основном на PHP. PHP также часто используется для обучения программированию. Но браузеры понимают только HTML и CSS, а PHP — нет. Потому что PHP это серверный язык программирования и сервер как раз преобразует и обрабатывает PHP-код (или результат его выполнения) в вид, понятный браузеру.

И такие обработчики стоят на каждом сервере/хостинге в интернете (без них никуда), но не на вашем домашнем компьютере.

Потребность в локальных серверах постоянно росла при разработке динамических сайтов на PHP, Перле и других языках программирования. Сначала это было обусловлено плохим и дорогим интернетом, затем люди поняли необходимость тестирования скриптов в специальной среде, да и вообще вырос любительский и профессиональный интерес к программированию.

Для полноценной имитации веб-сервера и решения всех вышеобозначенных задач и был создан локальный сервер.

Обычно эти проблемы решались, да и до сих пор решаются, средствами FTP-клиента. Вы скачиваете файл с веб-хостинга, редактируете его, закачиваете обратно, смотрите — работает как надо или нет. Если работает не совсем так, как предполагалось — повторяем процедуру.

Это как минимум неудобно — нужно быть постоянно подключенным к стабильному интернету, нужно ждать пока закачается обратно (файл ведь может быть большим, их может быть несколько), нужно постоянно редактировать файлы когда «что-то идет не так».

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

Сравните хотя бы URL при просмотре через веб-браузер:

Последний вариант не только более реалистичен визуально в строке браузера, но и корректнее обрабатывает HTML/CSS код (потому что код именно обрабатывается сервером, а не открывается для просмотра), подгружает все скрипты из интернета — без ошибок и накладок.

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

В своей вебмастерской практике я работал с Denwer, OpenServer и Winginx. Последними двумя периодически пользуюсь до сих пор — оба установлены на десктопе и запускаются по мере надобности.

Для чего? Например, для того чтобы создать на ПК за пару-тройку часов сайт-визитку на Вордпрессе. Или подготовить прототип сайта на HTML или WordPress — рабочая версия потом загружается в интернет и наполняется контентом.

Локальный сервер Denwer

Денвер (Denwer) — один из наиболее популярных локальных серверов.

Расшифровывается как «джентельменский набор веб-разработчика» — набор дистрибутивов и ПО для веб-разработки на локальном ПК.

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

Сразу после завершения установки локального сервера Денвера, вы сможете запускать и устанавливать движки своих веб-проектов на сервере «Апач». Работа с локальным сервером при этом ничем не отличается от работы с реальным хостингом.

Инсталлятор Денвера

Во времена Виндоус 95/98 приходилось тратить довольно много времени, чтобы пошагово вручную установить компоненты, входящие сегодня в инсталлятор Денвера. Сейчас этот кропотливый и трудоемкий процесс ушел в прошлое — автоматический инсталлятор, удобный конфигуратор и легкое обновление компонентов делают жизнь обычного пользователя во много раз проще.

Базовый пакет-инсталлятор Денвера включает в себя Apache (веб-сервер), интерпретатор PHP, базы данных MySQL и phpMyAdmin для управления базами данных, интерпретатор Perl, SSL, имитацию сервера электронной почты и т.д.

Денвер довольно компактный — если загружать дистрибутивы по отдельности, то получится примерно 40 мегабайт. Дистрибутив Денвера занимает в 5 раз меньше места — 8 мегабайт. Такая оптимизация была достигнута за счет того, что разработчики Денвера выбросили все лишнее (в том числе инструкции, мануалы) — оставили самое необходимое и пригодное для работы 90% веб-разработчиков и вебмастеров. Остальные 10% легко докачают недостающие пакеты при помощи встроенного инсталлятора.

В Денвере есть встроенная система управления хостами (виртуальными) на основе шаблонов. Создание нового хоста происходит через добавление новой директории в каталоге /home. При этом, есть поддержка названий директорий многих российских хостеров, что позволяет безболезненно переносить разработанный на локальном сервере проект на реальный вебхостинг.

Архитектура Денвера

Денвер полностью автономен. Вы устанавливаете его в выбранную папку, а за ее пределами Денвер ничего не трогает — не пишет файлы, не делает изменения в реестре Виндоуса. Запустили — работает, выключили — не работает и не оставляет следов после себя.

Технически, у вас даже есть возможность поставить два Денвера в две разных папки — локальные сервера не будут конфликтовать.

Денверу не требуется даже деинсталляция, если вы решили отказаться от использования локального сервера или перешли на другой — Open Server или Winginx. Удалите каталог (папку) Денвера — и готово. Точно также и с переносом на другие машины — переместите папку на другой ПК или на флешку. Денвер будет работать и там, с уже настроенной вами конфигурацией и пакетами расширений.

Изнутри Денвер похож на «маленький Unix» — на старте к основной директории прикрепляется папка на диске с расположением директорий как в Юниксе: /home, /usr, /tmp. Можно работать с обеими папками без замедления со стороны ОС.

На Блогворке уже публиковались статьи о Денвере, рекомендую вам с ними ознакомиться:

Установка Денвера ничем не сложнее установки обычной программы и проводится в 4 этапа, после прохождения которых можно работать с локальным сервером. Раз:

Локальный сервер OpenServer

Open Server (Опен Сервер) — программная среда, создающая портативную локальную серверную платформу.

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

Локальный сервер Open Server имеет:

Продуманный интерфейс пользователя;
Многофункциональные возможности по настройке встроенных компонентов и их администрированию;
Полноценный набор современного серверного ПО.

Вышеобозначенные достоинства, а также безотказная работоспособность делают из Open Server первоклассный и надежный инструмент для вебмастера и веб-разработчика. И действительно, Опен Сервером установлен и используется в реальном времени у десятков тысяч пользователей — об этом мы можем судить по счетчику на главной странице сайта, который колеблется в промежутке 10-20 тыс. пользователей.

А общее количество скачиваний дистрибутива неумолимо приближается к миллиону.

А все потому что связка компонентов для веб-сервера получилась не только легкой в использовании для пользователей Виндоуса, но и бесплатной, а также надежной — на уровне Линукса.

Предназначение локального сервера Open Server такое же как у Денвера и других локальных серверов — независимость от рабочего места.

Портативность сборки заключается в отсутствии необходимости заново устанавливать программы при смене рабочего места — достаточно подключить флешку или внешний жесткий диск с установленной и настроенной рабочей средой Open Server.

Я рекомендую использовать базовую версию Опен Сервера, которая является аналогом Денвера, Вертиго, Ксампа — содержит в себе только серверную часть, без дополнительных баз данных, Гита и программ для вебмастеров.

Вот сравнение версий Open Server:

А вот список программ в комплекте с ультимейт-версией Open Server:

Думаю 10% из них уже есть на вашем компьютере, а недостающие всегда можно поставить самостоятельно.

Как выглядит меню программы:

Я оцениваю Open Server как незаменимый инструмент для вебмастера любой квалификации. Удобство работы с ним и его полезность сложно переоценить. Взгляните хотя бы на меню настроек — все просто и понятно:

Мне нравится этот локальный сервер, рекомендую и вам.

Локальный сервер Winginx

Winginx — локальный веб-сервер для разработки на языках программирования PHP и даже Node.js. В Winginx встроены БД — MongoDB, Redis, memcached, MySQL.

Особенностью Winginx является встроенный сервер nginx, а не Apache как на других локальных серверах.

Быстрый и простой запуск локального сервера nginx на ОС Виндоус;
Удобная локальная разработка сайтов и сервисов на Node.js и PHP;
Мультипроектная система для разработки, имеющая универсальные и гибкие настройки, легко обновляющиеся компоненты;
Среда для ведения проекта — можно создавать задачи и учитывать время на их выполнение;
Среда для локального тестирования и запуска, веб-приложений, сайтов и браузерных сервисов;

Особенности Winginx по сравнению с другими локальными серверами: единый центр управления сервером и обновлениями компонентов, одновременная мультипроектная работа с несколькими сайтами (в т.ч. используя разные версии PHP), управление задачами и проектами, учет времени на выполнение задач, загрузка бесплатных CMS из магазина Winginx и их установка «в 1 клик».

Серверный менеджер и центр обновления Winginx

Winginx не нагружает локальный компьютер, незаметно работая в трее. Если вы кликните на иконку Winginx — отобразится единый центр управления сервером. В нем вы сможете остановить или запустить сервер целиком или его отдельные компоненты.

В новой версии Winginx есть контекстное меню. Ребята разработчики упростили его, чтобы пользователям было проще вводить быстрые команды.

Центр обновления в Winginx следит за актуальностью серверных компонентов. Если нужно поставить дополнительные компоненты или обновить устаревшие — центр обновлений решит эту проблему. Причем работает он автоматически — при запуске проверит, не нужно ли чего обновить и, если нужно, уведомит вам об этом. Вам остается лишь согласиться (или нет).

Но не беспокойтесь об автоматических обновлениях, которые могут нарушить работу вашего локального проекта — «само» ничего не установится и не обновится. Только с вашего согласия.

Управление проектом и задачами в Winginx

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

Задачи в менеджере имеют приоритеты (от 1 до 5), цветовые ярлыки, статус, описание, срок. Статусов всего 6 — на паузе, в работе, открыто, закрыто, идея, выполнено.

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

Вишенкой на торте является возможность держать необходимую документацию проекта всегда под рукой: ТЗ, договор, прототип, мокап и пр.

Учет потраченного времени на разработку

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

Магазин веб-приложений Winginx

В Winginx также встроен т.н. «Магазин». Это панель, которая предлагает загрузку и установку популярных движков сайтов.

На данный момент это наиболее популярные блоговые CMS, движки типа «Вики» и некоторые фреймворки для веб-разработки:

Вы выбираете движок, он загружается и устанавливается в выбранную папку (можно использовать уже настроенный домен или создать новый), затем запускается мастер установки движка, ну и дальше все просто. Пятиминутная установка Вордпресса и все такое.

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

Еще мудрейшие греки говорили: «Если ты хочешь быть сильным — делай бекапы, хочешь быть красивым — делай бекапы, хочешь быть умным — делай бекапы».

Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.

Только это вина не Windows Vista и последующих версий, а вина архитектуры NGINX. Еще с древних времен писалось, что не стоит работать с абсолютными адресами в разделяемой памяти, только смещения и тут никаких проблем и не было бы даже.

Кто-то где-то говорил обратное? Вопрос на самом деле филосовский, и я подозреваю, что оно даже реализуемо «смещениями», но вероятно с небольшой потерей производительности (просто поверьте) и многимя-многимя правлеными строчками кода (такой коммит-убийца, за который вам отдельное спасибо скажут владельцы кастомных сборок и разрабы foreign-модулей)… Как-то так. Такой коммит-убийца — хороший кандидат на включение в версию 2.0, в которой, наконец-то, можно будет что-нибудь сломать, но сделать всё-таки правильно.

Вам бы все чё-нибудь поломать… :)

А так-то да. Я вот как-то переписывал хэш-таблицу для работы на shared mem (с указателей на смещения) — сплошной позитив знаете ли в воспоминаниях.

Вообще, если используются smart pointers, то переделка вполне себе может крайне простой — заменой штатного на нештатный.
Интересно даже, а в бусте нет готового? Есть как бы относительная адресация. Да и сравните скорость обращения к памяти и работу сети, тут разница настолько велика, что на потери при работе с памятью можно закрыть глаза.

15ГБ/сек, а DDR4 даёт только

30ГБ/сек. Не такая и большая разница, согласитесь? И 100GBit Ethernet уже на подходе…

Конечно это скорее не для NGINX'а задачки, а для всяких кластерных RPC, но про то, что «сеть — это что-то такое мееедленое-мееедленное» пора забывать. Задержки в сети — да, они чудовищные, тут природу не обманешь, а вот пропускная способность — совсем другое дело, за этим нужно очень и очень следить.

30ГБ/c это один канал, соответственно для 4х каналов 120. Пока еще порядок разница.

Это правда, конечно, но вот только просрать разницу «в порядок» накрутив пяток уровней абстракции можно с лёгкостью неимоверной.

А так да — запас ещё есть. Иначе бы и со 100GBit Ethernet'ом заморачиваться бы не стоило :-)

… на винде? :)
Тут даже под linux начнутся муки раскидывания прерываний по ядрам.

На винде — не видел, врать не буду. На Linux — бывает вполне реально в кластерах. Для раздачи статики подобную конфигурацию, понятно, никто использовать не будет.

Очень даже можно, если правильно тюнить систему.
Вот неплохой пример отдачи статики на 80 Гбит/с.
Лично мне кажется, в windows на таком же железе результат будет меньше.
В том числе, из за только одного select в nginx под windows.

На *NIX, где в качестве основного способа порождения дочернего процесса используется fork(), копирующий все адресное пространство — абсолютные адреса в разделяемой памяти являются совершенно нормальным явлением.

Вам не кажется, что обвинять *nix-сервер в том, что его изначально не подготовили для работы под виндой — несколько странно?

На самом деле это не правда, вернее не совсем правда — nginx с незапамятных времен можно было собрать под Windows без этого ограничения — нужно было просто на этапе сборки определить FD_SETSIZE равным нужному вам количеству соединений.

То есть с IOCP он работать не умеет, может только косплеить слоупока работая через select? По моим последним данным (возможно устарело) — It's incomplete and doesn't work.
Если все-таки да, то вероятно это будет следующее за что возьмусь, если (когда) будет много время (улыбаясь сквозь зубы)… Без IOCP это не особо и прорыв на мой вкус. Всё же IOCP это как раз high-performance networking который nginx`у как воздух нужен. Ну как бы в корпоративном секторе, да под win (ntlm и иже с ним), часто длинный keepalive — поэтому по поводу медленного select я не очень страдаю, главное что хоть все воркеры — наконец воркают…
Про прорыв же — что вы, я без каких либо претензий — фикс он фикс и есть. Да я только за вообще. Хоть так.
Под IOCP придётся по другому делать. Он же с пулом потоков работает, значит количество воркеров будет количеством активных потоков в пуле. Всё остальное будет система делать. С каких пор IOCP работает с потоками пула? Он «работает» в том потоке, который вызвал GetQueuedCompletionStatus. Возможно, вы путаете поведение IOCP с поведением Overlapped IO без использования IOCP? Думаю crea7or имел ввиду, что IOCP больше для потоков (threads), чем для процессов (process). Что, не совсем «кошерная» технология для nginx, хотя… будем посмотреть. И что же мешает применять эту технологию с процессами, а не с потоками? Ну да, будет не один порт создан, а по числу процессов. Ну так ведь и проблема распределения сокетов по процессам уже решена… На мой взгляд, достаточно сложно ответить на этот вопрос в целом, но подозреваю, что реальный выигрыш на windows будет только действительно на пуле потоков. Ну или комбинировано — N worker process x M worker threads.
Вероятно IocpPoller все-таки реально сварганить с наследованными сокетами, но боюсь overhead на проброс completion события в другой процесс может скушать часть профита. Интересно конечно насколько, вот поэтому и сложно ответить.

Зачем пробрасывать? Можно же в каждом процессе создать свой порт, и связывать «свои» сокеты только с ним.

Проблема будет только с AcceptEx — но соеднинения все-таки устанавливаются не так часто, как через них передаются данные.

Так некто и не хочет…
Просто речь-то про пул потоков vs. пул процессов. Весь выигрыш completion port именно в асинхронном распределении по пулу (потоков).
(Например, один из важнейших управляющих параметров для эффективной работы IOCP — NumberOfConcurrentThreads.)

А то что я имел ввиду — как оно там внутри Windows будет «проброшено» до унаследованного сокета.

В первую очередь преимущество IOCP — в отсутствии необходимости каждый раз сначала формировать FD_SET из 10240 элементов, потом внутри windows его еще и обходить — а после любого принятого байта начинать все заного.

Если сокеты уже распределились по пулу процессов — зачем их потом еще и по пулу потоков раскидывать? Понятно что общий пул потоков даст чуть более равномерную нагрузку на ядра, чем пул процессов с отдельными сокетами (но потребует чуть больше накладных расходов на синхронизацию) — но этот вопрос не имеет никакого отношения к IOCP. Это применимо и для select, и для epoll.

PS а NumberOfConcurrentThreads в nginx, очевидно, будет равен 1

Всё равно переделывать много, так может сразу как надо под платформу соорудить? Работу с диском тоже на IOCP завести и вообще будет зашибись. Ну да, потоки в пуле будут обрабатывать завершение вв, но они же вместе работают с IOCP. Завершение ввода-вывода в случае использования IOCP обрабатывает программист, там где хочет. Само собой, оно не само в пуле работает. Но по дизайну должно работать с пулом. Так через IOCP всё надо делать и не нужны никакие REUSE. Спасибо, почитал. Но, проблема в том, что IOCP рассчитано только на треды. SO_REUSEPORT позволяет работать в виде нескольких процессов. Я понимаю, что «а нефиг писать однопоточные приложения», но в существующем приложении с однопоточной обработкой прикрутить SO_REUSEPORT и запуск нескольких копий проще, чем переделывать всё приложение на треды. Переделывать конечно сложнее. Так IOCP не на это рассчитан, а чтобы сразу писали с его поддержкой. Это плохой вариант для портирования, но уж что есть. Опять же быстрее потоками, чем процессами (хоть и не так безопасно в свете текущей моды на процессы). Я сам не замерял, но вот тут с epoll сравнивают — всё же в ядре. Хотя конкретно с nginx может быстрее особо и не будет (потоки <> процессы). Там если через шаред память перекидывается, то не сильно и медленнее будет одного адресного пространства. Разве что меньше переключений контекста. А ради интересу, до модификаций 1*5 и после 1*5 отличаются или нет? Вообще не заметно, т.е. все в рамках погрешности — раз чуть быстрее, раз чуть медленнее.
Иначе, я бы сразу это отключаемо сделал (или в случае 1 worker — по старому, без наследования) Хотя может для совместимости все-таки будет лучше так и сделать (в случае только 1 worker). Нет, не стоит так делать, ибо это сломает возможность «на лету» смены числа воркеров. Вовсе нет, при смене на лету — процессы перезагружаются, т.е. весь алгоритм, описанный в статье, повторяется сызнова… Прикрутил таки (проапдейтил на github и сбросил коммит changeset-ом в nginx-dev).
Теперь в случае «1 worker» все работает как раньше.

А как же сборка от nginx-win.ecsds.eu в которой и Fully ASLR and DEP compliant for shared memory и Select-boost и Multiple workers supported и FD_SETSIZE = 32768 и многое другое…

Вот полный список возможностей этой сборки:

Или несколько человек делают дурную работу делая одно и тоже… или я чего-то недогоняю? Может разработчикам Nginx подсмотреть что и как сделано в этой сборке?

~~это опенсорс детка ©~~ а по делу — то что для вас «тратить человекоресурсы», для меня хобби — я это делаю с удовольствием.
А упомянутые вами люди для меня сродни ну например фирмы Apple — я лично просто не собираюсь иметь с ними дела. За nginx не скажу, это повторяю от меня лично. Еще раз спасибо за такое прекрасное хобби! Наконец-то в оригинальном Nginx за столько лет при полном безразличии разработчиков к Windows платформе можно увидеть реальные перемены в лучшую строну. Причём значительные перемены. Надеюсь ваш пул-реквест насчет воркеров очень скоро станет частью Nginx. Успехов!

при полном безразличии разработчиков к Windows платформе

Ну как бы: раз — это совсем не правда, два — а они и необязаны.

А упомянутые вами ~~редиски~~ люди… По мне как, весь смысл в nginx — только когда он опенсорсный, чтобы значит можно было тупо глянуть в исходники (если что-то где-то непонятно), или чтобы что-то где-то подкрутить, или пересобрать с другим модулем или вообще куском «ядра» и т.д. Да много чего можно.

Ну тогда я не знаю как по другому объяснить многолетнее отсутствие подвижек в сторону Windows.

А кто говорил что обязаны? Я лишь сказал что они безразличны к Windows платформе. Пусть вы и утверждаете обратное (поскольку более тесно с ними общаетесь), но слова это одно, а дело другое. На деле всё это висело мёртвым грузом много лет. Впрочем когда появилась сборка от nginx-win.ecsds.eu жить стало проще, жизнь стала веселей :-)

он опенсорсный, чтобы значит можно было тупо глянуть в исходники (если что-то где-то непонятно)

«Тупо глянуть в исходники» не получится, Nginx крайне тяжелый для понимания и редкий программист сможет разобраться в его коде и уж тем более сам что-то дописать. Это уже не раз обсуждалось и об этом все знают. Поэтому меня всегда умиляют ссылки на open source, мол если нужна поддержка Windows — возьмите и допишите.

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

Я не люблю людей (по этой же причине например и фирмы как Apple), которые делают профит на базе чего-нибудь из opensource, при этом сами его не развивают или делают это в незначительной степени (тупо спрятав «исходники»). Ну как бы у меня на этой теме «когнитивный диссонанс» что-ли… и это дело принципа.

А вот вы лично, почему-то предъявили «претензии» разрабам nginx, да и мне или другим из коммюнити в том числе («не развивают nginx4win», «несколько человек делают дурную работу делая одно и тоже», «связался бы с командой» и т.д.), а почему-то не «команде» из ecsds.

Nginx крайне тяжелый для понимания и редкий программист сможет долететь до середины Днепра .

Неправда ваша, я знаю очень много людей (не из команды nginx) легко могущих прочитать его исходники.
А даже если и не все могут — это ничего не меняет. Сам принцип важен… имхо.

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

А вот вы лично, почему-то предъявили «претензии» разрабам nginx, да и мне или другим из коммюнити в том числе («не развивают nginx4win», «несколько человек делают дурную работу делая одно и тоже», «связался бы с командой» и т.д.), а почему-то не «команде» из ecsds.

Простите великодушно, но где вы увидели претензии? Мне процитировать еще раз дословно чтоль свои же слова? Я лишь сказал о том, что на ИХ месте я бы постарался связаться с командой из ecsystems.nl и выкупить или просто получить эти исходники. Вдруг ребята из ecsystems.nl готовы отдать их просто так лишь бы они НЕ легли мёртвым грузом на много лет, а были реально включены в Nginx?

Если уж вы заговорили про команду ecsystems.nl, то хочу вам сказать что в группе рассылки Nginx сидит человек из этой команды и пытается общаться и на английском и на ломаном русском, видимо через Google Translate. Понятия не имею как всё обстоит на самом деле, но вы не предполагали, а может не от хорошей жизни ребята из ecsystems.nl начали сами допиливать Nginx?
Может именно потому что разработчики Nginx никак не развивали свой продукт в этом направлении эти ребята и приложили свои усилия к тому чтобы допилить Nginx до нормального рабочего состояния под Windows.

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

У вас на это своя точка зрения, у меня своя. Думайте как хотите, я вас переубеждать не собираюсь.

Не хочу ничего утверждать, но я не уверен что они их прячут

Зачем тогда нужно предлагать «сборку на заказ» (что они и делают)?

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

Я про-то, что «зарабатывая деньги» на опенсорсном продукте (не важно как) они его развивали только для себя, ну или для своих клиентов, если хотите. Мне очень не нравится сам этот факт. Я же это делаю для пользы всех, и своей в том числе…

Я вам пример приведу: есть опенсорсная финтифлюшка X (всем миром разрабатывающаяся), фирма F изменив в X чуть-чуть (пару процентов) сделала продукт X2, при этом даже периодически перенимая все изменения и новшества из X (каждый релиз).
Зарабатывая на X2 (а в моей реальности в большей степени на X), они никоим образом не поспособствовали развитию самого X (ну или в несоизмеримо малой степени). Имеют они на то право — возможно. Должен ли я их за это «уважать» — имхо, нет. Ну вот нет и все тут.

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

Да поймите же вы, они ничего не зарабатывают конкретно на opensource, они зарабатывают на поддержке. Не важно какой и не важно чего, просто на поддержке своих клиентов, обработке их тикетов, настройке их серверов и проч. Сделанные ими изменения в коде никакого профита им не приносят и бинарники распространяются бесплатно. С таким успехом можно обвинить любого хостера который использует бесплатный Mysql для своих клиентов (не важно с доработками или без) в зарабатывании денег. Ну бред же.

По факту ECSystems продает услуги по поддержке Windows серверов и сборке Nginx с нужными модулями и часть этих денег жертвует команде, которая и осуществляет доработку Nginx под Windows.

OK не будем спорить :-) Я понял что вы их не уважаете, потому что свой вклад в opensource они пока не внесли.

Но ведь это только пока? По поводу исходников у них в FAQ написано что пока не выкладывают, т.к. проект не готов. Да и какой смысл их прятать, если бинарники и так бесплатные? Т.е. как только будет доделано то что указано в TODO ниже, можно ожидать появления исходников. Будем надеяться…

— ldap / ntlm
— allow multiple instances to run on the same machine
— More non-blocking Lua, event based DLL add-on’s like pagespeed, SharePoint, asp/dotnet.
— Full 64 bit builds.
— IO event and thread separation (60% completed).
— Distributed IO and CPU event processing (we have a working proto type).

Winginx — локальный сервер, с помощью которого можно быстро создать сайт на своем компьютере. Скачайте дистрибутив и запустите программу-установщик. После установки ПО нажмите на иконку Winginx в трее и включите компоненты программы.

Перейдите по ссылке «Рабочая среда Winginx», чтобы вызвать панель управления программой. Создайте новый проект и укажите адрес экспериментального сайта.

Перейдите в панель управления phpMyAdmin с помощью меню «Менеджеры баз данных – phpMyAdmin». Создайте базу данных экспериментального сайта.

Откройте папку сайта с помощью соответствующего меню в панели управления Winginx.

Разархивируйте дистрибутив выбранной CMS в каталог public_html.

Введите в адресную строку браузера адрес wp-admin/install.php и установите движок на сервер.

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

Как перенести действующий сайт на локальный сервер

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

Скачайте созданные пакеты на жесткий диск компьютера. Перенесите их в корневой каталог ресурса на локальном сервере.

Введите в адресную строку браузера путь к файлу installer.php на тестовом ресурсе. Вы попадете на страницу установки базы данных.

Удалите из корневой директории тестового ресурса файлы install.php и wp-config.php.
Укажите имя пользователя и название базы данных экспериментального сайта. Отметьте, что вы прочитали техническое предупреждение и запустите установку копии ресурса на локальный сервер. Запустите установку.

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

Вы можете перенести сайт с сервера хостинг-провайдера на экспериментальный ресурс на локальном сервере без помощи плагинов. Для этого можно воспользоваться функцией «Экспорт» в административной консоли.

С помощью функции «Импорт» можно загрузить полученный файл на локальный сервер.

Что делать, если вы не пользуетесь WordPress? Вот универсальный способ переноса ресурсов. В панели управления phpMyAdmin выберите базу данных экспериментального сайта. Укажите обычный способ экспорта, при котором отображаются все настройки. Выберите метод сжатия gzip. Не меняйте другие настройки. Запустите экспорт БД.

Браузер загрузит на жесткий диск ПК файл с расширением sql.gz. Его необходимо импортировать на сервер хостинг-провайдера. Для этого в панели управления сервером выберите меню «Базы данных – phpMyAdmin».

Описанными способами сайты можно переносить с локального сервера на сервер хостера и в обратном направлении. Также для создания копии ресурса и последующего переноса вы можете воспользоваться инструментами резервного копирования базы данных, например, плагином для WordPress WP Database Backup или аналогами для других движков. Если вы пользуетесь WordPress и локальным сервером Desktop Server, перенести локальный сайт можно с помощью плагина Desktop Server for WordPress.

Информация была тебе полезной? Поделись с друзьями, не будь жадиной 😀

Готовый бизнес без вложений

Деньги уже в 1й месяц, выход на >100.000 ₽/мес пассивного дохода в течение 12 мес

Автор: KalininLive

Локальный сервер Denwer

Одно и самых известных и простых решений для размещения сайтов, в том числе и на базе WordPress, в интернете.

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

Выбираем директорию установки;

Выбираем виртуальную директорию (например Диск L);

Режим запуска утилиты;

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

Локальный сервер Winginx

После этого нужно, как и в стандартных программах пройти простую процедуру установки.

Запуск файла setup:

Принимаем лицензионное соглашение. Выбираем папку на компьютере, где будет храниться программа:

Как только установка будет завершена на компьютере можно будет увидеть значок ххххх в панели инструментов.

Основными преимуществами использования именно этого ПО являются:

Использование PHP 7;
Простота работы с базами данных и файлов;
Не создаёт отдельный жёсткий диск (экономит место);
Имеется возможность запуска отдельно баз данных или виртуальной машины на выбор;
Имитация доменного имени.

WordPress на локальном сервере — установка, перенос

Далее, нужно создать отдельную папку в директории \Winginx\home, с названием будущего сайта, например test.local. Также следует создать в папке домена новую директорию public_html, по которой будет отображаться сайт.

Далее посещаем каталог \Winginx\, где нужно найти утилиту hostseditor.exe. В ней можно будет создать новый домен, а также задать IP-адрес, по которому оно будет отображаться. Для этого нажимаем на кнопку добавить и в поле «Имя домена» прописываем название будущего сайта, при этом нет необходимости прописывать оставшиеся поля, так как они по умолчанию настроены на используемый компьютер.

Теперь потребуется разархивировать папку с файлами WordPress в public_html. Как только разархивация будет выполнена можно будет запустить виртуальную машину, нажав на клавишу “запустить все”.

По умолчанию доступ к базе данных имеет всего 1 пользователь с логином root и заданным при создании паролем.

Если необходимо создать еще пользователей используем соответствующую для этого кнопку.

Теперь можно приступать непосредственно к установке самого WordPress. Для этого заходим на сайт test.local/ (или другой если Вы создали домен с собственным названием).

Далее заполняем все требуемые поля для подключения и работы Вордпресса:

Имя базы данных, которое мы создали в PHPMyAdmin
Имя пользователя, у которого есть доступ к базе данных (по умолчанию root)
Пароль от доступа данного пользователя (по умолчанию пустое поле)
Сервер базы данных localhost
Префикс таблицы лучше всего остается таким же «wp_»

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

Теперь потребуется ввести данные для доступа в CMS, куда включаются:

Название сайта (можно будет сменить в дальнейшем);
Имя пользователя (лучше всего использовать admin);
Пароль (генерируется самостоятельно или задается отдельно);
Ваш email.

Все готово сайт готов к работе:

Заключение

Использование локального сервера при разработке сайтов на WordPress позволит:

Уменьшить риск ошибки при изменении функционала, а также проводить тестирование в безопасной среде;
Создать и скорректировать новые файлы на ПК, а уже после проверки работоспособности залить их на сервер;
Набраться опыта при работе с данной CMS. Так, начинающие разработчики могут проверить свои силы на реально существующих проектах, сохраняя копии через ftp.

Используя современное ПО и мощности домашнего ПК появиться возможность проверить парсер, скрипты, генераторы и многие другие полезные атрибуты современного сайта. Также следует понимать, что созданный на локальном компьютере сайт на WordPress ничем не отличается от размещенного на виртуальном хостинге.

Читайте также:

Как удалить winginx с компьютера

Локальный сервер — что это такое?

Локальный сервер Denwer

Локальный сервер OpenServer

Локальный сервер Winginx

Как перенести действующий сайт на локальный сервер

Готовый бизнес без вложений

Автор: KalininLive

Похожие публикации

Локальный сервер Denwer

Локальный сервер Winginx

WordPress на локальном сервере — установка, перенос

Заключение