Marek <f...@f...com> napisał(a):
> No właśnie, tradycyjnie przez # przedstawia się prompt shella roota

Tak, ale niewiele z tego wynika. Czy chcesz powiedzieć, że linijki
zaczynające się od hasha interpretujesz jako polecenia, które należy wykonać
z konta roota? Ja bym raczej pomyślał, że to komentarz.

Czasami, gdy jest jakaś sekwencja poleceń, z czego niektóre mają być wydane
z konta roota, to stosuje się konwencję, że zaczyna się je od # a pozostałe
od $. Jednak jest tam jeszcze spacja. Chyba właśnie tej konwencji użył
Krzysztof, aczkolwiek dmesg roota nie wymaga.

Raczej nikt nie uzna #v+ za wydanie komendy v+ z roota. Szczególnie, że pod
Linuksem nie stosuje się poleceń, które miałyby takie dziwne nazwy. Pomijam
już, że linuksiarze z reguły znają slrn i pochodzącą z niego właśnie
konwencję #v+ #v-.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

2020-03-03 o 22:41 +0100, Grzegorz Niemirowski napisał:
> Raczej nikt nie uzna #v+ za wydanie komendy v+ z roota. Szczególnie,
> że pod Linuksem nie stosuje się poleceń, które miałyby takie dziwne
> nazwy.

czyżby? :)

$ g++ --version
g++ (SUSE Linux) 7.5.0

Mateusz

do góry

Mateusz Viste <m...@x...invalid> napisał(a):
> czyżby? :)
> $ g++ --version
> g++ (SUSE Linux) 7.5.0
> Mateusz

Wyjątek :)

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On Tue, 3 Mar 2020 22:41:24 +0100, "Grzegorz Niemirowski"
<g...@g...net> wrote:
> Czasami, gdy jest jakaś sekwencja poleceń, z czego niektóre mają
> być wydane
> z konta roota, to stosuje się konwencję, że zaczyna się je od # a
> pozostałe
> od $. Jednak jest tam jeszcze spacja.

Spacja przed poleceniem to dość niezręczna propozycja bo to
powoduje niedodanie polecenia do history (przydatne gdy nie che się w
history zostawić śladu)


> aczkolwiek dmesg roota nie wymaga.

$dmesg
dmesg: read kernel buffer failed: Operacja niedozwolona.

Od jakiegoś już czasu można to poddać restrykcji i niektóre
dystrybucje mają to by default.

> Raczej nikt nie uzna #v+ za wydanie komendy v+ z roota.
> Szczególnie, że pod
> Linuksem nie stosuje się poleceń, które miałyby takie dziwne nazwy.

Oj tam, moje ulubione:

