Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Wątek Zamknięty
Jesteśmy częściowo w czarnej d***e że tak to ujmę.
Mamy stary, dobry, przenośny init odziedziczony po SystemV. Działa od dziesięcioleci (;)) bez zarzutów. Ale mamy też rok 2013, gdzie każdemu odbija na punkcie innowacyjności. (Powaga, wszędzie gdzie się nie obejrzę coś jest "innowacyjne"). Owszem, aktualny init ma parę wad (znaczy się dość długi czas startu i sam z siebie średnio umie pilnować stanu usług), ale kurka, żeby od razu stawiać niezależny, międzynarodowy społecznościowy projekt przed wyborem ->
a) jesteśmy murzynami pasożytów z Canonical i przyjmiemy ich upstart, a potem będziemy odwalać najgorszą robotę portując pod to skrypty i łatać błędy, a nuż chociaż ktoś z Canonical nam za to podziękuje. (Za kradzione paczki nie dziękował nikt o ile dobrze wiem)
b) dobrowolnie dajemy sobie zaszczepić raka jakim jest "światła" idea magicznego chłopca Lennarta Poetteringa w postaci systemd, czym dołączamy do reszty systemów zależnych od 'muricańskiego korpo spod sztandaru Czerwonego Kapelusza. N
Nie mam zbyt dobrego zdania ani o jednym ani o drugim, najchętniej widziałbym pozostanie przy sysV. Jeżeli się nie da niech będzie nam dany OpenRC.
Jedyną zaletą systemd jaką zauważyłem jest szybki start systemu i jeszcze szybsze zamykanie. (Testowałem dziś na Wheezymz systemd na wirtualce KVM o mocy ~ 300Mhz, 256MB RAM. Bootowanie: 7 sekund. Shutdown: 1 sekunda). Cała reszta "cudownych" ficzerów w stylu usług aktywowanych po odebraniu pakietu na socket, etc. to zwykłe świecidełka.
Zalet upstarta nie widzę żadnych. Poza faktem że jego wybór stworzyłby silną opozycję do magicznej Lennartowskiej propagandy sukcesu. Ale murzynić na Canonical... Ech...
Ostatnio edytowany przez enether (2013-10-30 23:51:14)
Offline
[quote=enether]Jesteśmy częściowo w czarnej d***e że tak to ujmę.......[/quote]
Pisz za siebie.
Ja mam od kilku latek OpenRC i nie narzekam.
Gentusia lubię za to, ze nic o mnie beze mnie nie decyduje, ja sam decyduję, co mam w systemie, a co nie.
I dzięki temu jeszcze nie wywaliłem kompa przez okno, co przy buntach było
bardzo częstym i realnym zagrożeniem. :D
Offline
;)
Miałem tu na myśli społeczność Debianową. Gentoo też używam i cenię sobie za elastyczność i nieskończoną konfigurowalność, ale spójrzmy prawdzie w oczy, system wymaga zbyt wiele troski by dało się administrować kilkunastoma jego instancjami naraz bez zajeżdżenia się (w każdym razie ja nie potrafię, może przyjdzie z czasem), poza tym nie wszystko co da się zrobić na Debianie da się zrobić na Gen2 (chodzi mi głównie o ukochane przez klientów kawałki softu w stylu DirectAdmin) no i nie na każdym sprzęcie Gentoo pokazuje jak fajne jest. (Stąd mój stary T61 lata na Debianie, bo nie mam serca go męczyć kompilacją gnome3 i ton innych pokaźnych kawałków softu. firefox-bin, libreoffice-bin, etc. to nie wyjście, bo albo wszystko kompilować pod swoje potrzeby albo nic ;P)
Offline
Jeśli to jednakowe maszyny, albo podobne, to masz jeden serwer bazowy, na nim robisz paczki, reszta ciągnie je z binhosta.
W ten sposób administrujesz jednym serwerem, a aktualizuje się nawet 2000 serwerów.
Potem zostają tylko własne skrypty i konfigi, czyli to samo, co w Debianie.
Trochę zabawy jest z kopiowaniem kernela, bo tutaj nie znam ebuilda do gotowej paczki, można co najwyżej zbudować jajo do paczki tgz poleceniem make
z którąś z tych opcji:
tar-pkg - Build the kernel as an uncompressed tarball targz-pkg - Build the kernel as a gzip compressed tarball tarbz2-pkg - Build the kernel as a bzip2 compressed tarball tarxz-pkg - Build the kernel as a xz compressed tarball
Ale jak jajo buduje ktoś kumaty, to też nie zostawia bez potrzeby ładowalnych modułów, tylko sterowniki pakuje prosto w jajo, i potem wystarczy kopiować miedzy takimi samymi maszynami sam bzimage.
A jak masz np 50 serwerów, to raczej są mniej więcej jednakowe maszynki, prawda?
Gentoo tak samo operuje paczkami, jak Debian czy Fedora, trzeba tylko wykombinować sprawę kernela, czyli naskrobać do tego ebuilda albo skrypta, lub popytać na forach, czy ktoś miał podobny problem.
Chyba jednak nie święci garnki lepią, chociaż przyznaję, że dpkg bardzo ułatwia administrację.
Offline
Akurat w przypadku wirtualek nie ma specjalnego problemu, na KVMie wszystko wygląda tak samo, więc na upartego można postawić jedno Gentoo, wyczyścić, zrobić templatkę z obrazu i kopiować. I tak oto magicznie powstaje wstępnie prekonfigurowane Gen2. Problem pojawia się gdy podobne maszyny idzie stawiać na przeróżnych serwerach fizycznych różniących się nieraz wszystkim (a robić mega jajka z initrdem który miałby działać wszędzie zwyczajnie się nie godzi). Albo gdy nagle odkryjesz że gdzieś tam żyje jakieś Gentoo pamiętające rok 2009. A aktualizacja czegoś takiego to raczej niezła gimnastyka.
Poza tym zawsze zostają życzenia klientów. I fakt że dpkg jest wygodne. I aktualizacja trwają parę minut, podczas gdy emerge -NuD world potrafi zająć odrobinkę więcej.
Dzięki za info o narzędziach do paczkowania jajek, przetestuję jutro.
No ale odeszliśmy od zasadniczego tematu dyskusji.
Offline
Linux, to Linux.
Zawsze możesz sobie zrobić odpowiednią optymalizację Debiana, flagi hardened też już trafiły pod strzechy, podobnie, jak wszystkie inne,
jak potrzeba łatki czy ekstra kombinacje, to w podręczniku developerów wszystko pisze.
Różnica między Gentusiem a Debianem polega na tym, że Gentoo zazwyczaj kompiluje się pod konkretną maszynę i konkretne potrzeby.
I jak masz kilka serwerów w takiej malutkiej serwerowni, jak OVH, to tam właśnie mają po kilkaset, a czasem tysi każdego modelu serwera, dlatego Gentoo tam działa elegancko.
Jak natomiast masz każdą krowę z innej parafii i z innym sprzętem, to robisz albo modularne jajo, albo te kilka sterowników zostawiasz we wszystkich jajkach (99% serwerów ma może 5 - 10 sterów na krzyż, więc szanse, że ogarniesz 50 maszyn 15 - 20 sterownikami są dość spore).
Serwery zazwyczaj nie mają kart graficznych, kamerek internetowych, skanerów, czy myszek.
Chociaż mądralę, który zakupił sprzęt do serwerowni, i ma każdą maszynę z innej bajki, chyba należałoby gruntownie i starannie obić, za sabotaż przemysłowy.
Po prostu, jak masz 50 jednakowych maszyn, i coś się w nich pieprzy od czasu do czasu, to w trzy minuty z dwóch walniętych maszyn poskładasz jedną sprawną, parę ruchów śrubokręta i gotowe.
Możesz też mieć minimalny zestaw części zamiennych, bo pasują do każdego grata, i nauczyć się jednej instrukcji obsługi - jeśli takowa istnieje.
Konfiguracja też jest wtedy prostsza, możesz po prostu klonować obrazy po sieci.
Oczywiście każdy przypadek jest trochę inny, i każdy totalnie wyjątkowy. ;)
EDIT:
Hardening w Debianie:
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
dpkg-buildflags CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security FFLAGS=-g -O2 LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now
Sznurek:
https://wiki.debian.org/Hardening
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2013-10-31 01:42:34)
Offline
Ktoś próbował OpenRC na Debianie? Jak się sprawuje?
Offline
Na Debianie nigdy, ale na Gentusiu śmiga bardzo grzecznie i z zadowalającą szybkością.
Offline
@mati75
Instalowałeś według instrukcji z wiki Debiana?
Offline
topis: too long didnt read lol - przeczytam później
a samo systemd działa w testing bardzo dobrze, używam tego kilka ładnych miesięcy
Offline
Systemd działa ok.
Jest nawet szybszy od obecnego ale bardziej [i]miękki[/i]
Przeformatuj tylko partycję podpiętą we fstabie po uuidach to juz system nie wstanie. :)
Offline
[url]http://www.phoronix.com/scan.php?page=news_item&px=MTU1NDM[/url]
KDBUS & Systemd Now Yields A Working System
Ludzie z Red Hata dodali do jądra Linux kolejną porcję kodu - zintegrowali serwer DBus. Strona kliencka została zaimplementowana w Systemd.
Systemd w zależnościach potrzebuje właśnie m.in. Dbusa. Czym mniej zależności i linii kodu, tym stabilniej. Tymczasem:
[url]http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems[/url]
OpenRC (0.9.3): sysvinit + 300 files, ~30k lines, 3.3k posix sh, ~12k C
Upstart (1.5): 285 files, ~185k lines, ~97k C
Debian: sysvinit + 120 files, 5.8k lines
systemd (v44+): dbus + glib + 900 files, 224k lines, 125k C
sysvinit: 560kB, 75 files, ~15k lines
D-Bus: 11MB, ~500 files. 300k lines, 120k C
glib: 72MB, ~2500 files, ~1.7M lines, ~430k C
Debian startup is smallest, it's only shell with sysvinit (C) as dependency
Upstart is about 10 times bigger in terms of lines of code/text. Most of the extra complexity size comes from C.
OpenRC is about twice as big as debian startup. The size difference is mostly the OpenRC core written in C, which expands the footprint from ~3k LoC to ~15k LoC compared to shell.
systemd is about 10 times bigger, like upstart. But with the mandatory deps it blows up to about one hundred times the code footprint! Most of the extra code is in mandatory dependencies, but the systemd core is also bigger than anything else.[/quote]
Od zwolennika Systemd w Debianie:
[url]https://wiki.debian.org/Debate/initsystem/systemd[/url]Systemd is often said to be too big for the functionality of an init system.
However it is much more than init, and if you take into account all the functionality it can provide or replace, you’ll soon find out that it takes less lines of code than the alternatives, in a language (C) that takes less memory to execute.
Linux is mostly a monolithic kernel and runs an enormous amount of code in ring 0. Having ~2% of this amount in the init system, most of which is run outside PID 1, does not sound like gigantism.[/quote]
[url]https://wiki.debian.org/Debate/initsystem/openrc[/url]The systemd page uses Linux as being monolithic as an argument, which has absolutely nothing to do with the discussion about too many things in the PID1 (it is by the way my opinion that Linux is a way too monolithic though).[/quote]
[url]https://wiki.debian.org/Debate/initsystem/sysvinit[/url]No integration with udev, services cannot be started when specific hardware is discovered.
This sounds like the specific goal of a desktop environment trying to be user-friendly, but isn't something everyone wants; tight integration between kernel, initsystem and userland is a high price to pay.[/quote]Ostatnio edytowany przez uzytkownikubunt (2013-12-27 20:11:26)
Offline
[quote=ilin]Systemd działa ok.
Jest nawet szybszy od obecnego ale bardziej [i]miękki[/i]
Przeformatuj tylko partycję podpiętą we fstabie po uuidach to juz system nie wstanie. :)[/quote]
Albo wstanie po godzinie, jak u mnie, jak chciałem zobaczyć, co słychać w systemd.
Po prostu OpenRC wywala błąd skrypta i idzie dalej, czasem poczeka 50 sekund - jak jakiś wstaje dłużej, albo ileś tam usług nie wstanie z powodu braku koniecznych zależności, ale zawsze na końcu jest konsola, żeby się lognąć i poprawiać.
W systemd może też da się tak docelowo ustawić, ale na razie na każdym błędzie czekał sobie chyba z 5 minut, po godzinie wreszcie wstał, do poziomu konsoli, po różnych kombinacjach na klawiaturze.
Póki co, trochę za dobre dla mnie to cudo, jak na Jessie wrzuciłem systemd,
to wstawał pół godziny (sukces), sysvinit wstaje może z 20 sekund i wsio w nim chodzi.
W ten oto sposób Systemd usilnie mnie przekonuje, żeby trzymać się OpenRC, SysVinit i podobnych wynalazków. :D
Ostatnio edytowany przez Jacekalex (2013-12-27 22:32:58)
Offline
systemd ssie podobnie jak pulseaudio, w końcu ten sam autor. Dlatego jak dla jedyną słuszną opcją jest openrc. Zresztą od paru dni wita mnie taki obrazek:
[img]http://s24.postimg.org/lr23r07wl/openrc.png[/img]
Offline
Też masz ten komunikat z fast TSC calibration failed?
Myślałem, że u mnie grsec coś rozrabia, potem się okazało, że bez grsec też to wyłazi, myślałem, że coś przekombinowałem w konfiguracji jajka.
Tymczasem się okazuje, że świeże jajka w Debku też tak miauczą?
Czyli chyba jeszcze do reszty nie zardzewiałem :D
Ostatnio edytowany przez Jacekalex (2013-12-27 22:32:22)
Offline
[quote=uzytkownikubunt]Czym mniej zależności i linii kodu, tym stabilniej. Tymczasem:[/quote]
Wiesz to takie teorie wiesz ;p na tej zasadzie to siedziałbym na jądrze 2.4 i DSL.
a systemd .. cóż mi na desktopie działa okey, ale jak dla mnie też jest za duży i pakują do niego za dużo funkcjonalności.
Offline
[quote=Pavlo950]A ja mam bardzo lamerskie pytanie.
Po co robić jakieś upstarty i pochodne, skoro sysvinit jest (względnie) dobry i działa?[/quote]
Bo jest względnie dobry i działa :P
Po prostu ktoś ma pomysł jak coś ulepszyć i to robi, potem ktoś inny i powstaje kilka programów robiących to samo
Fervi
Offline
[quote=Pavlo950]A ja mam bardzo lamerskie pytanie.
Po co robić jakieś upstarty i pochodne, skoro sysvinit jest (względnie) dobry i działa?[/quote]
W zależności od konkretnej implementacji systemu init, inaczej można obsługiwać obsługę wirtualnych terminali (ConsoleKit/Logind, w tej chwili może się zdarzyć tak, że może przestać działać i użytkownik na danym terminalu nie będzie mógł nic wykonać, nie będzie mógł przejść do innego, jedynie magic sysrq zostanie) w szczególności zyskać mogą konfiguracje, gdzie na jednym PC pracuje kilka osób w tym samym momencie (do 1 PC są np 3 monitory, myszki, klawiatury), demonów pozwalających komunikować się pomiędzy procesami posiadającymi różne uprawnienia (czyli sprawy bezpieczeństwa pakiety PolicyKit/logind), w prostszy sposób skonfigurować system tak, by po podłączeniu urządzenia wykonywana była jakaś akcja (podłączenie przez usb adaptera bluetooth -> uruchomienie demona odpowiedzialnego za bluetooth) i możliwość kontroli jak zachowuje się usługa. Oprócz tego taki systemd pozwala łatwo tworzyć kontenery dla demonów, z drugiej strony ogranicza użycie innych kontenerów jak LXC, [url=https://github.com/google/lmctfy]lmctfy[/url]. No i stabilność i bezpieczeństwo systemd są wątpliwe. Przemawia za tym zarówno duża ilość kodu jak i ilość już teraz zgłoszonych błędów, również wiele ze zgłoszonych błędów grozi bezpieczeństwu systemu.
uzytkownikubunt napisał(-a):
Czym mniej zależności i linii kodu, tym stabilniej. Tymczasem:
Wiesz to takie teorie wiesz ;p na tej zasadzie to siedziałbym na jądrze 2.4 i DSL.[/quote]
Prawdopodobnie stabilność to nie jedyna cecha jakiej oczekujesz i dlatego używasz nowszych kerneli ;)
Poza tym teoria ta, jak to często bywa, ma założenie Ceteris paribus, a dyskusyjnym jest czy dla kerneli 2.4 i 2.6 można to założenie uznać za spełnione. Jeśli nie, to teorii się tutaj nie stosuje.
Na liście mailingowej Debiana o systemie init zdarzały się takie argumenty, że systemd ma dużo więcej linii kodu i nikt tej teorii nie atakował. Co najwyżej deweloperzy systemd odpierali zarzut tym, że zarówno na serwerach jak i desktopach i tak dużo z tego kodu byłoby uruchomione, ale nie w PID 1, tylko osobne demony, a według nich wychodzi na to samo.Ostatnio edytowany przez uzytkownikubunt (2013-12-31 14:29:28)
Offline
[quote=uzytkownikubunt][quote=Pavlo950]A ja mam bardzo lamerskie pytanie.
Po co robić jakieś upstarty i pochodne, skoro sysvinit jest (względnie) dobry i działa?[/quote]
W zależności od konkretnej implementacji systemu init, inaczej można obsługiwać obsługę wirtualnych terminali (ConsoleKit/Logind, w tej chwili może się zdarzyć tak, że może przestać działać i użytkownik na danym terminalu nie będzie mógł nic wykonać, nie będzie mógł przejść do innego, jedynie magic sysrq zostanie) w szczególności zyskać mogą konfiguracje, gdzie na jednym PC pracuje kilka osób w tym samym momencie (do 1 PC są np 3 monitory, myszki, klawiatury), demonów pozwalających komunikować się pomiędzy procesami posiadającymi różne uprawnienia (czyli sprawy bezpieczeństwa pakiety PolicyKit/logind), w prostszy sposób skonfigurować system tak, by po podłączeniu urządzenia wykonywana była jakaś akcja (podłączenie przez usb adaptera bluetooth -> uruchomienie demona odpowiedzialnego za bluetooth) i możliwość kontroli jak zachowuje się usługa. Oprócz tego taki systemd pozwala łatwo tworzyć kontenery dla demonów, z drugiej strony ogranicza użycie innych kontenerów jak LXC, [url=https://github.com/google/lmctfy]lmctfy[/url]. No i stabilność i bezpieczeństwo systemd są wątpliwe. Przemawia za tym zarówno duża ilość kodu jak i ilość już teraz zgłoszonych błędów, również wiele ze zgłoszonych błędów grozi bezpieczeństwu systemu.
uzytkownikubunt napisał(-a):
Czym mniej zależności i linii kodu, tym stabilniej. Tymczasem:
Wiesz to takie teorie wiesz ;p na tej zasadzie to siedziałbym na jądrze 2.4 i DSL.[/quote]
Prawdopodobnie stabilność to nie jedyna cecha jakiej oczekujesz i dlatego używasz nowszych kerneli ;)
Poza tym teoria ta, jak to często bywa, ma założenie Ceteris paribus, a dyskusyjnym jest czy dla kerneli 2.4 i 2.6 można to założenie uznać za spełnione. Jeśli nie, to teorii się tutaj nie stosuje.
Na liście mailingowej Debiana o systemie init zdarzały się takie argumenty, że systemd ma dużo więcej linii kodu i nikt tej teorii nie atakował. Co najwyżej deweloperzy systemd odpierali zarzut tym, że zarówno na serwerach jak i desktopach i tak dużo z tego kodu byłoby uruchomione, ale nie w PID 1, tylko osobne demony, a według nich wychodzi na to samo.[/quote]
Z tymi niedziałającymi usługami w SysInit to jakaś ciężka wariacja.
Debian i inne dystrybucje wiele lat na takich systemach działały, i nie było żadnego problemu czy to z pam, czy z consolekit, czy z udevem, czy naprawdę poważnymi rzeczami, jak SELINUX czy Grsecurity-ACL.
Twierdzenie, że bez systemd coś może nie działać, to zwykłe marketoidalne pierdolenie dla tworów humanoidalnych zbyt durnych na kretynów, coś w rodzaju homo-kapustobrainus.
Nie widziałem w życiu psa, kota, chomika czy myszy która by uwierzyła w takie marketoidalne bzdury, co dowodzi, że cześć ludzkości funkcjonuje na poziomie umysłowym znacznie poniżej myszy polnej.
Jedyna różnica między SysVInit a nowszymi systemami, to to, że SysVinit przewidywał sztywną kolejność startu usług, natomiast Upstart, OpenRC czy Systemd działają w oparciu o zależności między usługami, co w teorii ma być szybsze, w praktyce jest znacznie bardziej podatne na krytyczne błędy.
Przy okazji, im więcej kodu, tym więcej błędów, to widać słychać i czuć
i w Systemd, i w PA, i w NM, i setkach podobnych wymysłów, z aktualnym Xorgiem na czele, którego łatwiej pochować w betonowym sarkofagu i zastąpić Waylandem, niż próbować poprawiać. :D
Ostatnio widać to również w Thunderbirdzie, co napawa mnie głębokim smutkiem. ;PWiesz to takie teorie wiesz ;p na tej zasadzie to siedziałbym na jądrze 2.4 i DSL.[/quote]
Słuszna teoria, gdybym ją słyszał od oberlamera, w praktyce ciekawe, ile współczesnego sprzętu ogarnie jajo 2.4.
W dodatku w źródełkach kernela masz taki programik, wywoływanyKod:
make xconfigi nikt tobie nie każe pakować ~2000 sterowników do prawie wszystkich kart PCI/ISA, jakie były produkowane w ciągu ostatnich 15 lat, i których nie tylko żadna obudowa nie pomieści, ale nawet spory magazyn nie dałby rady.
Potrzebujesz 20 sterów na krzyż, to zaznaczasz te 20 sterów na krzyż, to wszystko.
A wtedy jajeczko jest nawet lżejsze, niż dystrybucyjne 2.4.
W dodatku, jak znasz system, to może być lekki jak DSL, nie ma z tym większego problemu, choć bez bibliotek QT i Gtk tracisz sporo współczesnych
i potrzebnych programów, a te już trochę ważą, nie wspominając np o kdelibs,
bez której nie odpalisz np Kaffeiny.
Generalnie w Linuxie "nie ma rzeczy niemożliwych, niektóre są tylko trudniejsze do zrobienia".
Dosiego Roku
:)Ostatnio edytowany przez Jacekalex (2014-05-21 19:09:23)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)Offline
Wątek Zamknięty
Time (s) | Query |
---|---|
0.00010 | SET CHARSET latin2 |
0.00003 | SET NAMES latin2 |
0.00122 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.144.93.14' WHERE u.id=1 |
0.00076 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.144.93.14', 1732247368) |
0.00037 | SELECT * FROM punbb_online WHERE logged<1732247068 |
0.00060 | SELECT topic_id FROM punbb_posts WHERE id=249646 |
0.00007 | SELECT id FROM punbb_posts WHERE topic_id=21568 ORDER BY posted |
0.00048 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=21568 AND t.moved_to IS NULL |
0.00004 | SELECT search_for, replace_with FROM punbb_censoring |
0.00297 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=21568 ORDER BY p.id LIMIT 50,25 |
0.00086 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=21568 |
Total query time: 0.0075 s |