Valojaban jelenleg az intel az aki agyatlanul elkeri mindennek az arat.
Ez nagyjából egy árú az alap 16ossal: https://www.razer.com/gaming-laptops/razer-blade/shop#rtx2070--fhd-240hz-9thgen--512gb-opto-black
Bár ugye ez már nem alap modell, i7-i9 cpu, GTX 2070 vga (lehet 2080 is akár).
Egyetlen egy hátránya van, hogy csak 1080p a kijelző (mondjuk 240hz nem csöves 60), cserébe erősebb cpu, sokkal erősebb vga, jobb hűtés stb. Bármilyen extra upgradeért meg nem kell bankot robbantani. Ja és a Razer az szintén nem egy olcsó gyártónak számít.
Ja és az sem szól az Apple mellett hogy vásárlás után bővíthetetlen (javíthatatlan) az összes gépük kb.
Azert ez egy lenyegesen szarabb kijelzo, szerintem nem is alu a haz. Amugy hw-ban jo gepek a razerek de 18 ev felett mar nagy nem szivesen mutogatja az ember. Nem latom hany usb-c van rajta. Es oke touchscreen nincs rajta de ezt a plusszt nem is kompenzalja valamivel. De ezeket a gepeket is lehet kerni 4k kijelzovel nem?
Jah es ui. Most latom 2,3 kg 🤣
Szerintem az upgrade a felháborító az Applenél, nem a gépek alapára.
2 kedvelés
Abban nem vagyok biztos, hogy rosszabb lenne a kijelző. Oké a felbontás kisebb (valószínűleg van amúgy 4K verzió, nem néztem meg), de a képfrissítés sokkal nagyobb ( ez egy szégyen hogy még mindig csak 60 az MBP-n, valószínűleg az amúgy is gyenge vga még jobban érződne 120hz-nél), és maga a panel minősége egyáltalán nem rosszabb.
Ház az unibody, nem műanyag.
1 TB3 port van rajta, mondjuk több nem is kell.
Megnéztem a 16os MBP meg 2kg: most komolyan 0.3kg különbség az ennyit számít? Szerintem észre sem vehető különbség.
A hardver fényévekkel jobb mint bármelyik Apple laptopban, és itt van hűtés is hozzá.
Ezt a 18 év felett már gáz használni dumát nem is értem, azért ez egy elég szubjektív dolog, én pl simán bevinném dolgozni, oké mondjuk a billentyűzet világítást beraknám konstans fehérre azt ennyi, de amúgy ez egy full fekete laptop, mi a gond vele? :D
Mindegy azt megadom, hogy a MacBook kijelző az legtöbbször jobb ( bár kinek melyik dolog fontos (felbontás/képfrissítés)), meg jobb a MacBook trackpad, meg MacOS de így ennyi.
Azt nem mondom hogy sokkal jobb mint egy MBP de azért azok az idők már elmúltak amikor tényleg csak az MBP volt a piacon egyedül értelmes gép a kategóriájában.
1 kedvelés
Szerintem az nincs rendben, hogy 950ezerről indul egy valamire is használható 15ös (16) gép az Applenel.
Vegulis csak pont az a jobb amit nezel es amit tapizol, meg az OS. :) hat nekem sokszor a 4 usb is elfogy a gepen es nem gond az usb-c. Mindenki ezen sirdogalt siman amazonon megrendeltem az usb-c - usb-b kabelet es mostmar ezt hasznalom. Ennyi.
Amugy a tacsbart is szidtak jo sokan nekem kb 3 nap meglett par olyan dolog amiert nagyon jo hogy van.
Megjeleneskor 2500 euroert vettem amazonon a 16”-os gepet. Most ezert kapni fogok de ez egy havi fizetes nyugaton (melosber). Akinek olcsobb gep kell ott van az air. Vagy reklamaljuk miert nincs 7es bmw 3 hengeres motorral meg fujjva 2 turboval hogy hozza a 78 lovat.
Nem a fizetések miatt drága a gép, itthon is lehet ennyit keresni bőven. A konkurenciához kell nézni, ahol viszont olcsóbban, erősebb gépeket árulnak. Nyilván vannak aspektusok ahol meg az MBP lesz jobb.
Air-t meg senki nem fog venni azért mert drága az MBP, az Airben gyenge a hardver, teljesen más célra van az a gép, más célközönsége van.
Ha prémium autót veszel akkor prémium szolgáltatást kapsz hozzá, na az itt már nem fért bele: pl 1 éves gari, régen adtak törlőkendőt is a géphez, töltőhosszabbitót stb. Ezeket mind megspórolták.
Aha otthon persze 2500 netto. Ha yahtozol horvatban vagy alsohangon kozepvezeto teteje.
Nem tudom, rengeteg ismerősöm a Morgan Stanley/ Ericssonnál van, szerintük nem “simán”, de kb majdnem. Mondjuk más területen, pl orvos / ügyvéd még sokkal többet is lehet. Vannak fizikai munkát végző ismerőseim is, pl kőműves, igaz ott valószínűleg nem teljesen fehéren, de hasonló összegeket lehet keresni.
Amúgy a 2500€ az nem számít egy jó fizetésnek külföldön (Ausztriában/Németországban), nyilván egy ott jónak számító 4-5000€ azt már itthon nem nagyon lehet elérni.
A 240 hertzre biztos nagy szükség van :)
(meg 15"-on a 4k-ra)
Ha pl a 13"-asba raknanak 4k kijelzot, akkor a mostani @2x helyett az @3x kijelzo lenne (jelenleg @3x kijelzo van pl. a 6+, 6s+, 7+, 8+, X, Xs, XsMax, 11Pro, 11ProMax telefonjaikba). Siman elferhetne itt is. Raadasul en pl. a 13"-as Prot 1920x1200-as virtualisban hasznalom, ha @3x kijelzo lenne benne a mostani @2x helyett (tehat 3840x2400 lenne a mostani 2560x1600 helyett), az azt jelentene, hogy tudnam hasznalni valodi retina modban 1920x1200@2x felbontasban. Szoval, en tamogatom a @2x-@3x valtast. Jelenleg jobban orulnek, ha a 13"-as gepemben 1920x1200 lenne, mert akkor nem kellene az 1920x1200-hoz 1.33333 zoomot alkalmazni.
Aha persze, kerdezuk meg a hofferes eladot vagy a postast. Biztos azt mondja majd mind 3500 a nettom 🤣
2 kedvelés
Nem is tudom hol kezdjem el. Igazából csak annyiról van szó, hogy ki akarom magamból adni a dühömet. Szóval nem várok semmilyen megfejtést sem a következőkhöz. :)
Előzetesen arról van szó, hogy egy régi SLES webszerverről (apache, mysql, és php 5.3) kell átállni új SLES szerverre. Az előző szervert közel 7 éve üzemelték be. Akkoriban php 5.3 alá írtak egy alkalmazást. A szervert és környezetet nekem kell kialakítani, de a weboldal működését egy olyan srácnak kell megoldania, aki egyáltalán nem ért a fejlesztéshez (legalábbis tapasztalatok alapján) és az egész szerver-kliens oldali működéshez. 7 éve a kódot nem ez a srác írta, hanem egy ténylegesen hozzáértő (aki ráadásul felül is írt php alap osztályokat saját metódusokkal, ami persze most évekkel később nagy nehézségeket okozott).
Szóval php 5.3-ról kell átállni 7.2-re. Én sem szívesen vállalnám be ezt, pedig még van is közöm a php-hoz. Szóval a legfontosabb az egészben az, hogy egy olyan srácnak kell ezt megcsinálnia, aki egyáltalán nem ért hozzá. (Hogy miért ő kapta a feladatot, abba most ne menjünk bele). Hozzáteszem a szerver oldali php, apache és mysql beállításokkal mi is szívtunk egy ideig, a külső levélküldéssel gyűlt meg kicsit jobban a bajunk, de mikor megoldottuk, jeleztük a srácnak, hogy működik, teszteltük. A levélküldést szándékosan emeltem ki, mert azzal kapcsolatos a kód, ami a végén van.
Amin mindig felhúzom magam, az három dolog, amit a srác állandóan kijelentget:
- “Ez biztos szerver oldali hiba, hiszen a régi szerveren tökéletesen működött!”
- “Ezt biztos meg lehet oldani szerver oldalról, nem hiszem, hogy ehhez a php kódot át kellene írnom!”
- “Ez biztos szerver oldali hiba, hiszen ugyan ez a kód működik más szolgáltatóknál tökéletesen!”
Persze ezek nyilván nem szó szerinti idézetek.
Az elsőhöz csak annyit tudok hozzáfűzni, hogy nem érti, hogy miért nem működik ugyanaz php 7.2 környezetben, ami korábban php 5.3-ban működött.
Második kijelentés az ami miatt most írom ezt az egészet. A harmadik kijelentéssel kapcsolatos kiakadásom amúgy korábbi volt, csak az hosszabb. :)
Az egész átállás megkezdésekor megbeszéltük, hogy a végén http helyett átállunk https-re, nyilvánvaló okok miatt. Persze a legvégén, amikor minden működik http-vel, mint régen.
Egyik pillanatról a másikra jött a döntés, hogy az új szervert be kell élesíteni. Csak annyira hirtelen jött a döntés, hogy a https-re való átállás a végén kimaradt. Beüzemeltem az új szervert és mikor ellenőriztem, hogy működnek-e a weboldalak, akkor vettem észre, hogy nem csináltuk meg a https-re való áttérést. Én megcsináltam a tanusítványokat, bekonfiguráltam az apache-ot, hogy működjön akár https-sel is, de még nem csináltam meg a redirectet http-ről https-re. Ugyanis az oldal telis-tele van http hívásokkal. Azt nyilvánvalóan a php-ban cseréni kell. Ezek nagy része egyébként külső hivatkozások, mint külső cdn-ről származó js-ek és google fontok, stb. Amikor megnyitom az oldalt https-sel, a Chrome nem is tölti be ezeket arra hivatkozva, hogy az a rész nem biztonságos.
Jeleztem a srácnak, hogy majd valamikor át kell írni mindenhol http-ről https-re a kódban. Erre visszaküldött egy apache redirectet, hogy hogyan tudom én ez megoldani szerver oldalról. Erre visszaválaszoltam neki, hogy igen, az lesz a vége, de addig nem tudom megtenni, míg ő át nem írja a kódban a dolgokat. Ezt részletesebben próbáltam neki elmagyarázni miért. Erre megint visszaválaszolt, hogy márpedig szentül hiszi, hogy ezt szerver oldalról meg lehet oldani és nem neki kell ezt átírni a php-ban. Ez az a pont, ahol feladtam. Be van állítva https-re az oldal, aki akarja úgy használja, aki akarja nem. Ha jelzi, hogy csináljam meg a redirectet, akkor megcsinálom, ha nem, akkor marad így minden. :D
Harmadik kijelentéshez: a végére bemásolok egy ~60 soros php kódot szemléltetés képpen, hogy mi az ami működik máshol és mi az ami nálunk nem. (Nyilván majd kiszedem az érzékeny részeket.)
Sztori az akkori felháborodásomhoz:
December közepén volt egy olyan pont, ahol levélben a felettesét (és az én felettesemet) is be CC-zve majdhogynem elküldtem a srácot melegebb éghajlatra. Ez a srác eleinte fogva naponta többször hívogatott. Szinte mindennap 1-1 órát segítettem neki telefonon, hogy elinduljon a php alkalmazás egyáltalán, megmutattam neki hogyan tud debuggolni. Hol melyik logban tudja megnézni, ha hibát dob neki a php. Sőt greppeltem is neki fájlokat, hogy mit melyik fájlokban kell átírni. Egyik nap decemberben jeleztem neki, hogy délután nem vagyok elérhető. Ne hívjon, mert nem veszem fel. Erre óránként legalább egyszer megpróbált felhívni, több sms-t is küldött, hogy sürgős, hívjam vissza. És akkor küldte el nekem a lentebbi kódot, mert arra hivatkozott, hogy még mindig nem megy a levél küldés és biztos, hogy szerver oldali hiba van és ugyanez a kód tökéletesen fut más szolgáltatóknál.
A levélben, amit írtam neki ekkor és ami legnagyobb felháborodásomat keltette az az, hogy saját gmail-es címe volt berakva, mint feladó (mármint nyilván az a feladó amelyik megjelenik a levelezésben a felhasználónak és nem az a cím, amiről kimegy a levél), és ugyanarra a saját gmailes címre próbálta elküldeni a levelet. Nos az ilyen levelek a tipikus adathalász levelek. Az ilyen levelek miatt könnyedén egész cégünket adathalászként jelölhetik meg, ezzel “letiltva” több ezer felhasználó levelezését. Arról meg nem beszélve, hogy több sebből vérzik az egész php kód. Pl a kedvencem az, hogy csinál egy (mindig) két elemű tömböt, majd for ciklussal megy rajta végig, ahol egy változót 0-ról egyre billent és aszerint fut le a két külön levélküldés. Egyébként telis tele van hibákkal, átgondolatlanságokkal ez a rövid kód. Igazából ebből lehetne csinálni egy kvízt, hogy ki fedez fel benne több hibát és értelmetlenséget. :D
És végére, hogy konkrétan miért nem működött a mi szerverünkön ez a kód: csak annyi, hogy a tárgyban ékezetes karakter volt. Nyílván oda csak base64 kódolt szöveggel lehetne ékezetes karaktert tenni. Egyébként el tudom képzelni, hogy valójában működhetett ez a kód másnál, el tudom képzelni mondjuk, hogy más szerveren felülírják a php mail függvényét, hogy a tárgyat mindig kódolja be base64-be…
(Ahol a stringben három pont van, ott módosítottam a kódot, azaz kivettem az érzékeny adatokat. A kódban a kitől, kinek és a végén lévő funkcióban szereplő gmail-es cím ugyanaz.)
<?php
$task = ( isset($_GET["task"]) && !empty($_GET["task"]) ) ? (int)$_GET["task"] : 0;
echo "task: ".$task. "<hr>";
$_system_kitol_email[1] = "...@gmail.com";
// kinek megy a regisztrálókról email
$_system_kinek_email[1] = "...@gmail.com";
function sendLetter($subject, $kinek_email="", $reguserid="", $nev="", $t=0, $lettertemplates="", $lettertemplates2="", $sztsz=""){
global $_system_kitol_email, $_system_kinek_email;
$targy = "Regisztráció-".$nev."-".$sztsz;
$style = "";
$header_title = "";
$datum = date("Y-m-d H:i:s");
$uzenet = $lettertemplates2;// üzenet az adminnak
$uzenet_user = $lettertemplates;
$kitol = $_system_kitol_email[1];
$fromx = "...XY";
$mailtomb = array($kinek_email);
for($i=1; $i<count($_system_kinek_email)+1;$i++){
array_push($mailtomb,$_system_kinek_email[$i]);
}
//$headers = "From: ".$kitol." \r\n"."Reply-To: {$kitol}";
//$headers .= "\r\nMIME-Version: 1.0\r\n" . "Content-type: text/html; charset=utf-8" . "\r\n" ."X-Mailer: PHP/".phpversion();
/* $headers = 'From: '. $kitol . "\r\n" .
'Reply-To: '. $kitol. "\r\n" . 'Return-Path: '. $kitol . "\r\n" . 'X-Mailer: PHP/' . phpversion();
*/
$headers = 'From: '. $kitol . "\r\n";
$headers .= 'Reply-To: '. $kitol. "\r\n" . 'Return-Path: '. $kitol . "\r\n";
$headers .= 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=UTF-8' . "\r\n";
$headers .= 'X-Mailer: PHP/' . phpversion();
$k=0;
foreach($mailtomb as $mail){
if( $k == 0 ){
$targy_user = $subject;
mail($mail, $targy_user, $uzenet_user, $headers);
}
else{
if($lettertemplates2!=""){
mail($mail, $targy, $uzenet, $headers);
}
}
$k++;
}
return $uzenet;
}
$v = sendLetter("teszt levél sajat szerverrol 2", "...@gmail.com", 1, "...XY", $t=0, "<p>helló</p>", "<p>levél az adminnak</p>", $sztsz="");
var_dump($v);
?>Mit nem értek? Mindent, vagyis semmit. :)
Ez botrányos, bár én már csak azért is kirúgnám az ilyet, mert magyar változóneveket használ :D
2 kedvelés
Idonkent hasonlo szituacioban vagyok. Nalunk az elso dolog, hogy egy kijelentes (szerver oldali / alkalmazas hiba) addig csak egy ures mondat, amig nincs bizonyitva valamivel. Ez lehet log reszlet, konfiguracio reszlet magyarazattal, stb.
PHP-hoz nem ertek, de altalanossagban, ha ti hasznaljatok az alkalmazast, akkor lehet erdemes masik konzultanst keresni, vagy masik alkalmazast.
Egy cégen belül dolgozok a sráccal, de más szervezeti egység. Szóval abba nincs beleszólásunk, hogy ott ki csinálja ezt vagy ki ne vagy milyen kód fusson ott. Egyébként az a szervezeti egység nem is informatikai, szóval nemcsoda, hogy ez történik :).
Nálunk is külön vannak a fejlesztők (az említett srác nem ott dolgozik…) és külön az üzemeltetők. Szerencsére nagyon jó a kapcsolatunk a fejlesztőkkel. Sokszor viszont nem lehet eldönteni, hogy egy adott beállítás üzemeltetői vagy fejlesztői feladat. És mi is (nyilván) mindig logokat nézünk, hogy kiderítsük mi a baj.
Emlékszem volt olyan hiba az említett szerveres átállás során, ami a weboldalt nézve nem volt egyértelmű, hogy alkalmazás vagy szerver oldali hiba van. Legalább háromszor beszéltem erről telefonon a sráccal, háromszor mondtam el neki, hogy lehet találgatni, hogy mi a hiba, de várjuk meg, hogy mi van a logban. Végig erősködött, hogy márpedig ő tudja, hogy szerver oldai hiba, mert neki nyilvánvaló. :)
Szerintem nem becsulitek elegge a kepessegeit! :-) ;-)
1 kedvelés