- A hozzászóláshoz be kell jelentkezni
- 4819 megtekintés
Hozzászólások
RIP Defender :)
- A hozzászóláshoz be kell jelentkezni
<troll>LoL Linux kell ahhoz, hogy windows komponenseket teszteljenek, most már értem, hogy miért dolgozik a MS a WSL-en gőzerővel... :D </troll>
--
:wq
- A hozzászóláshoz be kell jelentkezni
DLL betoltest linuxon a wine utan az mplayer is csinslt kozel 20 eve. Mi az ujdonsag?
- A hozzászóláshoz be kell jelentkezni
Talán az, hogy itt nem néhány konkrét DLL átemeléséről van szó, hanem általánosan bármelyikről.
- A hozzászóláshoz be kell jelentkezni
altalanoshoz azert a windows nagy reszet implementalni kell, ezt tudja a wine. konkret dll-ekhez (pontosabban konkret API-khoz, ha jol ertettem ez is arra valo) meg jo volt a mi implementacionk is az mplayerben. szoval nekem meg mindig nem jott le mi ebben az uj...
A'rpi
- A hozzászóláshoz be kell jelentkezni
Too bad Arpi, se nem twittelted, se nem dolgoztal trendi cegnel. :)
- A hozzászóláshoz be kell jelentkezni
Egyébként Wine-nal futtatható dll-t be lehet valahogy tölteni egy egyébként Linuxos processz alá?
- A hozzászóláshoz be kell jelentkezni
Aki ezt nem sub-processz/co-processzben csinalja, azt el is kuldenem azert melegebb egtajakra.
- A hozzászóláshoz be kell jelentkezni
Úgy csináltam, de ha lehetne ugyanabban a processzben, azért annak is lennének előnyei.
- A hozzászóláshoz be kell jelentkezni
https://github.com/taviso/loadlibrary/blob/aa445174ce34f2f6dddd0763d374…
Azért ez még elég kezdetleges.
- A hozzászóláshoz be kell jelentkezni
Az, hogy MIERT csinalta ezt a libet, le is irja, hogy konkretan fuzzing-ra hasznalja (ez egyfajta automatizalt vaktesztelesi modszer), nem user felhasznalasra keszult, hanem arra, hogy individualis libeket lehessen egyszeruen es hatekonyan security tesztelni Windows helyett Linuxon.
Csak sajnos a hirt elolvasok nagy szazaleka ott leragad, hogy nem tudja ertelmezni ezt, meg persze ott a clickbait, hogy Windows Defender - tokmindegy, nem ez a lenyeg.
Szo sincs arrol, hogy ez valamifele wine-szeruseg lenne.
- A hozzászóláshoz be kell jelentkezni
"konkretan fuzzing-ra hasznalja ... Windows helyett Linuxon"
Miért, Windows alatt nem lehet?
- A hozzászóláshoz be kell jelentkezni
Ez IS benne van a leirasban, hogy ugyanannyi meglevo eroforrassal parhuzamosan tobb mindent tud futtatni linugz alatt, mint windowson. Mert a containment egyszerubb es olcsobb.
- A hozzászóláshoz be kell jelentkezni
Nem biztos, hogy megértettem a leírást, mert ott user space -> kernel átmenetet is ír. De sebaj.
Viszont én a leíráshoz hasonló dolgot figyeltem meg több taszk futtatása esetén. Ha gyakori a taszkváltás, sok semaphore és event van, akkor a Windows baromira belassul. Egy bizonyos teszt 4-10-szer gyorsabban ment Linux-on, mint Windows-on.
- A hozzászóláshoz be kell jelentkezni
Én olyan programot csináltam, ami stdout-ot sztreamel egyik processzről a másikra, és az is érezhetően lassabban - nagyobb késleltetéssel - futott Windowson. Egyelőre nem mentem utána, hogy miért, lehet hogy valami paraméterezést benéztem csak.
- A hozzászóláshoz be kell jelentkezni
Mert linugz alatt buffermeret-meretu chunkokban pakolja at balrol jobbra az adat, windowsnal meg (pl. powershellben) csak eof utan tolja be. ¯\_(ツ)_/¯
- A hozzászóláshoz be kell jelentkezni
Powershellben objektumokat passzolsz át a pipeon, akkora objektumokat csinálsz amekkorákat csak akarsz. Persze ha beolvasol egy filet egyben és azt tolod át a pipeon, akkor tényleg csak eof után fog átmenni, de ez már a programozó hibája.
- A hozzászóláshoz be kell jelentkezni
Sajnos a collection-ök is egyben mennek át... és ez a gond, mert pl egy Where-Object esetén a teljes balértéket be kell várni, miután a jobboldal (pl. maga a Where-Object) újra végigmegy rajta. Mindkettő elfecsérelt idő.
- A hozzászóláshoz be kell jelentkezni
Nekem nem úgy tűnik:
PS C:\> 1..5 | Where-Object {Write-Host "Where-Object`t$_"; $_ % 2 -eq 0} | ForEach-Object {Write-Host "ForEach-Object`t$_"}
Where-Object 1
Where-Object 2
ForEach-Object 2
Where-Object 3
Where-Object 4
ForEach-Object 4
Where-Object 5
- A hozzászóláshoz be kell jelentkezni
Mások, más mérése szerint meg nem :D
Pl. https://david-obrien.net/2014/04/filter-faster-piping-using-configmgr/ mondjuk ő nem number range-et használ. De ez egy 3 éves cikk, otthon meg lusta vagyok újramérni.
- A hozzászóláshoz be kell jelentkezni
Ez a cikk nem támasztja alá az állításodat, másról szól.
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
Ennek a Defendernek vajon van EULA-ja?
Lehet így jó lenne az Amavishoz harmadik AV-nak, persze csak ha nem csukják le érte az embert. :)
- A hozzászóláshoz be kell jelentkezni
De, pont azt taglalja, hogy minel kevesebb adatot pipe-oljal, mert kulonben foslassu es ilyenek. Azt, hogy erintoleges a temaban, azt elismerem :)
- A hozzászóláshoz be kell jelentkezni
Nem egészen. Analóg probléma mysql-lel:
echo "select * from users;" | mysql | grep "Feri"
echo "select * from users where name = 'Feri';" | mysql
- A hozzászóláshoz be kell jelentkezni
mekkora a tabla? :D
- A hozzászóláshoz be kell jelentkezni
Te ezt állítottad: "a collection-ök is egyben mennek át"
A cikkben nincs ilyen.
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
Pedig pont ez tortenik ott.
- A hozzászóláshoz be kell jelentkezni
Na akkor mérjünk:
PS C:\> function Benchmark($Count, $Expression) {
1..$Count |
ForEach-Object {Measure-Command -Expression $Expression} |
Measure-Object -Property TotalMilliseconds -Average -Sum -Maximum -Minimum
}
PS C:\> Benchmark 100 {Get-WmiObject -Class CIM_Process}
Count : 100
Average : 72,739809
Sum : 7273,9809
Maximum : 92,0155
Minimum : 69,8858
Property : TotalMilliseconds
PS C:\> Benchmark 100 {Get-WmiObject -Class CIM_Process -Filter "Name = 'powershell.exe'"}
Count : 100
Average : 65,571801
Sum : 6557,1801
Maximum : 69,5814
Minimum : 62,2024
Property : TotalMilliseconds
PS C:\> Benchmark 100 {Get-WmiObject -Class CIM_Process | Where-Object {$_.Name -eq "powershell.exe"}}
Count : 100
Average : 112,736381
Sum : 11273,6381
Maximum : 153,2535
Minimum : 103,8209
Property : TotalMilliseconds
PS C:\> Benchmark 100 {Get-WmiObject -Class CIM_Process | Select-Object -First 1}
Count : 100
Average : 31,265305
Sum : 3126,5305
Maximum : 38,056
Minimum : 24,4049
Property : TotalMilliseconds
Az látszik, hogy valamivel gyorsabb, ha már a lekérdezésben szűröm a listát, viszont jelentősen lassabb, ha a kapott listát szűröm, utólag. A kérdés az, hogy a lassulást a pipe okozza-e. A választ az utolsó lekérdezés adja meg, ami egyszerűen kiválasztja az első elemet. Ez nem csak a Where-Object-es szűrésnél gyorsabb, de még a lekérdezésben szűrő kérésnél is. Ez azt bizonyítja, hogy nemhogy nem várja be a pipe az utolsó elemet, az akár meg is szakítható, ha újabb elemek feldolgozására már nincs szükség.
- A hozzászóláshoz be kell jelentkezni
ffmpeg-gel dekódolt nyers videoképkockákat pájpoltam. Eof egyáltalán nem jön. Szerintem flush-t a küldő oldal tol. Egyébként én is valami bufferelési gondra gyanakszom, ha a bufferméret pont egy frame-nyi lenne, nem sokkal kisebb, akkor tuti sokkal jobb lenne. De még nem volt időm rendesen ránézni.
- A hozzászóláshoz be kell jelentkezni