После нормальной, человеческой авторизации из блокнотика или ПО — ничего страшного, можно открыть фишинговую страничку в отдельной вкладке: если это не фишинг, сессия подхватится, если фишинг — будет видно сразу. IMHO. Главное изначально авторизоваться грамотно.
Храните триады URL:login:password в бумажном блокнотике или в таких программах, как KeePassX, и авторизуйтесь _только_ по этим данным, вводя URL вручную или через ПО. Проблема фишинга отпадёт сама собой.
Была версия IE для Солярки. Возможно, решатся и для этого браузера на что-то похожее. Но, если будет удовлетворять стандартам, и будет вполне взаимозаменяемым, то думаю, это будет незачем.
Пожалуйста; рад, что мой перепост решает чьи-то проблемы.
По поводу FFmpeg была новость, что оригинальный пакет вернётся в Ubuntu 15.04; но ведь можно (хотя бы ради спортивного интереса)) попробовать его имеющийся в основных репозиториях форк, т.е. libav.
Из личного опыта. Пытался освоить. Слишком высокое когнитивное сопротивление при обучении проектировании на основе этих технологий. В реализации показались сложными.
Согласно статистике, B2B-софт имеет в 10 раз больше юзабилити-проблем чем вебсайты для обычных пользователей.
Вот поэтому и есть тенденция применения веб-интерфейсов в B2B-софте, что делает его еще сложней и дороже в сопровождении.
И далее в сочетании веб-интерфейсов с такими шаблонами проектирования, как MVC, MVVM и им подобных.
Причём не совсем понятно, как с такой тенденцией бороться, и есть ли вообще смысл в такой борьбе.
Есть вероятность, что один из этих пакетов заработает и на Ubuntu 14.04. То, что он гарантированно не работает и/или не ставится — в посте не указано.
Но, поскольку на сайте разработчика о совместимости с Ubuntu 14.04 не сказано ни слова, а господам учёным нужна доказуемость, некие гарантии работоспособности, то вместо многих и сложных тестов уже существующих пакетов, легче собрать пакет самому. Заодно и новые навыки приобретут.
Правда, если раньше опыта сборки пакетов из тарболов не было, и с первого раза собрать пакет так, как надо, не получится, то это удовольствие, судя по времени компиляции, будет стоить уйму убитого времени.
Вполне себе адекватная задача по сборке прикладного ПО, которого еще нет в бинарном виде. Но для более масштабируемого её решения, конечно, неплохо бы было собрать пакет .deb. Полезно, например, для более быстрого (с учётом времени компиляции) и управляемого (можно будет снести, если не понадобится, и не засорять систему, также обновить версию) развёртывания на нескольких хостах.
еще бы под WINE запускалась, вобще бы был праздник
у меня не получилось. Debian GNU/Linux Wheezy (7.5) AMD64
пишет «ошибка: файл не найден» и «программы для открытия файлов этого типа не сконфигурировано»
Ещё логичней было бы не устраивать из научной сети — а именно такой была ARPANet/Internet изначально — то, для чего она не предназначена. Тогда бы все вопросы снялись автоматически. Хотя, конечно, всё началось с пузыря доткомов, а может и еще раньше. Но, к сожалению, сейчас Internet в целом и WWW в частности — более, чем вычислительная сеть, т.к. она масштабно «вошла в нашу жизнь».
Логичней было бы начать с добровольной регистрации сайтов в реестре, посмотреть, как это будет выглядеть в пилотном виде. Что-то такое было одно время, когда сайт хотели зарегистрировать в качестве СМИ. Теперь надо просто расширить варианты использования.
Очевидно, что данный спуфинг расширения имени файла эксплуатирует неортогональность формата архива. Для файла в архиве указано два имени с разными целями: одно — для отображения в GUI, другое — для всего остального. Для чего такое может быть полезно с точки зрения прикладного уровня? И есть ли, к примеру, еще какие-то аттрибуты у этого блока отображаемого имени, например, возможность полного сокрытия файла в архиве с точки зрения того же GUI? Ближайшее по смыслу из известных мне, но более объяснимое явление: короткие и длинные имена в файловой FAT — хотя бы есть веская причина: унаследованный формат каталога, в который просто так не впихнёшь длинные имена; последние, кстати, легко убиваются утилитой SCANDISK из дистрибутива MS-DOS v6.20.
Тут буквально вчера поставил на андроид приложение MS Windows Mobile. Никакие способы сохранения файла .DOCX, как нового, так и существующего на карте SD, не работают, как только сохранение в облако от MS. Похоже, MS при любом раскладе хочет заполучать как можно больше пользовательских данных, и стиль нейтральности, в котором выдержан текст лицензии — всего лишь маскировка подлинного положения вещей. В MS Office 365 для десктопа есть возможность сохранять и на локальных дисках, и в облаках, но примечательно то, что из учётной записи Windows Live ID в запущенном Word 2013 не выйдешь, и при установке офиса, при отказе от использования облака всё равно выдаёт неотменяемое окно с приглашением ввести свой Live ID.
Иногда прототип системы делают для того, чтобы его потом выкинуть. И воспользоваться «побочным» эффектом, полученным вследствие его создания. Например, для проверки на практике реализуемости, истинности какой-либо идеи, концепции.
По поводу FFmpeg была новость, что оригинальный пакет вернётся в Ubuntu 15.04; но ведь можно (хотя бы ради спортивного интереса)) попробовать его имеющийся в основных репозиториях форк, т.е. libav.
Вот поэтому и есть тенденция применения веб-интерфейсов в B2B-софте, что делает его еще сложней и дороже в сопровождении.
И далее в сочетании веб-интерфейсов с такими шаблонами проектирования, как MVC, MVVM и им подобных.
Причём не совсем понятно, как с такой тенденцией бороться, и есть ли вообще смысл в такой борьбе.
Есть вероятность, что один из этих пакетов заработает и на Ubuntu 14.04. То, что он гарантированно не работает и/или не ставится — в посте не указано.
Но, поскольку на сайте разработчика о совместимости с Ubuntu 14.04 не сказано ни слова, а господам учёным нужна доказуемость, некие гарантии работоспособности, то вместо многих и сложных тестов уже существующих пакетов, легче собрать пакет самому. Заодно и новые навыки приобретут.
Правда, если раньше опыта сборки пакетов из тарболов не было, и с первого раза собрать пакет так, как надо, не получится, то это удовольствие, судя по времени компиляции, будет стоить уйму убитого времени.
Т.е. указать один нулик, если не знаешь точно второй аргумент. Добавит нужное количество нуликов сам.
но у seq свои удобства: ему можно сказать, чтоб заполнял нуликами слева (удобно, если вставлять в имена файлов, лучше сортировка):
у меня не получилось. Debian GNU/Linux Wheezy (7.5) AMD64
пишет «ошибка: файл не найден» и «программы для открытия файлов этого типа не сконфигурировано»