Pan Kot

Wrzuć w odpowiedni blok location po prostu.

CSF ma coś takiego jak connlimit, można ustawić maksymalną ilość połączeń przypadającą na IP.

Android Studio.

Po prostu jaśki tego pokroju nie potrafią zoptymalizować takiego bota i żeby go odpalić potrzebują całego interfejsu graficznego, klienta TS'a i aplikację muzyczną, a prawda jest że wystarczyłaby atrapa xtermowa, null sink pulseaudio i MPD. Ale cóż...

Nie używaj więcej sarkazmu proszę.

O ile napiszesz własnego konsolowego klienta protokołu TS'a, pewnie.

Lepiej wziąć kimsyfa w takim razie.

Nie są to zaskakujące wartości, ale można podać parę przykładów: Przykład 1: OVH standardowo ma governor cpu "ondemand", który dostosowuje frequency do potrzeb. Ja zmieniam na performance - zawsze ustawiam max frequency. Przykład 2: Większość kerneli używa I/O governora CFQ, poprzez używanie Deadline jesteśmy w stanie nieco zwiększyć szybkość I/O. Przykład 3: Wyłączenie debuga pozbawia kernel overhead'u, z którym mamy styczność na wszystkich produkcyjnych i dystrybucyjnych kernelach. Jeśli ktoś nie zamierza debugować problemów z kernelem, można wyłączyć debug, aby kernel nie starał się zapisywać informacji o tym, co robi. Przykładów jest więcej, żadnego benchmarka nie robiłem bo ciężko coś takiego jak kernel w ogóle zbenchmarkować, jednak odczuwalna jest nieco większa responsywność w takich komendach jak apt i dpkg chociażby. Kernela kompiluję głównie dla grseca, prawdopodobnie gdybym nie używał tej łatki to bym się nie zagłębiał jakoś szczególnie w konfigurację, ale skoro już rekompiluję to od razu dostosowuje pod daną maszynę. I "zawsze" jakaś tam mikroskopijna różnica na plus jest odczuwalna po tym jak zrebootuje. Może to być również związane z samym faktem kompilatora, nowsze GCC zawsze lepiej sobie radzą z kodem i optymalizacjami niż starsze.

Jakby jeszcze te kimsyfy RAID miały... .

Musisz odróżnić kernel dystrybucji od własnego. Kernel dostarczany z dystrybucją jest jedną wielką bańką modularną. To oznacza, że ma wkompilowane jako moduły wszystkie sterowniki, drivery i czego dusza zapragnie co może być potrzebne/używane podczas korzystania z systemu. Kernel taki ma kilka zasadniczych wad. Po pierwsze, jest duży, zawiera tonę syfu, której nigdy w świecie nie użyjesz (chociażby moduł podczerwieni). I o ile te moduły de facto nie są ładowane, to fizycznie wciąż muszą być dostępne w razie, gdybyś podłączył nowe urządzenie wymagające określonego drivera. Kernel rekompiluje się z kilku powodów. a) Żeby być "na czasie", czyli wtedy, kiedy nowy kernel ma wsparcie dla określonej rzeczy, której wymagasz / chcesz b) Żeby zaaplikować kernelowe łatki, takie jak wsparcie grsecurity czy dodatkowe nieoficjalne moduły/funkcje/inne łatki. c) Żeby stworzyć jądro skompilowane konkretnie pod daną maszynę, w tym zastosowanie CPU-profilingu -mtune, który kompiluje kod konkretnie pod dany procesor/architekturę. d) Żeby odchudzić jajko ze wszystkich niepotrzebnych modułów, tak aby było mniejsze i działało szybciej. Ja kompilując kernela używam każdego z tych podpunktów. Ściągam najnowszego kernela z kernel.org, potem ściągam na niego najnowszą łatkę grsecurity z grsecurity.org, potem ściągam config OVH z ftp://ftp.ovh.net/made-in-ovh/bzImage, następnie aplikuję łatkę na kernela, odpalam config OVH, który jest już wstępnie zoptymalizowany i robię kilka zasadniczych modyfikacji: 1. Zmieniam target CPU z generic na Intel Atom, z racji że taki właśnie mam aktualnie na serwerze. 2. Wyłączam wsparcie dla procesorów innych niż Intel, oraz wszystkie funkcje AMD, których nie posiadam. 3. Włączam grsecurity 4. Optymalizuję jajko poprzez kilka zabiegów - w tym optymalizacja likely/unlikely, zmiana kompresji kernela, wywalenie całego debuga, frame pointerów i innych zbędnych rzeczy. 5. Wyłączam nieużywane przeze mnie funkcje, w tym tonę filesystemów (ext2, ext3, btrfs, xfs, jfs, nfs, cifs i więcej), tonę layoutów partycji i inne rzeczy. 6. Inne rzeczy, których już mi się nie chce pisać. Finalnie kompiluje nowego kernela, instaluję go, rebootuje maszynę i wszystko jest szybsze niż kiedykolwiek. Jeśli chcesz zrobić jednego kernela pod każdy z serwerów, których używasz należy upewnić się, że zawiera on wszystkie moduły, które są potrzebne każdemu z serwerów. Moduły zasadniczo są bardziej preferowane niż built-in rzeczy, aczkolwiek funkcje używane na każdym serwerze powinny być zaznaczone jako built-in, w szczególności takie rzeczy jak np. wsparcie dla dysków twardych, bez którego kernel po prostu nie zbootuje.

