All streams
Search
Write a publication
Pull to refresh
11
0
kodx @kodx

User

Send message
Amazon Kindle начиная с версии 3 имеет экран Pearl.
Версия 3g keyboard имеет на борту безлимитный и бесплатный интернет по всему миру, да еще и возможность работы по WiFi, более удобное управление (большие кнопки перелистывания по бокам, вместо мелких внизу) и нормально работающую прошивку. Amazon выдает специальный адрес email при регистрации, на который можно посылать книги в разных форматах, он сам сконвертирует их в нужный формат и закачает на читалку по WiFi, куда удобнее, чем возиться с этим самому(а можно и по 3G, но это будет стоить денег).
Можно даже хакнуть устройство и поставить читалку которая будет читать все, устройство точно также видится как носитель информации в разных ОСях.
Стоимость у Kindle 3G Keyboard вместе с доставкой из Америки около 160$. С учетом всех этих плюсов — читалки местных и ближайшего зарубежья (Украина) производителей смотрятся жалко. Если народ, купив LBook потом еще полгода боролся с неработающей прошивкой, то в Kindle все сразу работает, даже не возникает желания что-то хакать.
Вот только эта база geoip не всегда актуальна. К примеру судя по большинству сайтов я уже много где побывал, и в Германии и в Сибири, да куда меня только не заносило, хотя живу в центре России. Просто провайдер все время покупал разные диапазоны ip адресов, которые раньше принадлежали другим провайдерам.
Если использовать мобильный интернет, то вообще может определить соседний регион, ни разу не было так, чтобы по этой базе попал именно тот регион, откуда я выхожу в интернет.
Так что все эти определялки, лично для меня, ничего не значат и зачастую — только мешают.
Не уверен, что такое возможно сделать с помощью Xmodmap. Советую заглянуть на LOR Wiki ( www.linux.org.ru/wiki ), там может быть совет, как сделать подобное. Либо спросить на форуме того-же сайта.
Для xserver давно уже существуют xbindkeys и xmodmap, с помощью них можно переназначить любые клавиши (из тех, которые сама система может видеть) на что угодно да еще и запуск нужных программ сделать. Статей полно.
Сам имел опыт работы с большими проектами и вышло так, что пока проекты небольшие то на средах типа Eclipse оно делать действительно проще. Но чем больше число файлов в проекте, чем больше растут исходники, тем все труднее таким монстрам это дело переваривать, и простое открытие файлы занимало по 5 минут, потому что ему надо проиндексировать большое количество инклудов. А в больших проектах работает, обычно, не один разработчик и исходные тексты меняются очень быстро.
Лично я считаю, что autocompletion только вредит, без него разработчик лучше знает свой проект. Но для Emacs есть средства autocompletion (http://www.emacswiki.org/emacs/AutoComplete) и вполне рабочие.
Средства деплоя тоже вполне просто делаются средствами сторонних утилит, путем интегрирования их в Emacs(Emacs lisp позволяет сделать очень многое).
А вот «haters gonna hate» я совсем не понимаю. Я указал на то, что можно всего добиться и с помощью Emacs и не городить огород и встраивать то, что уже есть в разные другие программы (типа клавиатурных сокращений).
Мои посты направлены как раз на то, что скорее Emacs следует KISS, чем весь ворох разношёрстных программ, к которым приходиться лепить костыли.
Использовать Eclipse на больших плюсовых проектах — это какой-то мазохизм. Попробуйте в него загрузить ядро linux и поработать с ним. Зато простые редакторы, типа Emacs, с такими проектами справляются легко.
Конечно надо учесть, что вы используете Windows для работы, это накладывает свой отпечаток на работу (отсутствие многих полезных утилит и программ) и это можно понять. Но назвать это взрослением я бы не решился.
Вы уже можете отвечать за всю индустрию, не много ли на себя берёте?
И — нет, это как раз мода. Неужели программа, которая находится под svn станет лучше работать, если перевести её на git? Зато если переводить, то придется менять инфраструктуру разработки, переучивать разработчиков, перенастраивать средства разработки. Есть плюсы в более простом слиянии бранчей и децентрализации разработки, но они меркнут перед мерами, которые необходимо предпринять для перехода.
Каждый разработчик может сделать у себя реп git наравне с уже существующим репом svn, но именно переход бывает менее чем оправданным.
Новые проекты можно начать делать на git или mercurial, они уже достаточно взрослые для повседневного использования, но для старых проектов в этом особой нужды нет.
Я уже писал почему, смотрите вышел.
Наличие или отсутствие документации совсем не показатель, тем более для других программистов, которые хотят использовать код у себя.
По ссылке видно, что человек указал только один минус, который я уже описал выше — это запрет на использование GNU GPL программ в некоторых корпорациях. Для линковки с кодом под несовместимыми лицензиями есть GNU LGPL.
Это мода.
Тут скорее идет противостояние svn с git. Сначала с трудом переходили на svn, пока разбирались что там к чему, потом вот появились git и hg, на них тоже переходить уже нет большого желания у некоторых разработчиков.
А самому разработчику главное чтобы был хостинг для кода, и какая там уже внутри система контроля версий уже дело десятое(IMHO).
Но если программисту не наплевать на то, что будет с его кодом дальше, то он скорее выберет GNU GPL, чем BSD-like лицензию.
Устарели для чего? Ими можно пользоваться и они работают, не вижу проблемы в этом.
Там где копирайты затирают, вы уже не узнаете.
Тут другое, в случае с GNU GPL они будут обязаны выложить свои наработки в открытый доступ или предоставить по первому требованию. Т.е. если они что-то доработали в вашем продукте, то это вернется к вам и вы сможете использовать эти наработки у себя, чтобы улучшить свой продукт.
Если кто-то использует ваш код в своих закрытых продуктах и наживается на этом, ничего не принося сообществу в целом — это нехорошо. Про качество тут речи не идет. Они просто хотят сэкономить, используя чужой труд, при этом ничего не отдавая в замен.
Почему те или иные проекты выбрали для себя BSD-like лицензию может быть много причин, и иногда это не зависит от самих разработчиков(например компания не позволяет сотрудникам выпускать программу под GNU GPL лицензией). Каким образом выбор той или иной лицензии поможет распространению вашего продукта(кроме случаев корпоративного внедрения, где строго оговорен список допустимых лицензий, и это скорее всего продиктовано спонсором)?
Защищает от того, что кто-то может сделать продукт, на основе вашего кода, закрыть его и продать как свой. И в случае BSD-like лицензии будет иметь на это полное право.
Как написали в одном месте «BSD это свобода для разработчика, GPL это свобода для пользователя».
В каком случае главное, чтобы программой могли воспользоваться как можно больше людей? Если вы преследуете такие цели то вам дорога в android market или app store, цела туча хомячков загрузят вашу программу.
И странно другое, если программа будет под лицензией GNU GPL, то в каком случае человек не сможет её использовать, в отличие от MIT?
Можете поинтересоваться почему Microsoft вкладывает деньги в Apache Foundation и поощряет использование именно лицензии Apache.
Выбирая GNU GPL вы уверены, что все библиотеки и наработки, созданные под этой лицензией, будут вам доступны и не придется заново изобретать велосипед, когда кто-то уже написал для этого библиотеку.
По поводу того, что надо в каждый файл исходного кода — для этого есть автоматизация текстовых редакторов (не знаю какой конкретно вы используете), не вижу в этом ничего сложного.
Считать лицензию opensource? Это как? Если только текст лицензии, он открыт.
GNU GPLv3 была создана в 2007, никак не 20 лет назад. Она отлично защищает программистов и их труд, а так же дает гарантии, что ваш код всегда будет открыт, а не утонет в каком-нибудь корпоративном продукте и будет прозябать там в закрытом виде.
GNU GPLv3 дает защиту для пользователей. Например вы используете программу, которую уже никто не разрабатывает много лет, вы всегда можете запросить исходный код у разработчика и доработать программу для новых систем. В большинстве случаев, программы под этой лицензией выкладывают на хостинги проектов, типа sourceforge.net, где она хранится долгое время, и вам нет нужды обращаться конкретно к разработчику, хотя такое бывает не всегда.
В чем-то есть ограничение, конкретно в линковке только с GNU GPL совместимыми лицензиями, но это так-же дает защиту, что вся программа будет работать и в дальнейшем, и её можно будет модифицировать под свои нужды. Если так необходимо линковать продукт с несовместимыми лицензиями — есть LGPL.
Если не важно кто и как возьмет код вашей программы, закроет и использует в своей программе, а потом продаст, то конечно. Но если вы думаете о том, что создаете, то только GNU GPL 3
www.defectivebydesign.org/
В Debian есть утилита backup-manager, умеет инкрементальные бекапы, отправку на удаленный FTP, SSH, RSYNC, Amazon S3. Написана на Perl. www.backup-manager.org/about/
Использвал его в одном проекте, пришлось дописывать то, чего не хватало. API нормальное, только не хватало некоторых очевидных вещей.
Вообще с трдуом могу себе представить кривое API, ведь это только интерфейс для работы, в крайнем случае его можно самому переписать как надо (имею в виду OpenSource проекты).
На сколько я помню — 3D qwt не умеет.
А чем Вам qwt qwt.sourceforge.net ну угодил?
А не проще использовать
chmod u=rwX,g=rX,o= -Rv /var/www/example.ru
он будет учитывать каталоги и файлы отдельно.
chmod соотв. из утилит GNU

Information

Rating
Does not participate
Location
Россия
Registered
Activity