Ну что ж вы так сразу? Достаточно для начала грохнуть процесс chrome с максимальным pid (если конечно это было в последней открытой вкладке). Скорее всего поможет и вместо вкладки с окном скрипта будет что-то типа этого.
На линуксе еще всегда можно уйти в глухую консоль и сурово выполнить kill -9. Можно еще xkill на хоткей подвесить, только не знаю, что именно он покосит — скорее всего, весь хром.
Прочитал статью и решил, что, пожалуй, таки не стоит. Если уж сильно приспичит, лучше часть функционала на голых сях напишу, со всякой низкоуровневой магией.
Ну, Эппл к Адобу не пойдет, у них принцип другой — «кто захочет — сам придет». Мелкософт вон вообще до недавнего времени все устраивало и без магазинов, типа попадает в систему софт каким-то образом — и ладно. Честно говоря, лично я бы всем этим тоже не стал бы заниматься, остановившись на первом шаге. Думаю, что товарищи из OneGet тоже до Адоба и прочих монстров докапываться не будут, а мелкие разработчики сами к ним побегут.
А если посмотреть с другой стороны — тот же стим, например, живет и процветает, а ведь туда свои игрушки тащат даже крупные разработчики. Видимо, вопрос как раз в соотношении возможных потерь и потенциальной прибыли, голая экономика и ничего более.
В принципе, я над этим думал, тема довольно-таки скользкая. Я для себя вижу следующий вариант развития подобных менеджеров:
1. Берем кучу открытого и бесплатного софта, который мы можем добавить в репозиторий, договорившись с разработчиками (или вообще их не трогая).
2. Набираем пользователей (не очень быстро, так как самых смачных плюшек типа того же Адоба у нас нету)
3. Добавляем систему платежей.
4. Когда (а точнее, если) все это более-менее разрастется, идем к серьезным людям типа Адоба и говорим: «Вот, у нас есть такая классная штука, и у нас уже есть пользователи. Мы можем добавить Ваш продукт, если Вы сделаете нам специальный пакет, который мы сможем положить в наш репозиторий». Далее все зависит от того, какие для них будут затраты на создание этого пакета, и какая потенциальная прибыль от продажи через наш репозиторий.
А сам-то я хотел делать репозиторий именно для opensource софта, просто чтобы не надо было постоянно искать сборку под винду какого-нибудь sqliteman или выкачивать себе на разные машины libreoffice и следить, чтобы он всегда был свежий. Я для этого слишком ленивый. Идея именно развести микролинукс в винде, когда весь крупный проприетарный софт ставится своими инсталляторами, а всякие бесплатные ништяки ставятся и обновляются через единую утилиту. Ну и вопрос с библиотеками тоже решается, когда какой-нибудь толстый boost не надо с каждой отдельной софтиной таскать.
Эх, запороли мне всю малину. Я только хотел начать свой костыль менеджера пакетов под винду писать, а тут, оказывается, уже все сделано, и даже работает :'(
Можно пока начать с opensource софта, который можно перед сборкой пропатчить для «наступления коммунизма». А там уже и коммерческий подтянется. По крайней мере, мы на первой стадии уже получим некий аналог обычного линуксового репозитория.
Можно сделать следующую схему: отгаданная капча не убирается до тех пор, пока не запускается генерация новых капч. В процессе генерации старые капчи (отгаданные и просто просмотренные) удаляются и заменяются новыми. Таким образом допускается повторное появление капчи в течении дня, и при этом гарантировано не придется днем генерировать новые капчи. Зато ночью все использованные капчи удалятся.
Ну, насколько я помню, интерпретатор там полноценный, может, нет только каких-нибудь библиотек. Я бы сделал так: задаем программу строительства как описание слоев блоков в псевдокодах (например, слой — матрица чисел, каждое из которых представляет определенный тип блока), затем пишем на lua же интерпретатор, который переводит этот псевдокод в команды робота. Далее скачиваем готовую программу строительства для нужного устройства, передаем интерпретатору и запускаем робота. Программу же просто один раз кто-то делает, а дальше она распространяется в виде обычного файла.
Я вот подумал — если установить мод, добавляющий в игру программируемых на языке lua роботов, то можно для них написать программу для изготовления такого блока. В результате получится фабрика по производству ПЗУ, жаль только, что продавать некому. Зато можно с помощью разных lua-программ создавать разные устройства, а потом соединять их в большие комплексы, как конструктор.
Господа, это же было гениальнейшее решение — вынести рекламу в отдельное окно, чтобы ее можно было вместе с этим окном заблокировать. Да ему за это спасибо сказать стоит!
Ну, тут можно поэкспериментировать с gdb, попробовать собрать самостоятельно или где-нибудь найти уже собранный, может кто-то этой проблемой уже заморачивался. Главное, что Creator позволяет без извращений подменить один gdb на другой, что дает простор для творчества.
З.Ы.
Например, вот здесь есть статейка, в конце которой упоминается собранный gdb с поддержкой arm и python, можно его попробовать.
gdb в них собран без поддержки Python'а, что делает невозможной отладку через QtCreator
Я с этой проблемой столкнулся, оказалось, что она решается очень просто и быстро. Как правило, под разные системы (ту же винду, в частности) есть собранные версии gdb с поддержкой python (например, под ту же винду есть собранный gdb на сайте qt-project http://download.qt-project.org/official_releases/gdb). А в настройках комплекта в QtCreator можно этот отладчик явно указать. Profit!
Прочитал статью и решил, что, пожалуй, таки не стоит. Если уж сильно приспичит, лучше часть функционала на голых сях напишу, со всякой низкоуровневой магией.
А если посмотреть с другой стороны — тот же стим, например, живет и процветает, а ведь туда свои игрушки тащат даже крупные разработчики. Видимо, вопрос как раз в соотношении возможных потерь и потенциальной прибыли, голая экономика и ничего более.
1. Берем кучу открытого и бесплатного софта, который мы можем добавить в репозиторий, договорившись с разработчиками (или вообще их не трогая).
2. Набираем пользователей (не очень быстро, так как самых смачных плюшек типа того же Адоба у нас нету)
3. Добавляем систему платежей.
4. Когда (а точнее, если) все это более-менее разрастется, идем к серьезным людям типа Адоба и говорим: «Вот, у нас есть такая классная штука, и у нас уже есть пользователи. Мы можем добавить Ваш продукт, если Вы сделаете нам специальный пакет, который мы сможем положить в наш репозиторий». Далее все зависит от того, какие для них будут затраты на создание этого пакета, и какая потенциальная прибыль от продажи через наш репозиторий.
А сам-то я хотел делать репозиторий именно для opensource софта, просто чтобы не надо было постоянно искать сборку под винду какого-нибудь sqliteman или выкачивать себе на разные машины libreoffice и следить, чтобы он всегда был свежий. Я для этого слишком ленивый. Идея именно развести микролинукс в винде, когда весь крупный проприетарный софт ставится своими инсталляторами, а всякие бесплатные ништяки ставятся и обновляются через единую утилиту. Ну и вопрос с библиотеками тоже решается, когда какой-нибудь толстый boost не надо с каждой отдельной софтиной таскать.
З.Ы.
Например, вот здесь есть статейка, в конце которой упоминается собранный gdb с поддержкой arm и python, можно его попробовать.
Я с этой проблемой столкнулся, оказалось, что она решается очень просто и быстро. Как правило, под разные системы (ту же винду, в частности) есть собранные версии gdb с поддержкой python (например, под ту же винду есть собранный gdb на сайте qt-project http://download.qt-project.org/official_releases/gdb). А в настройках комплекта в QtCreator можно этот отладчик явно указать. Profit!