| 1.1, Аноним (-), 20:18, 09/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Woo-hoo. I'm sure somebody will report a "this doesn't compile, and
I have a new root exploit" five minutes after release, but it still
feels good ;)
Линус молодец конечно, его здравый "пофигизм" мне очень нравится :-) | | |
| 1.2, Аноним (-), 21:52, 09/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Темп, с окторым прогрессирует Линукс ядро просто радует и пугает одновременно =) | | |
| |
| 2.9, _Nick_ (??), 05:56, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
 пугает потому что ты не на настолько гибок, чтобы просто принять скорость развития Пингвина. | | |
|
| 1.3, CR (?), 23:33, 09/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
signalfd/timerfd/eventfd... - скоро изобретем виндовский WaitForSingleObject... | | |
| |
| 2.4, Аноним (-), 00:31, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Нет совсем не Single а очень даже мульти ))
Только вот в виндовс мульти это <64. Причём в поразительно большом количестве мест встречается это число.
А эти вызовы окучат тысячи событий, таймеров, или сигналов. Удобно, добавлять новые события (новые генераторы событьий), не качаясь работающего обработчика.
Если кто не знает зачем это делается, пусть прочитает про мультиплексирование, чем плохи select и poll )) | | |
| |
| 3.5, accept 186млс (?), 06:53, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
В книги Сетевое программирование Стивенсона рассказиваеться о минусах select и poll, во kqueue эти минусы сведены к минимуму | | |
|
|
| 1.6, Евгений (??), 01:24, 11/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Вот из-за того, что в каждое (!) новое ядро толпы уродцев добавляют чудовищное количество изменений критически важных подсистем, ванильные ядра были, есть и будут непригодными для любой серьезной серверной системы.
Хорошо, что есть Редхат и Сусе. | | |
| |
| 2.11, Аноним (-), 11:01, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Уже писалось ведь, что максимально стабильные ядра будут от дистрибутивов, а с кернел.орг самые современные, не глючные, но не самые стабильные. Имхо, так даже лучше. Ничто не будет тормозить прогресс, а стабильности максимальной пусть создатели дистрибутивов добиваются. | | |
|
| 1.7, Сергей (??), 04:03, 11/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Взял 2.6.22.1 наложил POM, интересовало действие TARPIT для iptables. Не собралось, ругается на отсутствие мембера в какой-то структуре. Да новые ядра нужно использовать осторожно :(
Хотя стандартные возможности обычно нормально работают. | | |
| |
| 2.8, _Nick_ (??), 05:49, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Взял 2.6.22.1 наложил POM, интересовало действие TARPIT для iptables. Не собралось,
> ругается на отсутствие мембера в какой-то структуре. Да новые ядра нужно использовать
> осторожно
не нужно, плз, грать волну.
Не новые, а самопатченные ядра нужно использовать осторожно.
А еще точнее нужно знать, что делаешь.
А если в носу мало - то нече лезть в патчинг ядер. | | |
| |
| 3.10, Sokolov Sergey (?), 10:45, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Ну какое нафиг самопатченное, поддержка netfilter должна быть в первую очередь обеспечена. Или ты хочешь сказать, что без netfilter удобоиспользуемое ядро будет? Брал последний patch-o-matic-ng от 2007-07-10 | | |
|
| 2.12, BigBiker (?), 15:25, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
В новом ядре изменили структуру sk_buff, поэтому многие сторонние модули не компилятся. Но исправить это не сложно. | | |
| |
| 3.13, Sokolov Sergey (?), 16:53, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
Ругается на отсутствие мембера "nh". Вопрос что вместо него?
В ipt_TARPIT.c используется где-то в 9-ти местах. | | |
| |
| 4.14, BigBiker (?), 07:44, 12/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Смотрите Changelog:
[SK_BUFF]: unions of just one member don't get anything done, kill them
Renaming skb->h to skb->transport_header, skb->nh to skb->network_header and
skb->mac to skb->mac_header, to match the names of the associated helpers
(skb[_[re]set]_{transport,network,mac}_header).
[SK_BUFF]: Introduce skb_network_header_len
For the common sequence "skb->h.raw - skb->nh.raw", similar to skb->mac_len,
that is precalculated tho, don't think we need to bloat skb with one more
member, so just use this new helper, reducing the number of non-skbuff.h
references to the layer headers even more.
[SK_BUFF]: Introduce ip_hdr(), remove skb->nh.iph
[SK_BUFF]: Introduce arp_hdr(), remove skb->nh.arph
[SK_BUFF]: Introduce ipv6_hdr(), remove skb->nh.ipv6h
[SK_BUFF]: Introduce skb_reset_transport_header(skb)
[SK_BUFF]: Introduce skb_transport_offset()
[SK_BUFF]: Introduce skb_set_transport_header
[SCTP]: Introduce sctp_hdr()
[ICMP6]: Introduce icmp6_hdr()
[SK_BUFF]: Introduce igmp_hdr() & friends, remove skb->h.igmph
[SK_BUFF]: Introduce udp_hdr(), remove skb->h.uh
[SK_BUFF]: Introduce icmp_hdr(), remove skb->h.icmph
[TCP]: Introduce tcp_hdrlen() and tcp_optlen()
[SK_BUFF]: Introduce tcp_hdr(), remove skb->h.th
[SK_BUFF]: Introduce ipip_hdr(), remove skb->h.ipiph
[SK_BUFF]: Introduce ipipv6_hdr(), remove skb->h.ipv6h | | |
|
|
|
| 1.15, Zoonman (?), 09:46, 12/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
При переходе на новое ядро всегда будет существовать проблема обратной совместимости. От этого никуда не денешься.
Стоит лишь призадуматься о том, что надо четко себе представлять, чего ты хочешь от своей ОС. Стабильность или новизна? Выбор должен сделать каждый. | | |
|