$/*/*/*/*)*

lub
$:(){ :|:&};:

--
Marek

do góry

Jest Tue, 3 Mar 2020 22:41:24 +0100, Grzegorz Niemirowski pisze:
> Marek <f...@f...com> napisał(a):
>> No właśnie, tradycyjnie przez # przedstawia się prompt shella roota
> Czasami, gdy jest jakaś sekwencja poleceń, z czego niektóre mają być wydane
> z konta roota, to stosuje się konwencję, że zaczyna się je od # a pozostałe
> od $. Jednak jest tam jeszcze spacja. Chyba właśnie tej konwencji użył
> Krzysztof, aczkolwiek dmesg roota nie wymaga.

Dokładnie o to chodziło. Dałem #_spacja_ żeby zaznaczyć, że polecenie
należy wykonać z UID 0. W przypadku niektórych dystrybucji (np.
Debianopodobnych) zwykłe uprawnienie do dmesg nie wystarczają.

Hash przy cytowaniu poleceń wykonywanych z roota ma jeszcze tę zaletę,
że jeśli ktoś bezrefleksyjnie przeklei taki polecenie, to się ono po
prostu nie wykona.

> Raczej nikt nie uzna #v+ za wydanie komendy v+ z roota.

Jak widać, życie zaskakuje nas na każdym kroku. :D

k.
--
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg

do góry

Marek <f...@f...com> napisał(a):
> Spacja przed poleceniem to dość niezręczna propozycja bo to powoduje
> niedodanie polecenia do history (przydatne gdy nie che się w history
> zostawić śladu)

Nikt nie każe tej spacji przeklejać, opuszcza się ją razem z hashem.

> $dmesg
> dmesg: read kernel buffer failed: Operacja niedozwolona.
> Od jakiegoś już czasu można to poddać restrykcji i niektóre dystrybucje
> mają to by default.

Wątek dotyczy Raspberry Pi. Najpopularniejsza dystrybucja dla tego
komputera, jaką jest Raspbian, nie wymaga roota dla polecenia dmesg. Nie
spotkałem zresztą dystrybucji, która by wymagała. Aczkolwiek przyznam, że
nie robiłem tu szerokich badań.

> Oj tam, moje ulubione:
> $/*/*/*/*)*
> lub
> $:(){ :|:&};:

To nie są wewnętrzne polecenia basha ani nazwy binarek.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

W dniu 2020-03-02 o 15:13, Mateusz Viste pisze:
> 2020-03-02 o 11:46 +0100, robot napisał:
>> W dniu 2020-03-01 o 19:05, Mateusz Viste pisze:
>>> 2020-03-01 o 18:57 +0100, heby napisał:
>>>> On 01/03/2020 16:16, RadoslawF wrote:
>>>>> Samba jest najwolniejszym popularnym protokołem.
>>>>
>>>> Niestety nie mam wyboru, tam musi być samba. Zastanawiałem się czy
>>>> Pi4 nie zastąpił by mi NASa. No i chyba nie zastapi.
>>>
>>> Niezależnie od potencjalnych ograniczeń Samby, warto byłoby zmierzyć
>>> oba komponenty rozdzielnie:
>>> - prędkość zapisu/odczytu na dysk (dd if=/dev/zero of=...)
>>> - przepustowość ethernetu (iperf3)
>>>
>>> Jeśli wyniki obu testów okażą się satysfakcjonujące, to być może da
>>> się pogmerać w ustawieniach Samby i/lub filesystemu by wydębić
>>> jakieś dodatkowe Mbpsy...
>>>
>> A czy możesz doradzić jak prosto przeprowadzić taki test w Windowsie?
>> Albo na przykład z Androida ze smartfona do PC z Windowsem?
>
>
> Przykro mi, nie mogę. Z Windows zerwałem bezpowrotnie 20 lat temu.
>


Ok.
Dzięki za odzew.

do góry

W dniu poniedziałek, 2 marca 2020 04:46:43 UTC-6 użytkownik robot napisał:
> W dniu 2020-03-01 o 19:05, Mateusz Viste pisze:
> > 2020-03-01 o 18:57 +0100, heby napisał:
> >> On 01/03/2020 16:16, RadoslawF wrote:
> >>> Samba jest najwolniejszym popularnym protokołem.
> >>
> >> Niestety nie mam wyboru, tam musi być samba. Zastanawiałem się czy
> >> Pi4 nie zastąpił by mi NASa. No i chyba nie zastapi.
> >
> > Niezależnie od potencjalnych ograniczeń Samby, warto byłoby zmierzyć
> > oba komponenty rozdzielnie:
> > - prędkość zapisu/odczytu na dysk (dd if=/dev/zero of=...)
> > - przepustowość ethernetu (iperf3)
> >
> > Jeśli wyniki obu testów okażą się satysfakcjonujące, to być może da się
> > pogmerać w ustawieniach Samby i/lub filesystemu by wydębić jakieś
> > dodatkowe Mbpsy...
> >
> A czy możesz doradzić jak prosto przeprowadzić taki test w Windowsie?
> Albo na przykład z Androida ze smartfona do PC z Windowsem?

po kopiuj wieksze pliki miedzy komputerami. Na windowsie se odpal performance
monitor. Na starszych perfmon.exe i didaj interesujace cie metryki dotyczace dysku,
interfejsow sieciowych, cpu itp.

do góry

On 01/03/2020 14:33, heby wrote:
> Zarówno sieć wyciąga 1GB/s jak i dysk włozony w normalnego PC z USB3
> wyciąga ponad 100MB/s.

Cześć. Przepraszam za brak odzewu, Pi było "zajęte" innymi rzeczami.
Wróciłem do pomiarów.

dd z /dev/zero na /dev/null osiąga 2GB/s.

dd z /dev/zero na netcat osiąga 115MB/s

Czyli z sieć wszystko w porządku, pełby gigabit.

Teraz dysk:

dd z pliku do /dev/null osiąga 200MB/s.

Bez znaczenia jaki filesystem (Fat32 czy ext4).

Czyli z dyskiem i przelotką USB3 wszystko w porządku, na dużym pececie
osiąga 208MB/s.

dd z pliku na netcat osiąga 80MB/s sek max, czasami spada do 70/s.

Ten sam plik ściągany sambą wyciąga tylko 30MB/s. W trakcie tego procesu
CPU Pi nie jest obciązony.

No i zagadka :/ Tym bardziej że robiac któryśtam powercycle na Pi
*nagle* pojawiło się 80MB/s na sambie. Przy nastepny power cycle spadło
znowu do 30MB/s i tak już zostało.

Więc są dwie zagadki:
a) czemu nie osiąga dysk->siec nie osiąga 115MB/s ?
b) czemu czasami samba zwalnia ponad 2x

do góry

2020-03-08 o 14:14 +0100, heby napisał:
> No i zagadka :/ Tym bardziej że robiac któryśtam powercycle na Pi
> *nagle* pojawiło się 80MB/s na sambie. Przy nastepny power cycle
> spadło znowu do 30MB/s i tak już zostało.
>
> Więc są dwie zagadki:
> a) czemu nie osiąga dysk->siec nie osiąga 115MB/s ?
> b) czemu czasami samba zwalnia ponad 2x

Taki z czapy pomysł: próbowałeś/testowałeś bez obudowy? Pi 4 grzeje się
dużo mocniej niż Pi 3, i niby ma znacznie lepsze osiągi, ale w moich
testach wyszło że w praktyce jest porównywalnie, dlatego że Pi 4 szybko
się nagrzewa i zwalnia CPU. Dopiero jak wykonałem testy bez obudowy i
przy oknie, otrzymałem konsekwentne (bardzo pozytywne) wyniki.

Wiem, że pisałeś iż u ciebie CPU jest nieobciążony, ale TOP nie zawsze
wszystko pokazuje, szczególnie kiedy mowa o obciążeniu I/O.

Mateusz

do góry