ահ, ինչ լաւ են ապտակել սէյլֆիշը մաեմօ֊լեսթէի յաճախ տրուող հարցերում։
#մաեմօ #մաեմօ-լեսթէ #էկրանահան #սէյլֆիշ #օպերացիոն-համակարգեր #անգլերէն #ազատութիւն
բայց տխո՞ւր չի, որ մինիքսի իւզերլանդը գրեթէ ամբողջովին փոխարինեցին նէթբիէսդիի իւզերլանդով։
հիմա մենք ունենք մի իւզերլանդ քիչ։
մարդիկ էսքան ջանք են դրել, ու մի այլ ձեւ գրել են։
էհ։
#մինիքս #իւնիքս #բազմազանութիւն #կենսաբազմազանութիւն #օպերացիոն_համակարգեր #օպերացիոն-համակարգեր #անկապ
ես յիշում եմ շատ հին ու հետաքրքիր թեստ որից պարզ ա որ արդէն քսան տարի առաջ լինուքսի միջուկը գերազանցում էր այլ իւնիքս միջուկները գրեթէ բոլոր թեստերում։ սա բնաւ չեմ գրում լինուքսը գովալու համար։ ուզում եմ ասել, որ լինուքսը յաջողութեամբ կատարում էր խոշոր կորպորացիաների կողմից իր առջեւ դրուած խնդիրները։ եւ այդ խոշոր կորպորացիաներն էլ ներդրում ունեն՝ իրենց պէտք էր եւ իրենք սատարել են զարգացմանը։ սակայն այդ ծանրաբեռնուածութիւնը արժանապատիւ տանելու ունակութիւնը այդքան կարեւոր չի փոքրիկ համայնքային սպասարկիչների պարագայում։ փոքրիկ սպասարկիչները չունեն այդքան օգտուող։ եւ ապա ուզում եմ վերադառնալ ծայրայեղ մինիմալիլմի մասին իմ գրառմանը՝ մեզ պէտք էլ չի կորպորացիաների պահանջներին համապատասխանող չաղացած պինգուինը, կամ այլ ծրագրակազմը։ սերուերների եւ անձնական կարգիչների վրայ մեր խնդիրները լուծւում են եւ աւելի նիհար ու պարզ լուծումներով։ ու ապա նաեւ նախընտրելի են պլերոմայի պէս՝ աւելի թեթեւ, ու գուցէ ոչ շատ ֆիչըրներով համակարգեր, բայց որ ունեն էականը՝ օրինակ ջեմինի երէս։
#լինուքս #իւնիքս #դաշնեզերք #թեստ #օպերացիոն-համակարգեր #օպերացիոն_համակարգեր #ազատութիւն #մինիմալիզմ
վայելում եմ droid4֊ի վրայ մաեմօ֊լեսթէ։
իրականում հասկանում եմ որ մարդկանց մեծ մասի համար կիրառելի չի, ու կիրառելի չի նոյնիսկ սրանից զգալիօրէն աւելի ողորկ սէյլֆիշը, բայց ես պարզւում ա իսկապէս մինիմալիստ եմ, ինձ շատ բան պէտք չի, բայց այ էսպիսի բաներ շատ են պէտք, ու ես դրանցից հրճւում եմ։
ի դէպ, տեսէ՛ք, ես աշխատեցնում եմ 1992֊ի խաղ՝ զի այն կայ դեբիանում (ու ջենթու֊ում էլ) ու սա ինձ համար շատ կարեւոր ա, որ զուր չի մարդու երեսուն տարի առաջ գրածը, որ մենք ազատ ծրագրակազմի աշխարհում կարողանում ենք պատչեր անել եւ մինչ այսօր այդ հին խաղն աշխատեցնել, առանց ճարպի շերտեր մեր համակարգերում աւելացնելու։ (դէ լաւ, սա sdl-1 ա գրած, sdl-2֊ի փորտ չեն արել, բայց ահագին բան փաթչած ա, պատշաճեցրած ա։ (:
իհարկէ, ափսոս որ գոնէ մաքուր c չի, c++ էլ կայ, ու որ էդ ձեւ զարգացանք, բայց դէ լաւ, ինչ արած, զատո փոխարէնը յուսանք մեր ծրագրակազմի զգալի մասը շատ էֆեկտիւ ա աշխատում, հնարաւորինս էֆեկտիւ, երբ չի պայթում։ (:
լաւ արդէն շատ շեղուեցի։
#ծրագրակազմ #էկրանահան #պատմութիւն #դեբեան #դեբիան #մաեմո #մաեմօ #մաեմօ-լեսթէ #մաեմո-լեսթէ #լեսթէ #խաղ #մաելսթրոմ #մինիմալիզմ #դրոիդ #մոտորոլա #օհ #օպերացիոն-համակարգեր #օպերացիոն_համակարգեր #ողորկ #տեք
maemo-leste֊ն հիմա ունի extras շտեմարաններ՝ https://maemo-leste.github.io/maemo-leste-repositories-and-community-packages.html
այնտեղ արդէն կան maemo fremantle֊ից բերած յաւելուածներ http://maedevu.maemo.org/extras/pool/main/
մէկ էլ, maemo-leste֊ն հիմա հասանելի ա նաեւ փայնֆոնի համար։
#մաեմո #մաեմո-լեստէ #փայնֆոն #յաւելուած #հեռախօս #օպերացիոն-համակարգեր #մաեմօ
ուրեմն, ուզում եմ մի քիչ գրել իմ մակօս֊ական փորձից։
որպէս դեւ, ով առաջին անգամ է այս օհ֊ի հետ աշխատում։ իմ հին ծանօթ աւստրալիացին իր մակի վրայ հաշիւ է բացել, որ կպնեմ, վոկ֊ը պորտ անեմ մակի։
նախ սիլանգից՝ ասեմ, որ այս գործիքն առաջին անգամ եմ փորձում, օգտւողի տեսակէտից ահագին յարմար է թւում։ Ոչ միայն տողն է ասում, ուր սխալն է գտել, ինչպէս ջիսիսի֊ն, ոչ միայն տողի որ երորդ նիշն է (միշտ զարմանում էի, ինչո՞ւ ոչ մի սի կոմպիլյատոր դա չի անում), ոչ միայն սիրուն գեղեցիկ պսեւդոգրաֆիկայով ցոյց է տալիս՝ ահա, այստեղ է սխալդ — այ այստեղ սա է պակասում, ասենք, բայց եւ… ակնարկում է թէ ինչ անես, որ սխալները ուղղես։
Միւս կողմից, այդ իր վարքագիծը նոյնիսկ յոգնացնում է։ Ասենք, այս դէպքում, լրիւ անիմաստ է զգուշացնել, ինձ թւում է՝
ասում է՝ «place parentheses around the ‘&&’ expression to silence this warning»։ ինչո՞ւ։ կոմպիլյատորը գիտի, չէ՞, ցանկացած սի֊ի կոմպիլյատորը այդքան պարզ բան գիտի, չէ՞ որն է օպերատորների precedence֊ը։ ուրեմն ո՞ւմ համար է։ գրողի, կամ կարդացողի։ որ գրողը տեսնի իր գրածը, ու իմանայ, որն է precedence֊ը, այնպէս չստացւի, որ կասկած լինի, որ նա չգիտի։
բայց սա արդեն ո՞ւմ համար է։ ակնյայտ անգրագէտի՞։ չգիտեմ, լա՞ւ է դա, թէ չէ։ այն էլ լռելեայն, առանց զգուշացումներն յատուկ միացնելու։
Ասենք այս կոդի մէջ կայ սխալ՝
սիլանգը ասում է՝
ասում է… նու ճիշտ բան է ասում, հա՞։ բայց կարող է ես ուզում եմ սենց բան անել, ինձ պէտք է հենց այսպէս, ինչի՞ պիտի հայհոյի։ նկատի ունեմ, նա ինձ նախապէս դնում է յիմարի տեղ։ ենթադրում է, որ ես չգիտեմ ինչ եմ անում։
չգիտեմ, լաւ է դա թէ վատ։
ջիսիսի֊ում իմ ցանկութեամբ կմիացնէի ասենք, -pedantic, ու կնայէի ինչ է ասում։
հիմա համակարգից։
փաստօրէն, ստատիկ բինար նիշք ստանալ չեմ կարող։ մակօս֊ում չի լինի։ իրենք (էփլը, ֆաշիստները, սրիկաները) չեն տալիս համակարգի գրադարանների ստատիկ տարբերակները՝ .a նիշքերը, ասենք։ Որ դրանց միջի .o նիշքերը լինի ստատիկ միացնել իմ ծրագրին։
երկրորդ շատ հետաքրքիր բանը։ այստեղ ELF չկայ, այստեղ Mach-O բինարնիկներ են։
ու այդ պատճառով էլ .so չկայ, կայ .dynlib.
ldd֊ի փոխարէն էլ otool է
ու վերջապէս այն, ինչը լրիւ անսպասելի էր։
ուրեմն, ես երբ voc֊ը թեստաւորում եմ, անում եմ այսպէս․ ստացա՞յ նոր վարկածը, իրենով իրեն շինում կոմպիլացնում եմ, ու նայում եմ md5 գումարը նոյնը մնա՞ց թէ չէ։
ինձ պէտք է որ նոյնը մնայ, եթէ չէ, ուրեմն ինչ֊որ բան սխալ է, ինքն իրեն վերարտադրել չի կարողանում։ ու սխալը երկար չի թաքնւում, արդեն երկրորդ անգամ, յաջորդ սերնդի վարկածը կամ ինքն իրեն, կամ այլ մոդուլներ կոմպիլյացիա անել չի կարողանում։
այս անգամ, նա ինքն իրեն ստաբիլ ստանում է, լրիւ գրադարանները ստաբիլ կարողանում է շինել, իսկ արի ու տես, որ իր իսկ md5 գումարը հա փոխւում է։
ամէն անգամ կոմպիլյացիայից յետոյ փոխւում է։
ես մտածում էի՝ խնդիր ունեմ։ ես եմ մի բան սխալ արել։
յետոյ մտածեցի, ո՞վ գիտի ի՞նչ է այդ ոչ էլֆ օ֊մախ բայնարին։ մի հատ ․օ֊ները ստուգեմ։
բոլոր գեներացւող ․օ֊ները նոյն էմդիհինգն ունէին։ Դա ինձ հանգստացրեց։ Բայց ամէն անգամ լինքինգից յետոյ ստացւած նիշքի էմդիհինգ գումարը փոխւում էր։ Յետոյ պարզեցի, որ այդ մակի ֆորմատի ձեւն է, ամէն անգամ լինքերը մախ բինարիի մէջ uuid է սարքում խփում։ այն պէտք է իրեն համապատասխանեցնելու համար արտաքին dwarf debugging տւեալները յստակ այս կամ այն նիշքի հետ։
այնպէս որ զգօն եղէք մակի համար գրելիս․ սիլանգը ձեզ կարող է յիմարի տեղ դնել, համակարգը ստատիկ բինար սարքել չի թողնի, իսկ լինքերը ամէն անգամ նոր ձեւի նիշք է արտադրելու նոյն կոդից։
ու տենց
Ով չգիտի, Նոկիայից գնացած կամ հեռացված աշխատողներն են շարունակում իրենց Միգո Մաեմո նախագիծը։
իսկ ես հավանել եմ ինտերֆեյսը, շարժումներով կառավարելը, Ն9֊ից ցրած ու փոխած սվայփը։
Կարեւոր է ինչպես, շարունակելով մաեմոյի ու հարմաթանի ավանդույթները, իրենք միակն են ում մոտ այսպես ասած «մինիմայզ» արած ֆոնում կատարվող ծրագիրը նույնիսկ փոքր թամբնեյլի շարունակում է աշխատել, օրինակ շարունակում է ցույց տալ տեսանյութը։
Ու նույնը սվայփի ժամանակ։
Նաեւ կարեւոր է որ մաեմոյի պես աբստրակցիա են արված կոնտակտները՝ ուզում ես ֆբ֊ով ուղարկի, ուզում ես սմս, հավանաբար նաեւ ուզում ես սքայփով զանգիր, ուզում ես ջաբերով, ուզում ես՝ բջջային կապով։
Դուրս է գալու շուկա տարվա վերջում, արժի 400 եվրո, որը թանկ չէ, իսկ հաջորդ տարվա սկզբին էժան դիվայս աղքատ, կամ այլապես զարգացող երկրների համար։
Հիմա իրենց երեւի օդի պես պետք է փող ու պրեօրդեր են կազմակերպել, որ օգնի արտադրել։
Ինձ անձամբ պետք է իսկական ստեղնաշար, ու ես հուսով եմ իրենք շուտով կհայտնեն, երբ կլինի դրանով սարքը, քանի որ խոսակցություններ ստեղնաշարով սարքի մասին չեն մարում։
ու տենց
computer science -ը վերացարկման (աբստրակցիայի) արվեստ է։ մենք մտածել ենք մոդուլներ, վրոփերներ, կոպմոնենտներ, եւ այլն։
այսինքն մենք ուզում ենք նվազեցնել կրկին գրվող կոդի մասը, ավելի ընդհանորւ ենք սարքում ինտերֆեյսներ, եւ այլն։
դա նաեւ այն է ինչ մեզ սովորեցնում են։
հիմա նայենք ինչ ունենք մոբայլ սարքերի ոլորտում նախագծման դեպքում։
ունենք հայտարարված փորթաբնլ, բայց իրականում մեկ պլատֆորմային կպած դոթնեթ (WP7), ունենք անփորթաբլ C++ Սիմբիանի համար, ունենք հայտարարված կրոսպլատֆորմ ջավա, որի անդրոիդի համար գրված ափը էլ ոչ մի տեղ չի աշխատում․․․
ունենք cocoa էփլի դեպքում։
այսինքն, կամ գրում ես անդրոիդի, կամ այֆոնի, կամ սիմբիանի, կամ վինդովսի համար։ թե ուզում ես պորտ անել, պիտի ահագին ուժ ծախսես։
որը հակագիտական է։
բայց բիզնեսի մոծիվներով է
ի՞նչ կար առաջ․ ունեինք j2me, որը մահացավ թույլ հեռախոսների հետ, բայց որը կարելի է համարել փորթաբլ։
ի՞նչ կունենանք։ Միրիադ ընկերությունը պորտ է անում անդրոիդի դավլիկը (ջվմը) Լինուքսի վրա, այսինքն անդրոիդի ծրագրերը կաշխատեն Միգոյում։ (Միրիադը նախագծել է վինմոբայլի ջ2մեն, յբեդը, Օբերոնով)
կունենանք դոթնեթով գրված ափեր վինդովսի եւ այֆոնի, եւ Միգոյի համար ազատ մոնոյի շնորհիվ։
Կունենանք Լազարուսով գրված սոֆթ դրոիդի, սիմբիանի, այֆոնի, միգոյի, բայց ոչ վինմոբայլի համար, քանզի այնտեղ դոթնեթ ա։
Կունենանք հավանաբար ՔԹ, որը կծածկի սիմբիան, ու Միգո։ Ինչ կստացվի այֆոնի ու անդրոիդի հետ դեռ պարզ չի։
Նենց չի որ շատ գույնզգույն ա, բայց կարծես քիչ քիչ լավանում ա վիճակը։
ու տենց
«Մոդուլային համակարգերի գաղտնիքները» հոդվածի հեղինակն է Սերգեյ Գուբանովը։
«Մոդուլ» եւ «մոդուլյար լեզու» թերմերի բացատրությունների զանազանությունը ծնում է ավներջ վեճեր։ Ինչեր ասես, որ մոդուլ չեն անվանել, ինչ լեզու ասես, որ մոդուլյար չեն համարել։ Ոմանք մոդուլ անվանում են կլասսները, ոմանք ել համեմատում են մոդուլները օբյեկտների հետ։ Առհասարակ այնպիսի տպավորություն է ստեղծվում, որ այժմ մոդուլյար եւ կոմպոնենտային լինելը նորաձեւ ոճ է։ Տարբերակների զանազանության պատճառը բացատրությունների ձեւի մեջ է՝ ներքին ձեւի։ Ներքին է այն իմաստով, որ սահմանումը տրվում է որոշ ներքին հատկությունների հիման վրա (մոդուլը պարունակում է տվյալներ, կոդ, տիպեր, ապահովում է ինկապսուլյացիան, ունի ինտերֆեյս, եւ այլն)։ Մոդուլների ներքին էական հատկությունները առանձնացնելու բազմաթիվ եղանակներ կան, իսկ դա նշանակում է, որ գոյություն ունեն նաեւ մոդուլների սահմանման բազմաթիվ եղանակներ։ Ապագայում ներքին հատկությունների քանակը գուցե եւ ավելանա, հայտնվեն սահմանումների նոր ձեւեր․ այսինքն՝ վիճելու առիթ ավելի շատ կլինի ու դա կտանի փակուղու։ Ելքը ներքին սահմանման փոխարինումն է արտաքինով։
Արտաքին է այն իմաստով, որ սկզբից պետք է նկարագրել ինչ է «մոդուլյար համակարգը», իսկ «մոդուլի» հասկացությունը կհայտնվի ինքնաբերաբար, ավտոմատ կերպով, քանի որ մոդուլը մոդուլյար համակարգի բաղադրիչն է։ Մոդուլյար համակարգը առաջնային է, մոդուլը՝ երկրորդային։ Մոդուլն ինքը իրանով չէ, այլ համակարգի մոդուլ է։ Մոդուլյար լեզու հարկավոր է անվանել այն լեզուն, որը մոդուլյար համակարգեր նախագծելու համար հարմարեցված, օպտիմիզացված է։ Այսպիսով՝ մոդուլյար ծրագրավորման լեզուների իմաստը մոդուլյար համակարգերի նախագծումն է։
Ստորեւ բացահայտենք մոդուլյար համակարգերի իմաստը:
Մոդուլյար ծրագրավորման համակարգերը եկել են միաձույլ ծրագրերը փոխարինելու համար։ Մոդուլյար համակարգեր կիրառելու իմաստը (ի տարբերություն միակուռ ծրագրերի) դինամիկ ընդարձակվելու ունակությունն է։ Մոդուլյար համակարգը կարելի է դինամիկ ընդլայնել մի քանի ձեւով։ Օրինակ՝ դրա մեջ նոր մոդուլներ ավելացնելով կամ փոխարինելով դրա միջի հին մոդուլները նորերով , որոնք ունեն ավելի լայն հնարավորություններ կամ որեւէ այլ լավացումներ։ Ընդարձակվող մոդուլյար համակարգը երբեք ավարտված չէ, այն զարգացում է ապրում։ Որոշ մոդուլներ փոխարինվում են, որոշները դինամիկ ավելացվում։ Այսպիսի համակարգի կյանքը կարող է լինել ավելի երկար, քան նրա միջի կոմպոնենտների կյանքը (տես․ մարդը եւ բջիջները, թարգմանչի նկատողություն)։ Համակարգի օգտագործողը ինքն է որոշում ինչպես այն ընդարձակել։ Կատարյալ դեպքում գոյություն ունի համակարգի կոմպոնենտների շուկա, որտեղ տարբեր արտադրողներ առաջարկում են մոդուլների իրենց իրագործումները, որոնք եւ ձեռք է բերում համակարգի օգտագործողը։ Կոմպոնենտների շուկայի բացակայությունը կարող է խոչընդոտել միաձույլ համակարգերից մոդուլյար համակարգեր անցնելուն։ Սակայն, պահանջարկը ծնում է առաջարկ։
Դիտարկենք մոդուլյար, դինամիկ ընդլայնվող համակարգի կառուցվածքը։ Մոդուլների միջեւ փոխազդեցությունը իրագործվում է մոդուլի՝ այլ մոդուլներ ներմուծելու (import) ունակության շնորհիվ։ Այսպիսով՝ ներմուծող մոդուլը հանդիսանում է ներմուծվող մոդուլների կլիենտ։ Մոդուլների ներմուծման գրաֆը միշտ ացիկլիկ է։ Գրաֆի ացիկլիկ լինելը կապված է այն հանգամանքի հետ, որ մոդուլները հանդիսանում են բեռնման, կատարման եւ բեռնաթափման միավորներ, իսկ ցիկլիկ կախվածության դեպքում բեռնման եւ կատարման միավոր կլիներ ամբողջ ցիկլը․ այսինքն՝ այն ամբողջությամբ կլիներ մոդուլ (համակարգի կոմպոնենտ)։ Մոդուլյար համակարգը ենթադրում է կատարման միջավայր, որի հիմնական խնդիրներից է մոդուլների դինամիկ բեռնումը, ուշ կապը (late linking), կատարումը եւ բեռնաթափումը։ Այլ խնդիրը ամբողջականության կոնտրոլն է․ տիպերի դինամիկ բերումը, զանգվածների (array) ինդեքսների դինամիկ ստուգումը եւ այլն։ Դինամիկ բեռնաթափման հնարավորությունը անհրաժեշտ է հին մոդուլները նորերով փոխարինելու համար։ Ի դեպ մոդուլը չի կարելի բեռնաթափել մինչեւ բեռնաթափված չեն բոլոր նրա կլիենտները։ Դա ակներեւ է թվում, սակայն այդ մասին հաճախ մոռանում են։ Մոդուլների բեռնումը եւ բեռնաթափումը կարելի է համեմատել աղյուսներից աշտարակ հավաքելու հետ․ աշտարակը կարելի է քանդել միմիայն վերեւից, այլ դեպքում այն կփլվի։ Ակներեւ է նաեւ այն, որ մոդուլը կարելի է բեռնաթափել միմիայն հստակ (explicit) հրամանով, այլ ոչ թե ավտոմատ կերպ (օրինակ՝հիմնվելով կլիենտների բացակայության փաստի վրա․ այժմ կլիենտներ չկան, իսկ որոշ ժամանակ անց կլինեն, եւ մոդուլի վիճակը պիտի պահպանվի)։ Նոր մոդուլի ավելացումը կամ հին մոդուլի փոփոխությունը չպետք է բերի ամբողջական համակարգը ավիրելուն։ Քանի որ մոդուլները կարող են մատակարարվել տարբեր արտադրողների կողմից, ապա կատարման միջավայրը պիտի ստուգի մոդուլների համատեղելիությունը եւ խոչընդոտի անհամատեղելի մոդուլների բեռնմանը։ Համատեղելիությունը ստուգվում է մոդուլի ինտերֆեյսի անալիզի միջոցով։ Մոդուլը պարունակում է իր մեջ զանազան ծրագրային էություններ` կոնստանտներ, տիպեր, փոփոխականներ, ֆունկցիաներ։ Մոդուլի որոշ էություններ հասանելի են դառնում կլիենտների համար, այսինքն` արտահանվում են (export), իսկ մնացածները թաքցվում, այլ խոսքերով՝ ինկապսուլյացիա անում։ Ի դեպ այդպիսի ինկապսուլյացիայի ձեւը ամենահզորն է, քանի որ այն խախտելու միակ միջոցը մոդուլի բինար կոդի հետազոտությունը եւ դրա ոչ անվտանգ փոփոխությունն է։ Մոդուլի արտահանվող էությունների ամբողջությունը սահմանում է մոդուլի ինտերֆեյսը։ Դրա միջոցով էլ իրականացվում է կլիենտների հետ փոխազդեցությունը։ Եթե երկու մոդուլ (նույնիսկ տարբեր արտադրողների մոդուլներ) ունեն նույն ինտերֆեյսը, ապա դրանք երկուստեք փոխարինելի են։ Եթե երկու մոդուլներից մեկը ունի առաջինի համեմատ ընդլայնված ինտերֆեյս (այսինքն՝ նրա ինտերֆեյսը ճշգրիտ կրկնում է առաջին մոդուլի ինտերֆեյսը եւ դրան գումարած արտահանում է հավելյալ էություններ), ապա երկրորդ մոդուլը փոխադարձորեն փոխարինելի է առաջինի հետ։
Ինչպե՞ս է կատարման միջավայրը որոշում մոդուլների համատեղելի լինելը։ Ամենապարզ ձեւն է՝ դրոշմել ամեն մոդուլը իր տարբերակի համարով (լինի դա հստակ նշված տարբերակ, թե վերջին կոմպիլյացիայի ժամանակը)։ Հին մոդուլյար համակարգերը օգտագործում էին ժամանակային նշումների մեխանիզմը (timestamps)։ Բայց տարբերակի հստակ (explicit) նշելը գերադասելի է, որովհետեւ ավելի ուշ timestamp-ը հայտնում է միայն այն, որ տվյալ մոդուլը ավելի ուշ է հավաքվել (compiled), բայց չի ակնարկում որ մոդուլի ինտերֆեյսը լուրջ փոփոխությունների է ենթարկվել։ Սակայն մոդուլը որոշակի համարով դրոշմելու լուծումը նույնպես թերի է։ Ենթադրենք, նոր մոդուլը հնից տարբերվում է միայն նրանով, որ նրա մեջ փոխված է ինտերֆեյսի բավականին փոքր մասը։ Օրինակ՝ փոխվել է մի արտահանվող կոնստանտի արժեքը, իսկ մնացած ամենը մնացել է անփոփոխ։ Ապա այդ մոդուլը պետք է դրոշմվի որպես նոր տարբերակ։ Սակայն գոյություն ունեն այնպիսի կլիենտ մոդուլներ, որոնք օգտագործում են միայն ինտերֆեյսի անփոփոխ մնացած մասը։ Նոր դրոշմի պատճառով այդ մոդուլի բոլոր կլիենտ մոդուլները կճանաչվեն անվավեր, այսինքն՝ կատարման միջավայրը կհրաժարվի բեռնել (աշխատեցնել) դրանք փոփոխված մոդուլի հետ համատեղ։ Մոդուլների համատեղելիության ստուգման մեխանիզմը երբեմն անհիմն անգութ է, եւ կատարման միջավայրը կարող է անվավեր համարել բազմաթիվ մոդուլներ։ Բարեբախտաբար, գոյություն ունեն մոդուլների համատեղելիությունը հաստատելու այլ, ավելի գրագետ ձեւեր։ Հավաստիանալու գաղտնիքը նրանում է, որ մոդուլի յուրաքանչյուր արտահանվող (exported) էությանը (յուրաքանչյուր կոնստանտի, փոփոխականի, տիպի, ֆունկցիաի) կցվում է ուրույն նշան, մատնահետք (fingerprint), ավելի պարզ՝ checksum, որը հաշվարկված է այդ էության որոշակի կառուցվածքային ինվարիանտ հատկությունները ի նկատի ունենալով։ Այսպիսի «մանտնահետք» դրոշմեր ստանալը հեշտ խնդիր չէ, առավել եւս ընդարձակվող համակարգերի դեպքում։ Ավելի քան տաս տարի առաջ ETH-ում մատնահետք դրոշմեր հաշվելու թեմայով դոկտորական թեզ է պաշտպանվել (Regis Crelier «Separate Compilation and Module Extension», գիտական ղեկավարներն էին Նիկլաուս Վիրտն (Wirth) ու Հանսպետեր Մոսենբոքը (Mossenbock), Oberon-2 լեզվի համահեղինակները)։ Կատարման միջավայրում մոդուլների համատեղելիության կոնտրոլի բացակայությունը կարող է բերել անկանխատեսելի հետեւանքների։ Այսպես, օրինակ, MS Windows համակարգի կատարման միջավայրը (ըստ էության պարզապես բեռնիչը), որի մեջ dll ֆայլերը հանդիսանում են մոդուլներ, չի ստուգում այդ մոդուլների համատեղելիությունը։ Որպես հետեւանք գոյություն ունի տխրահռչակ dll hell հասկացությունը։
Մոդուլյար համակարգեր ստեղծելը սկզբունքայնորեն հնարավոր է ցանկացած ծրագրավորման լեզվի օգնությամբ։ Օրինակ՝ win32 dll մոդուլյար համակարգը կարող է իրագործվել զանազան լեզուներով։ Սակայն դժվար թե լինի գոնե մեկ լեզու, որը այդ իսկ նպատակին հարմարեցված է նախագծման պահին։ Համեմատենք մեկ dll մոդուլի ստեղծման թեթեւությունը (որը որպես կանոն շատ հեշտ է, քանի որ բոլոր հոգսերը տանում է նախագծման միջավայրը) մի քանի, կամ տասնյակ/հարյուրավոր դինամիկ բեռնվող եւ բեռնաթափվող dll մոդուլներ պարունակող համակարգի ստեղծման բարդության հետ։ LoadLibrary եւ GetProcAddress կանչերի վիթխարի քանակը հարմարավետ չես անվանի եւ դրանք կիրառող տեքնոլոգիան, կամ լեզուն, ոչ մի կերպ չես անվանի մոդուլյար համակարգեր ստեղծելու համար հարմարեցված լեզու։ Ընդ որում ստատիկ կապումը (static linking) ելք համարել չի լինի, որովհետեւ բեռնաթափել եւ փոխարինել ստատիկ կապված մոդուլը անհնար է։ Ինչպես ասված էր, բնական է մոդուլյար ծրագրավորման լեզուները սահմանել որպես մոդուլյար համակարգեր ստեղծելու համար հարմարավետ, հատուկ նախագծված, նախատեսված լեզուներ, դա է իրենց իմաստը։ Բայց ինչպես մենք քիչ առաջ համոզվեցինք, մոդուլյար համակարգերը, առհասարակ, կարելի է կերտել նաեւ այդ համար հատուկ չնախատեսված լեզուների օգնությամբ։ Հարցը միմիայն աշխատանքի ծախսն է։ Կարող է պարադոքսալ թվալ, բայց լինում է եւ հակառակը․ կան ծրագրավորման լեզուներ, որոնք, կարծես, հարմարավետ են ոչ միայն միաձույլ, այլ նաեւ մոդուլյար համակարգեր ստեղծելու համար։ Ես ի նկատի ունեմ Delphi-ն։ Թվում է, որ այնպիսի սինտակտիկ միավորները, ինչպիսին են՝ unit, interface, implementation, uses, մոդուլյար համակարգեր ստեղծելու համար շատ օգտակար են․ մոդուլներ կհանդիսանային յունիթները, ավելի ճիշտ դրանց կոմպիլյացիայի արդյունքը՝ dcu ֆայլերը (delphi compiled unit)։ Բայց, ցավոք, dcu ֆայլերը մոդուլներ չեն, դրանք «կիսաֆաբրիկատներ» են։ Չնայած նրան, որ մոդուլների բոլոր արտաքին սինտակտիկ հատկանիշները առկա են, նրանց անհնար է մոդուլյար համարել․ ներկա ժամանակ աշխարհում գոյություն չունի մոդուլյար համակարգ, որի ստեղծման համար այն հատուկ հարմարեցվի։ Տեսականորեն, եթե երբեւէ ստեղծվի հատուկ կատարման միջավայր, որն ունակ կլինի դինամիկ բեռնել եւ բեռնաթափել dcu ֆայլերը, ապա այնժամ հնարավոր կլինի Delphi-ն անվանել մոդուլյար, այսինքն՝ հատուկ հարմարեցված մոդուլյար ծրագրավորման համար։ Այս տրամաբանությունը կարող է թվալ անսպասելի, բայց այն հետեւում է այս գրառման սկզբում սահմանված մոդուլյար համակարգերի իմաստից։ Մոդուլյարության հատուկ սինտակտիկ հատկանիշները անշուշտ անհրաժեշտ են, սակայն դրանք բավական չեն, այսինքն ոչ մի պարադոքս իրականում չի դիտվում։
Չնայած նրան, որ լեզվի միջի հատուկ շարահյուսական (սինտակտիկ) հատկանիշները բավական չեն լեզուն մոդուլյար անվանելու համար, դրանք միեւնույն է անհրաժեշտ են։ Անհրաժեշտ են նրա համար, որ լեզուն հարմարեցված լինի մոդուլյար համակարգեր գրելու համար։ Մոդուլյար ծրագրավորման լեզվի շարահյուսության մեջ պիտի արտահայտված լինեն ամենաքիչը երեք հասկացություն՝ ինքը մոդուլը, մոդուլների ներմուծմանվ(import) միջոցները եւ ծրագրային էությունների արտահանման (export) միջոցները։ Մոդուլյար համակարգի ամբողջականության վերահսկումը հնարավորինս վաղ իրականացնելու համար անհրաժեշտ է անջատ (separate), այլ ոչ թե անկախ (independent) կոմպիլյացիա։ Ակնհայտ է, որ մոդուլը պիտի լինի կոմպիլյացիայի միավոր։ Այլ դեպքում ինչու՞մ է կայանում հարմարավետությունը։ Մոդուլի ներքին էությունները իրար ամուր կապված են։ Եթե կոմպիլիացիայի միավոր լինի մոդուլից փոքր մեծություն, ապա անջատ կոմպիլիացիան հաշվի առնելով՝ անհրաժեշտ կլինի հնարել որոշակի թաքցրած ինտերֆեյսներ այդ էությունների փոխազդեցությունների համար։ Ակներեւ է, որ դա ավելորդ բարդացում է, գուցե նույնիսկ՝ անվտանգության ճեղք (vulnerability), եւ դրա օգուտը պարզ չէ։
Ընդհանուր առմամբ, մոդուլյար համակարգերի ծրագրավորումը չի պահանջում օբյեկտային կողմնորոշված ծրագրավորման (ՕԿԾ) մոտեցում, իրավացի է եւ հակառակը։ Սակայն, այդ երկու մոտեցումների համաժամյա կիրառությունը բերել է նոր ծրագրավորման պարադիգմայի ստեղծմանը։ Բանն այն է, որ ՕԿԾ-ն, իր ամենատարածված բացատրությամբ, հիմնված է ժառանգողականության (inheritance) հասկացության վրա։ ՕԿԾ-ն եւ մոդուլարությունը միատեղ կիրառելու ընթացքում ծնվում է միջմոդուլյար ժառանգողականությունը, սակայն այն հանդիսանում է տարբեր արտադրողների մոդուլների փոխարինելիության խոչընդոտ։ Եթե տիպի մասը սահմանված է մեկ մոդուլի մեջ, իսկ մյուս մասը՝ այլ, ապա հիմնական տիպի նկարագրությունը պարունակող մոդուլը այլ արտադրողից նույնանման մոդուլով փոխարինելը բավականին մեծ խնդիր է․ իրականացման հնարավոր մանր տարբերությունների պատճառով։ 1995 թվին, պրոֆեսոր Կլեմենս Շիպերսկին (Clemens Szyperski) ֆորմալիզացրել է Կոմպոնենտային Կողմնորոշված Ծրագրավորման (ԿԿԾ) հիմունքները սահմանափակելով եւ ՕԿԾ-ն եւ մոդուլյար մոտեցումը դրանց չհակասող համատեղ գոյության համար («Component-Oriented Programming A Refined Variation on Object-Oriented Programming», The Oberon Tribune, Vol 1, No 2, December 1995)։ ԿԿԾ-ի իմաստը ընդարձակելի համակարգերի կառուցումն է՝ մոդուլների եւ ՕԿԾ-ի օգնությամբ։ Այսպիսով, ԿԿԾ-ն, Շիպերսկու կարծիքով, գտնվում է «<ՕԿԾ-ից դուրս» (Beyond Object Oriented Programming - թարգմանչի նկատողություն) (այսպես է կոչվում նրա արդեն երկու անգամ հրատարակված բեսթսելերը)։ ԿԿԾ-ի հիմքը հանդիսանում են․ պոլիմորֆիզմը, ուշ կապումը (late linking), իսկական ինկապսուլյացիան, կատարման միջավայրի կողմից իրականացվող անվտանգութան ամբողջական վերահսկումը։ Կատարման միջավայրը նաեւ պարտավոր է աղբ հավաքել։ Աղբ հավաքելը շքեղություն չէ բնավ, այլ անհրաժեշտություն․ այն կոմպոնենտային համակարգի ամբողջականության երաշխիքներից մեկն է (հիշենք, որ համակարգի կոմպոնենտները՝ մոդուլները, ստեղծվում են, առհասարակ, տարբեր արտադրողների կողմից)։ Այժմ, ուշադրություն դարձրեք այն հանգամանքին, որ «ժառանգողականության» հասկացությունը (այսինքն տիպի ընդլայնումը), որը այնքան տարածված է ժամանակակից ՕԿԾ լեզուներում, առհասարակ չի ընդգրկված ԿԿԾ-ի հիմքերի մեջ։ Դրա բացատրությունը տրիվիալ է։ Եթե տիպերի ընդլայնումը կիրառվում է մոդուլների մեջ, ապա դա սովորական ՕԿԾ է՝ այնտեղ ուրույն կանոններ են։ Իսկ եթե օգտագործվում է տիպերի միջմոդուլյար ընդլայնումը, ապա այն մոդուլները, որոնց միջեւ տիպերը կապված են ժառանգողականողականության հարաբերություններով, կապված են լինում ավելի պինդ, ավելի կարծր կերպ։ Բարդ է փոխարինել բազային տիպ պարունակող մոդուլը այլ արտադրողի մոդուլով, առանց անվավեր անելու կլիենտ մոդուլները, որտեղ այդ տիպը ընդլայնված է։ ԿԿԾ-ն խորհուրդ է տալիս կիրառել միջմոդուլյար ժառանգողականություն միմիայն աբստրակտ տիպերից՝ դա նպատակահարմար փոխզիջում է ՕԿԾ-ի եւ մոդուլյար համակարգերի միջեւ։ Սակայն ծրագրավորողը, իհարկե, իրավացի է ինքը որոշել, արդյո՞ք արժե կոնկրետ համակարգում օգտագործել տիպերի միջմոդուլյար ժառանգողականությունը առանց սահմանափակումների (դրանով իսկ կարծր կապելով մոդուլները իրար), թե այնուամենայնիվ, նախընտրել փոխարինելի, ընդարձակվող մոդուլներ՝ տարբեր արտադրողներից։ ԿԿԾ-ի սահմաններում, «կոմպոնենտ» բառը դառնում է թերմ։ Կոմպոնենտային համակարգը դա մոդուլյար համակարգի այն մասնավոր դեպքն է, որի մեջ կիրառվում է ՕԿԾ։ Քանի որ այժմ ՕԿԾ-ն օգտագործվում է ամենուր, ապա «մոդուլյար համակարգ» կամ «կոմպոնենտային համակարգ» հասկացությունների տարբերությունը գրեթե բացակայում է։ Մյուս կողմից, կոմպոնենտ բառը այժմ չափազանց ծանրաբեռնված է տարբեր իմաստներով, այդ իսկ պատճառով կարելի է գտնել կոմպոնենտոների այլ բացատրություններ։ Քանի որ այժմ դա «նորաձեւ» է, յուրաքանչյուրը այն բացատրում է իր ձեւով։ Օրինակ՝ Delphi-ում կան ուրույն, այսպես կոչված, «կոմպոնենտներ», որոնք բնավ ոչ մի առնչություն չունեն մոդուլյար համակարգերի հետ։ Այս գրառումը ավարտելով դիտարկենք ինչպիսի կոմպոնենտային համակարգեր կան այսօր։ Microsoft ընկերությունը իրականացրել է կոմպոնենտ համակարգի իր մտապատկերը՝ .Net պլատֆորման եւ այդ պլատֆորմայի համար կանոնիկ՝ C# ծրագրավորման լեզուն։ Անկեղծ ասած, .Net համակարգը առհասարակ չի հանդիսանում դինամիկ ընլայնվող մոդուլյար համակարգ, քանի որ նրա մեջ պարզապես բացակայում է մոդուլներ բեռնաթափելու հնարավորությունը։ .Net համակարգերը ավելի շատ նման են մոնոտոն աճող միաձույլ ծրագրերի, մասնակի, հաջորդաբար կոմպիլյացիայով ու բեռնմամբ ըստ անհրաժեշտության։ Իրականում, այս ամենը ավելի բարդ է, որովհետեւ .Net-ում տարբերություն կա կոմպիլիացիայի միավորի (dll կամ exe մոդուլ) եւ բեռնման միավորի միջեւ (assembly)։ Assembly-ն մի քանի մոդուլի տրամաբանական միացումն է մեկ ենթահամակարգում։ Assembly-ների, dll-ների եւ exe մոդուլների մեջ չխառնվելու և առանց ընդհանրությունը կորցնելու պարզության համար ենթադրենք, որ assembly-ն բաղկացած է մեկ մոդուլից, եւ դրանց մեջ ոչ մի տարբերություն չկա։ Մեկ assembly-ի մեջ մի քանի մոդուլի դեպքը սկզբունքորեն ոչ մի բան չի փոխում (բացի բարդացում ավելացնելուց), այդ պատճառով կխոսենք միայն մոդուլների մասին։ Այսպիսով՝ .Net կատարման միջավայրը մոդուլների համատեղելիության վերահսկման համար չի օգտվում վերը նշված մատնահետքերի (fingerprint) մեխանիզմով։ Դրա փոխարեն կիրառվում է մոդուլի տարբերակի համարը հստակ նշելու տեխնիկան։ Դա, իհարկե, ավելի լավ է, քան ոչինչը (ինչպես win32 dll դեպքում), բայց ստեղծում է իր խնդիրները։ Օրինակ՝ եթե .Net մոդուլը արտահանում է կոնստանտ, որը, միգուցե, ոչ ոք չի օգտագործում, ապա, այդ մոդուլի ինտերֆեյսը, այսինքն՝ կոնստանտի արժեքը փոխելով, պետք է փոխել նաեւ մոդուլի տարբերակի համարը՝ այսպիսով անվավեր հանելով բոլոր կլիենտ մոդուլները, նույնիսկ նրանք, որոնք այդ կոնստանտը չեն օգտագործել։ Սա արդեն «dll hell»-ի ճիշտ հակապատկերն է։ Եթե սովորական win32 dll բեռնիչը բոլոր մոդուլները համարում էր համատեղելի, ապա .Net-ի դեպքում բեռնիչը անհամատեղելի է համարում չափազանց շատ մոդուլներ․ ինտերֆեյսում նույնիսկ չնչին փոփոխություն կատարելիս անհրաժեշտ է փոխել ամբողջ մոդուլի տարբերակի համարը։ C# լեզվի մեջ, որը, թվում է թե իր տրամաբանությամբ պիտի հարմարեցված լիներ մոդուլյար համակարգերի ծրագրավորման համար, բացակայում է մոդուլի հասկացությունը շարահյուսական մակարդակի վրա․ ուրեմն, մոդուլի ներմուծման հասկացությունը նույնպես բացակայում է։ C# լեզվով գրված մոդուլի տեքստը կարդալիս անհնար է իմանալ․ ա) ինչպիսի մոդուլներ է այն ներմուծում։ բ) որ մոդուլի մեջ է սահմանված տեքստում օգտագործված այս կամ այն իդենտիֆիկատորը։ Կիրառվող namespace մեխանիզմը կապված չէ մոդուլների անունների հետ։ C#-ը «հին նմուշի» լեզու է, որը հարմար է միաձույլ ծրագրեր ծրագրավորելու համար, ու հարմարեցված չէ մոդուլյար համակարգեր ստեղծելու համար։ Գուցե արդար չէ այդքան խիստ լինել C#-ի հետ, քանի որ .Net-ը ավելի նման է քայլ առ քայլ աճող միակուռ համակարգի, քան դինամիկ ընդարձակվող մոդուլյար համակարգի։ Մեծ պրոեկտներ հարմարավետ ծրագրավորելու համար առաջարկվում է օգտվել ոչ թե լեզվի հնարավորություններից, այլ նախագծման միջավայրի գործիքներից։ Գոյություն ունեն կոմպոնենտային համակարգեր, ու կոմպոնենտային ծրագրավորման լեզուներ, որոնք գրեթե զուրկ են թերություններից։ Դա կարող է զարմանք առաջացնել, սակայն առաջին մոդուլյար համակարգերը հայտնվել են դեռ անցյալ դարի 70-ականների ավարտին։ Օրինակ՝ դա Lilith համակարգչի համար ստեղծված օպերացիոն համակարգն է, որը գրված է պրոֆեսոր Նիկլաուս Վիրտի (Niklaus Wirth) Modula-2 լեզվով։ Այնուհետեւ, նա ու Յուրգ Գութկնեխտը (Jurg Gutknecht) ստեղծել են Oberon օպերացիոն համակարգը նույն անվանմամբ՝ Oberon լեզվի օգնությամբ, որը արդեն կարելի է համարել կոմպոնենտային, չնայած այդ համակարգը ստեղծելու աշխատանքը սկսվել է դեռ 1985 թվին՝ կոմպոնենտային ծրագրավորման հիմունքները հռչակելուց 10 տարի առաջ։ Մեր օրերում, օրինակ, Windows-ի համար գոյություն ունի անվճար (եւ ազատ արտոնագրով - թարգմանչի նկատողություն) տարածվող, 1994թ ստեղծված շվեյցարական AG Oberon Microsystems, Inc արտադրության BlackBox Component Builder կոմպոնենտային միջավայրը։ Նիկլաուս Վիրտը տնօրենների խորհրդի կազմի մեջ է, իսկ հիմնադիրներից մեկը ԿԿԾ «գաղափարային հայր», պրոֆեսոր Կլեմենս Շիպերսկին է։ Ճիշտ է այժմ նա աշխատում է որպես software architect Microsoft Research-ում։ Ամենասկզբից BlackBox համակարգը անվանվում էր Oberon/F եւ նախագծվում էր Oberon-2 լեզվով MacOS եւ Windows համակարգերի համար։ Այնուհետեւ Oberon-2 լեզուն փոփոխված էր ԿԿԾ նորաձեւ գաղափարի համաձայն։ Նոր լեզուն ստացավ Կոմպոնենտ Պասկալ (Component Pascal) անունը (1997)․ դա Oberon-2-ի արդյունաբերական տարբերակն է։ 2004 թվին BlackBox-ը հայտարարվել է անվճար, (իսկ ծրագրի կոդը՝ ազատ - թարգմանչի նկատողություն)։ Կամավորները ստեղծում են BlackBox-ի տարբերակ Linux (GNU/Linux - թարգմանչի նկատողություն) համակարգի համար (արդեն կա ալֆա տարբերակը)։ Իսկ Oberon Microsystems-ը ներկա ժամանակ աշխատում է համակարգի նոր տարբերակի վրա։ BlackBox-ով ստեղծված է Ամազոն գետի վրա գտնվող աշխարհի ամենամեծ հիդրոէլեկտրոկայանի հսկման համակարգը։ Դրա համար ստեղծվել էր BlackBox-ի հատուկ տարբերակ 64 բիտանի Unix-ի համար։ Borland ընկերության պատվերով Oberon Microsystems ընկերությունը գրել է Java-ի JIT կոմպիլյատոր։ Բացի դրանից, Oberon Microsystems-ում Կոմպոնենտ Պասկալով գրված է Portos իրական ժամանակի օպերացիոն համակարգը (չշփոթել PortOs-ի հետ, որը լրիվ այլ համակարգ է)։ Այնուհետեւ Portos-ը վերանվանվեց JBed, իսկ Oberon Microsystems-ից առանձնացվեց Esmertec ընկերությունը։ JBed-ը ավելի շատ հայտնի է որպես իրական ժամանակի օպերացիոն համակարգ embedded սարքերի համար, որը գրված է java-ով։ Ի նկատի ունենալով Java-ի լայն տարածումը եւ Component Pascal-ի թույլ ճանաչվածությունը՝ պետք է խոստովանել, որ դա հաջող մարկետինգային քայլ է։ Ռուսաստանում վերջերս հայտնվել է ընկերություն, որը հայտարարել է որպես հիմնական արտադրամիջոց BlackBox Component Builder համակարգը օգտագործոլու մասին։ Գոյություն ունի «Ինֆորմատիկա 21» միջազգային պրոեկտ, որի նպատակներից մեկն է BlackBox համակարգի առաջխաղացումը դպրոցներ, բարոյապես հնացած Turbo Pascal-ի փոխարեն։ Եթե փորձել պատասխանել այն հարցին, թե որն է ավելի լավը՝ BlackBox-ը թե Java-ն, ապա պետք է հաշվի առնել, որ բարդությունը թերություն է, իսկ .Net-ն եւ Java-ն անհամեմատ ավելի բարդ են։ Իսկ բացի BlackBox-ից գոյույթուն ունեն մի շարք հետազոտական մոդուլյար համակարգեր։ Ուզում եմ շեշտել Aos BlueBottle օպերացիոն համակարգը (այժմ A2, թարգմանչի նկատողություն) որը անմիջապես «երկաթի» վրա ապրող ակտիվ օբյեկտների հիման վրա ստեղծված առաջին եւ միակ համակարգն է։ Այն ամբողջությամբ գրված է Active Oberon լեզվով։ Համակարգի կատարման միջավայրը իրականացված է անմիջապես «երկաթի» վրա։ Սակայն, դա արդեն այլ պատմություն է։ բնորինակը
ու տենց
Բլոգը ճիշտ օգտագործեմ, որպես վեբ լոգ՝
ու տենց
Ստանդարնտները լավ բան են։ Ինչ որ ստանդարտ պետք ա լինում։ Նույնիսկ ասենք շփման մեջ, միմյանց հասկանալու համար։ Կամ թերմերի մեջ, կրկին՝ հասկանալու համար։
Սակայն, երբ ստեղծում եք նորը ստանդարտին հետևելը, կամ համապատասխանելը հաճախ բերում է վատ որոշումներին, ու վատ դիզայնին։
Ասենք, երբ Ստրաուստրուպը C++ նախագծելուց փորձում էր պահպանել C-ի հետ համատեղելիությունը, դա բերեց ինչպես տգեղ լուծումների, այնպես էլ լեզվի չաղացմանը։
Ուինդոուս/Սոլարիս-ներում – պահպանել նախկին տարբերակների հետ համատեղելիությունը որոշումը բերեց գրադարանների չաղացմանը։
Ի տարբերություն, Վիրտը, նախագծելով Մոդուլան որոշեց չպահպանել պասկալի հետ համատեղելիությունը։ Փոխարենը, նա գրեց քոնվերթեր, պասկալից մոդուլա տրանսլացիա անելու համար։ Նույնպես նա վարվում էր և հետագայում, Մոդուլայից Օբերոն քոնվերթեր գրելով, քանի որ հասկանում էր՝ համատեղելիությունը պահպանելը կբերի տգեղ դիզայնի։
Բաց ԾԱ-ի աշխարհում համատեղելիություն պահպանելը իմաստ չունի։
Փոխվեց գրադարանը՝ փոխվում է ծրագիրը որը այն օգտագործում է։ Եթե ծրագրի հեղինակը հետաքրքրված չէ, դա անում է մեյնթեյները կամ յուրաքանչյուր մեկը ում այդ ծրագիրը պետք է։ Այսպիսով, բաց ԾԱ-ն չունենալով համատեղելիության շերտ՝ ավելի նիհար է։
Ինչպես ես արդեն գրել եմ, կարգինը՝ արտակարգ լինել չի կարող։
Այս պատճառով Պլան9-ը և Ինֆերնոն, որոնց դիզայնի մեջ, ի դեպ, անկերես է Օբերոնի ազդեցությունը, չեին կարող հետևել սովորական Յունիքս/Պոսիքս ստանդարտների։
Ու պարզ է որ նրանք լայն չեն կիրառվում այն պատճառով, որ ծրագրերի մեծ մասը գրված է տեքնոլոգիաներով, որոնք անհամատեղելի են Ինֆերնոի հետ։ Օրինակ, C-ով կոդ այնտեղ ափլիքեյշն լեվել չի օգտագործվում, դրա համար կա Լիմբո։
Սակայն, նոր դիզայն կարող է իրեն թույլ տալ կորմորացիա որը նախագծում է ու տարածում նոր համակարգ։
Ես Անդրոիդ-ի մասին եմ։
Գուգլը լինուքս միջուկի հիման վրա ստեղծել է «նոր» համակարգ, ձեռք է բերել նոր ջավա վիրտուալ մեքենա։
Դրայվերների խնդիր մոբայլ սարքերի համար չկա՝ միևնույն է լիքը նոր դրայվեր գրվել է։
Լինուքսից օգտագործվել է սքեդուլերը, թիսիփի սթեքը, և այլն։ Սի-ով ափլիքեյշն կոդ գրելն նախատեսված չեր։
Այսինքն, կարելի էր անել համակարգ, որտեղ կան դիզայնի նոր ընտրություններ, ինչպես ընդհանուր հասցեական տարածությունը։ Բայց էդպիսի բան արված չէ։ Ընդ որում Լինուքս միջուկի քաստոմիզացիայի վրա այնքան ռեսուրս է ծախսվել, որ այդ ուժերը անհրաժեշտ էր ծախսել Ինֆերնոն փրոդաքշն և մոբայլ սարքեր բերելով։
Որովհետև նոր է, արագագործ, ու գեղեցիկ։
ու տենց
– ես ուինդոս եմ ուզում
– ինչի քոնը էդ չի՞՞
– իմը վիստա ա
– ․․․
․․․
․․․
ի նկատի ունես՝ իքսփի ես ուզու՞մ
_ու տենց_http://lkml.org/lkml/2007/6/12/232
http://blogs.sun.com/jonathan/entry/one_plus_one_is_fifty