(no subject)
Dec. 8th, 2004 | 12:34 pm
From:: drako
Nezinu, ko tu ar to domāji, bet no savas pieredzes gibās teikt ...
Tādi navaroti, kā zem windows nav ... toties ir sava specifika, kas reizēm ir patīkama (piemēram detachable menu, kas liekas ir gtk+ strandarta fīča)
Galvenais gļuks ar borlandu ir tas, ka viņš ir nevis paņēmis un papildinājis standarta unix bibliotēkas (gtk+, tcl/tk vai kādu citu), bet gan taisījis savas pilnīgi no jauna. Ja izgudro riteni no jauna tad vienmēr rodas problēmas ...
Un vispār vienmēr esmu uzskatījis ka labākie unix risinājumi ir consoles aplikācija + krafiskais frontends. Kā pioemēram eroaster - forntends konoles tūļiem cdrecord, mkisofs ...
Negribu nevienam uzspiest savu patiesību, vienkārši mans vērojums ir tāds, ka zem unix ir sava filozofija par to, kā liela sistēma tiek veidota no mazām utilitām, kas savstarpēji komunicē ar vienkāršiem interfeisiem (sistēmas komandas ,parsēts parastais stdin/stdout teksts vai XML ...)
Unix no Windos atšķirās ar to, ka zem unix jaunas programmas palaišanās notiek momentāli ... ja līdzīgu dizainu mēģinātu realizēt zem Windows, tad sistēma momentāli strādātu ĻOTI lēni, jo, cik es savulaik sapratu, viņai ir stipri komplicētāks jaunas programmas palaišanas process, nekā zem UNIX. Iespējams, ka viena no problēmām sakņojas vecajos labajos 640K ... Microsofts liekas joprojām visām programmām uztur paralēli visus arhaiskos atmiņas menedžmenta modeļus (C programmeri gan zin, par ko iet runa), kur zem UNIX, cik zinu šāda problēma neeksistē (Eksistē viens vienīgs LARGE atmiņas modelis un āmen). Varbūt kļūdos, jo galvenokārt šī informācija ir pa kripatai savākusies runājot ar dažādiem cilvēkiem no viņu atsauksmēm. Vēlreiz saku, ka pats zem UNIX neko vairāk par Hello.c neesmu rakstījis :)) - nav bijusi vajadzība - esmu izticis ar perl, tcl, sh/bash/tcsh ... tie ir ļoti spēcīgi intrumenti sistēmā un kodēt iekš C man nav bijusi nepieciešamība ...
Tādi navaroti, kā zem windows nav ... toties ir sava specifika, kas reizēm ir patīkama (piemēram detachable menu, kas liekas ir gtk+ strandarta fīča)
Galvenais gļuks ar borlandu ir tas, ka viņš ir nevis paņēmis un papildinājis standarta unix bibliotēkas (gtk+, tcl/tk vai kādu citu), bet gan taisījis savas pilnīgi no jauna. Ja izgudro riteni no jauna tad vienmēr rodas problēmas ...
Un vispār vienmēr esmu uzskatījis ka labākie unix risinājumi ir consoles aplikācija + krafiskais frontends. Kā pioemēram eroaster - forntends konoles tūļiem cdrecord, mkisofs ...
Negribu nevienam uzspiest savu patiesību, vienkārši mans vērojums ir tāds, ka zem unix ir sava filozofija par to, kā liela sistēma tiek veidota no mazām utilitām, kas savstarpēji komunicē ar vienkāršiem interfeisiem (sistēmas komandas ,parsēts parastais stdin/stdout teksts vai XML ...)
Unix no Windos atšķirās ar to, ka zem unix jaunas programmas palaišanās notiek momentāli ... ja līdzīgu dizainu mēģinātu realizēt zem Windows, tad sistēma momentāli strādātu ĻOTI lēni, jo, cik es savulaik sapratu, viņai ir stipri komplicētāks jaunas programmas palaišanas process, nekā zem UNIX. Iespējams, ka viena no problēmām sakņojas vecajos labajos 640K ... Microsofts liekas joprojām visām programmām uztur paralēli visus arhaiskos atmiņas menedžmenta modeļus (C programmeri gan zin, par ko iet runa), kur zem UNIX, cik zinu šāda problēma neeksistē (Eksistē viens vienīgs LARGE atmiņas modelis un āmen). Varbūt kļūdos, jo galvenokārt šī informācija ir pa kripatai savākusies runājot ar dažādiem cilvēkiem no viņu atsauksmēm. Vēlreiz saku, ka pats zem UNIX neko vairāk par Hello.c neesmu rakstījis :)) - nav bijusi vajadzība - esmu izticis ar perl, tcl, sh/bash/tcsh ... tie ir ļoti spēcīgi intrumenti sistēmā un kodēt iekš C man nav bijusi nepieciešamība ...