Racja, używajmy przestarzałego sysvinit'a, który nigdy nie był tworzony z myślą o dzisiejszych potrzebach i zastosowaniach, albo ubuntowskiego upstarta, który ze stabilnością i kompatybilnością ma tyle samo wspólnego co najnowsze wydanie developerskie . Systemd to jedno z najlepszych rozwiązań na tą chwilę.

Podliczyłem i stara oferta wciąż wypada nieco lepiej. Razem netto47.97 PLN VAT (23 %)11.03 PLN Za 3 miesiące 59 zł z VAT .

Wrzuć do jakiegoś pliku .txt wszystkie pliki do pobrania. Następnie napisz sobie taki skrypt: #!/bin/bash PLIK="plik.txt" echo "Pobieranie w toku..." while read LINE; do wget "$LINE" >/dev/null 2>&1 & done <"$PLIK" wait echo "Pobieranie ukonczone" exit 0 Ew. możesz zastąpić wget "$LINE" >/dev/null 2>&1 & komendą wget -b "$LINE" >/dev/null 2>&1. Kwestia konwencji czy chcesz robić forki pod kontrolą czy bez kontroli. Jak je masz pod kontrolą to możesz dorzucić wait, tak jak ja to zrobiłem, żeby skrypt dał Ci znać kiedy skończy, oczywiście jeśli tego chcesz.

Znalazłem swojego starego maila .

Zapodaj szklaną kulę to ci powiem.

U mnie na IE 11 śmiga bez problemu twoja strona.

Takie coś można osiągnąć wszystkim właściwie. Do prostych schematów możesz użyć płatnego Visio, albo darmowego np. LibreOffice'owego Draw'a.

Po co tak kombinować? Linux ma coś takiego pięknego jak symbolic linki. W swojej stronie, która jest np. w /var/www możesz sobie podlinkować phpmyadmina z np. /usr/share/phpmyadmin komendą ln -s /usr/share/phpmyadmin /var/www/phpmyadmin. 99% problemów nginxowego rewrite'a można rozwiązać JEDNĄ prostą regułką: location / { try_files $uri $uri/ /index.php?$args; } Zamiast kombinować z kilkoma.

Tak, pod kilkoma warunkami: 1. Kernel wspiera architekturę na którą jest kompilowany. 64-bitowy kernel nie pójdzie na x86. 2. Kernel wspiera dany procesor, opcja wspieranych procesorów jest domyślnie ukryta (wymagany tryb expert), więc pewno ok. 3. Kernel wspiera wszystkie specyficzne dla twojej maszyny moduły. Trzeci punkt jest najtrudniejszy, bo jest to taka mała ruletka w przypadku dedyków. OVH na ten przykład udostępnia configi do kerneli, które dostarczają, przez co możesz być pewny, że startowy config jest już odpowiednio zoptymalizowany pod ich sprzęt, czyli wywalili to co zbędne. Współczesne domyślne kernele systemów operacyjnych to jedna wielka bańka modularna. Kernel ma wsparcie dla prawie wszystkich podzespołów, urządzeń i konfiguracji, ale ładuje tylko te moduły, które są w danej chwili potrzebne. Oczywiście możesz wziąć takowy kernel i samemu skompilować, ale będzie on po prostu wolny, duży, i będzie się wolno kompilował. Jednym z lepszych pomysłów jest zanotowanie jakie moduły załadował kernel np. debiana, a następnie upewnienie się, że wszystkie są dostępne. Jeśli kompilujesz na tą samą maszynę to masz plus w postaci make localmodconfig, który zrobi to, co opisałem wyżej.

Priorytet - im mniejszy, tym bardziej ważny, jak priorytety w Linuxe. Waga - Określa "rozrzucanie". Im większa waga, tym więcej przyjmie serwer w stosunku do serwera z tym samym priorytetem, ale niższą wagą.

To drugie możesz uzyskać tylko w przypadku, gdy pola mają wartość domyślną DEFAULT, jeśli takowej nie mają (a są wymagane), wrzucenie tam nieprawidłowej wartości wyrzuci error, co zresztą jest logiczne.

ls -l /home/testowy pokaż.

cd: /usr/home/bryn1u/ports-build/work/mpfr-3.1.2: No such file or directory

Ty to umiesz rozweselić człowieka z samego rana .

Docelowy dir musi być w posiadaniu roota. chown root:root /home/mojuser.