Re: CLI vs. GUI
On Wed, May 23, 2012 at 10:10:59AM +0400, Artem Chuprina wrote: > Смешивать CSS и HTML иногда надо. Но если это приходится делать до > такой степени, что нужна синтаксическая подсветка CSS - фигню порешь. > Что и наблюдается в случае HTML из-под винворда :-) > >> Это второй вопрос. Но программа на JS, если она используется, должна > >> быть в отдельном файле, а не включена в тот же HTML. > АН> Когда как... > > Ни одного контрпримера не попадалось. Проблема в том, что Билл Гейц и Ко сумели творчески переработать принцип: "Все есть файл" в "Нечто есть _один_ файл". Как следствие, появилось поколение калек, для которых мысль о необходимости копирования _нескольких_ файлов для того чтобы разместить страницу, кажется странной. Как следствие, какой-нибудь, опенофис вместо того чтобы создать каталог с читаемыми файлами создает архив, а, говорят, может и одну xml-простыню родить. Или в багрекере inkscаpe многие годы добивались возможности инкапсуляции растра в SVG. Добились, кстати. А любимый, некоторыми, fb2? -- Иван Лох -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523100209.ga12...@nano.ioffe.rssi.ru
Re: CLI vs. GUI
23.05.2012 14:02, Иван Лох пишет: > On Wed, May 23, 2012 at 10:10:59AM +0400, Artem Chuprina wrote: >> Смешивать CSS и HTML иногда надо. Но если это приходится делать до >> такой степени, что нужна синтаксическая подсветка CSS - фигню порешь. >> Что и наблюдается в случае HTML из-под винворда :-) >> >> Это второй вопрос. Но программа на JS, если она используется, должна >> >> быть в отдельном файле, а не включена в тот же HTML. >> АН> Когда как... >> >> Ни одного контрпримера не попадалось. > > Проблема в том, что Билл Гейц и Ко сумели творчески переработать принцип: > "Все есть файл" в "Нечто есть _один_ файл". Как следствие, появилось > поколение калек, для которых мысль о необходимости копирования _нескольких_ > файлов для того чтобы разместить страницу, кажется странной. > > Как следствие, какой-нибудь, опенофис вместо того чтобы создать каталог с > читаемыми файлами создает архив, а, говорят, может и одну xml-простыню > родить. > > Или в багрекере inkscаpe многие годы добивались возможности инкапсуляции > растра в SVG. Добились, кстати. А любимый, некоторыми, fb2? Ну, не всё так сурово. Я про более частный случай. Кстати, тесно связанный с MS. :-) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbcf44e.8060...@yandex.ru
Re: CLI vs. GUI
23.05.2012 10:10, Artem Chuprina пишет: > Артём Н. -> debian-russian@lists.debian.org @ Tue, 22 May 2012 22:48:11 > +0400: > > >> >> >> Так что писать на коленке презентацию, которая будет > >> >> >> выведена плюс-минус так, как ты ее видишь, еще можно (и то > >> >> >> не всегда нужно - видел я подобные поползновения печатать > >> >> >> объявления в ворде...), а HTML - уже ни в коем разе. > >> >> АН> Как-раз для HTML, GUI необходим. Если, конечно, вы не > >> >> АН> рассчитываете на то, что все ваши пользователи используют > >> >> АН> lynx, links, w3m или подобное. > >> >> > >> >> Доктор, это ничего, что у меня есть информативный сайт, все HTML > >> >> которого написаны вручную, старые в vim, новые в emacs? Ключевое > слово > >> >> - "информативный". > >> АН> Вообще-то, это частный случай, когда требуется преимущественно > >> АН> подсветка HTML и CSS. С чем VIM неплохо справляется. > >> > >> Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном > >> файле, отчего все еще проще. > АН> Правильный редактор не должен рассчитывать на то, что всё будет "по > АН> уму", к тому же, иногда надо смешивать CSS и HTML. > > Правильный _для меня_ - имеет право на это рассчитывать. Более того, > ему рекомендуется так делать. Типа если он не справляется с подсветкой, > значит, я фигню порю. emacs вполне успешно справляется с задачей ловли > меня за руку. А вы будете в своём "правильном" редакторе просматривать исключительно "правильный код"? :-) Или что-то чужое иногда приходится читать? Да и неплохо бы дать пользователю _выбирать_, что для него правильно... > Смешивать CSS и HTML иногда надо. Но если это приходится делать до > такой степени, что нужна синтаксическая подсветка CSS - фигню порешь. > Что и наблюдается в случае HTML из-под винворда :-) Не обязательно (именно про подсветку в CSS, даже когда он в отдельном файле). Синтаксическая подсветка позволит визуально выделить элементы (я не про помойку CSS+HTML, а про выделение элементов в самом CSS). Меньше придётся напрягаться, например, при визуальном поиске (в глаза сразу бросаются имена атрибутов, например, в "полотне" параметров и "своих" классов). Меньше усталость, комфортнее работать. Я не прав? > >> Суть, собственно, в том, что vim и emacs - это TUI, а не GUI. Хотя > >> emacs даже умеет показывать картинки. Лучше б не умел... > >> > >> >> А если мне нужно интерактивное веб-приложение, то > >> >> там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно > >> >> ручное редактирование. > >> АН> Хм... Haml - любопытно. > >> > >> Угу. Технология создания веб-приложений сводится к тому, что дизайнер > >> делает дизайн, HTML-верстальщик (это совершенно другой человек) > >> превращает его в HTML, CSS и набор картинок, а программист превращает > >> эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов, > >> которые динамически заполняются данными. Гуй для HTML при этом может > >> использоваться в принципе только на втором этапе, но тем верстальщикам, > >> кто пытается его там использовать, быстро отрывают руки. Ну, или > >> результат получается, мягко говоря, неюзабельным для пользователя. > АН> Хм. Что, вы хотите сказать, что во всех компаниях, которые > АН> занимаются созданием WEB-данных (документов или приложений и т.п.) > АН> и могут позволить себе иметь дизайнера, не имеющего представления о > АН> вёрстке и ей не занимающегося, верстальщика и прочих, вторые всегда > АН> работают без GUI? Кстати, а дизайнер тоже обязательно, либо не > АН> использует компьютер, либо работает без GUI? :-) Или, всё-таки, на > АН> первом этапе тоже есть GUI, только совершенно отличный от GUI > АН> верстальщика? > > К слову, в большинстве контор, занимающихся созданием веб-приложений, > своего дизайнера вообще нет. Аутсорсят. Дизайнер не работает с HTML, > поэтому ему гуй для (читаем внимательно!) HTML не нужен. > Верстальщик тоже работает с гуем - но не для создания HTML, а для > нарезки того, что сделал дизайнер, и для извлечения оттуда информации о > цветах :-) Ну, я про это и говорю (читаем внимательно в предыдущем сообщении): раздельный ГУЙ. Но дизайнер тоже работает с гуём... > АН> Кстати, а операторам на станциях например, GUI тоже не требуется? > АН> :-) Или, всё-таки, он иногда нужен (почему-то вы та упорно > АН> пытаетесь доказать, что GUI - всегда плохо)? > Почему-то вы упорно вычитываете в моих словах то, что там не написано. Ну, потому что мне кажется, что вы упорно доказываете то, что я там вычитываю. :-) > >> >> Как это выглядит, нужно смотреть в браузере и только в браузере. > >> >> Желательно не в одном. > >> АН> Как это выглядит и работает нужно проверять в браузере. Обязательно > >> АН> не в одном, как говорят. По крайней мере, в наиболее популярных > >> АН> (или в тех, на которых это будет работать, если это нечто > >> АН> специфическое). И, затем ещё вносить корректировки для конкретных > >> АН> экземпляров. :-| > >>
Re: Сетевуха работает только в promisc режиме
22.05.2012 12:58, Eugene Berdnikov пишет: > Итак, можно предположить, что есть некий клинический случай асимметричного > роутинга, когда пакеты почему-то идут не через eth, а иным путём... > Какие ещё сетевые интерфейсы есть на машине? Выключите все виртуалки, > приведите машину к проблемному состоянию и покажите результат работы > такого скрипта: > > ip addr list > ip route list > ip link set dev eth0 promisc off > ip route flush cache > ip route get 192.168.1.1 > tcpdump -nlUevvp -i any arp or icmp & > ping -n -c2 192.168.1.1 > killall tcpdump > ip link set dev eth0 promisc on > ip route flush cache > ip route get 192.168.1.1 > tcpdump -nlUevvp -i any arp or icmp & > ping -n -c2 192.168.1.1 > killall tcpdump > ip link set dev eth0 promisc off Логи приложил. Первый (log0), когда сеть не поднялась после hibernation. Второй (log1), я перезагрузился (nm был включен, networking выключен), сеть не работала. Установил адаптер в promisc и запустил networking. Без этого: "~# sh ss.sh 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff inet6 fe80::a800:4ff:fe00:a04/64 scope link valid_lft forever preferred_lft forever RTNETLINK answers: Network is unreachable connect: Network is unreachable RTNETLINK answers: Network is unreachable connect: Network is unreachable" Затем, убрал promisc. Пинга не было. 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0 inet 192.168.1.4/24 brd 192.168.1.255 scope global secondary eth0 inet6 fe80::a800:4ff:fe00:a04/64 scope link valid_lft forever preferred_lft forever 3: vmnet0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:50:56:c0:00:00 brd ff:ff:ff:ff:ff:ff inet 192.168.62.1/24 brd 192.168.62.255 scope global vmnet0 inet6 fe80::250:56ff:fec0:0/64 scope link valid_lft forever preferred_lft forever default via 192.168.1.1 dev eth0 proto static 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 192.168.62.0/24 dev vmnet0 proto kernel scope link src 192.168.62.1 192.168.1.1 dev eth0 src 192.168.1.3 cache ipid 0xaa1c rtt 17ms rttvar 20ms cwnd 10 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 19:29:50.631596 Out aa:00:04:00:0a:04 ethertype ARP (0x0806), length 44: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.3, length 28 19:29:51.634945 Out aa:00:04:00:0a:04 ethertype ARP (0x0806), length 44: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.3, length 28 >From 192.168.1.3 icmp_seq=1 Destination Host Unreachable >From 192.168.1.3 icmp_seq=2 Destination Host Unreachable --- 192.168.1.1 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1007ms pipe 2 19:29:52.638311 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 128: (tos 0xc0, ttl 64, id 21585, offset 0, flags [none], proto ICMP (1), length 112) 192.168.1.3 > 192.168.1.3: ICMP host 192.168.1.1 unreachable, length 92 (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.3 > 192.168.1.1: ICMP echo request, id 15456, seq 1, length 64 19:29:52.638320 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 128: (tos 0xc0, ttl 64, id 21586, offset 0, flags [none], proto ICMP (1), length 112) 192.168.1.3 > 192.168.1.3: ICMP host 192.168.1.1 unreachable, length 92 (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.3 > 192.168.1.1: ICMP echo request, id 15456, seq 2, length 64 4 packets captured 6 packets received by filter 0 packets dropped by kernel 192.168.1.1 dev eth0 src 192.168.1.3 cache ipid 0xaa1c rtt 17ms rttvar 20ms cwnd 10 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.41 ms tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 19:29:53.656411 Out aa:00:04:00:0a:04 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.3 > 192.168.1.1: ICMP echo request, id 15462, seq 2, length 64 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.919 ms --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg
Re: Сетевуха работает только в promisc режиме
23.05.2012 06:03, Andrey Lyubimets пишет: > 22.05.2012 21:58, "Артём Н." написал: > >>> Возможно, карточка была повреждена при перепрошивке. >>> Хотя я пока не знаю, может ли это как-то объяснять чудеса, >>> которые мы наблюдаем в дампе. >> Возможно ли такое, что карточку повредил flashrom, который не поддерживал >> мать >> (а man я не посмотрел и опцию -l не использовал перед прошивкой)? >> Ещё и прошивку не ту залил. Окончилось печально: пришлось искать нормальную >> прошивку и везти микросхему BIOS на программатор. >> Адаптер, понятное дело, встроенный. >> Мог ли он быть повреждён? И как лечить? :-( >> >> > Попробуй перешить ещё раз инструментами от производителя платы Там есть встроенный в BIOS прошивальщик. Перешью старой прошивкой. Но как-то это всё-равно напрягает после предыдущей прошивки (несмотря на то, что сейчас есть, где быстро перешить, если что-то полетит). :-| -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbd0775.3030...@yandex.ru
Re: CLI vs. GUI
On Wed, May 23, 2012 at 06:43:38PM +0400, "Артём Н." wrote: > Главная страница может использовать общий стиль. Но у неё есть некоторые > особенности. Зачем для неё выносить CSS в отдельный файл (читайте отдельный Ну и ввести набор классов специально для особенностей главной страницы. > запрос), если он больше нигде не дублируется? > IE поддерживает условные комментарии (aka костыли), которые приходится > применять Это уже треш какой-то -- Иван Лох -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523163650.gb12...@nano.ioffe.rssi.ru
Re: Сетевуха работает только в promisc режиме
On Wed, May 23, 2012 at 07:48:36PM +0400, "Артём Н." wrote: > Логи приложил. Первый (log0), когда сеть не поднялась после hibernation. > Второй (log1), я перезагрузился (nm был включен, networking выключен), > сеть не работала. Установил адаптер в promisc и запустил networking. > Без этого: > "~# sh ss.sh > 1: lo: mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast state UP > qlen 1000 > link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff > inet6 fe80::a800:4ff:fe00:a04/64 scope link >valid_lft forever preferred_lft forever > RTNETLINK answers: Network is unreachable > connect: Network is unreachable > RTNETLINK answers: Network is unreachable > connect: Network is unreachable" Это совсем нерабочая конфигурация: даже ip-адреса на eth0 нет... По логам: тяжёлый случай. Первой рекомендацией будет поставить ядро 3.2.0 из дистрибутива. Слишком много странностей, нужно сократить круг поиска. Второй будет поставить в машину дополнительную сетевушку и попробовать её. Наконец, предлагаю ещё раз получить нерабочее состояние системы и запустить немного изменённый скрипт. ip addr list ip route list ip link set dev eth0 promisc off ip route flush cache ip nei flush dev eth0 ip -s nei list ip -s -t mon all > ipmon.log & tcpdump -nUlep -i eth0 -w dump.pcap arp or icmp & sleep 1 ip route get 192.168.1.1 date +%T.%N ping -n -c2 192.168.1.1 ip -s nei list sleep 1 date +%T.%N ping -n -c2 192.168.1.2 ip link set dev eth0 promisc on ip route flush cache ip nei flush dev eth0 ip route list ip -s nei list ip route get 192.168.1.1 date +%T.%N ping -n -c2 192.168.1.1 ip -s nei list sleep 1 ip link set dev eth0 promisc off killall tcpdump killall ip Пришлите выдачу этого скрипта, а также образовавшиеся файлики ipmon.log и dump.pcap. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523191255.gq3...@sie.protva.ru
