Terminal linux

Здравейте , имам желание да направя под linux терминален сървър от който да се достъпва програма която трябва да печата на принтер. Всичко е окей но проблема е че трябва да по време на терминалната сесия да се обръща към локалния принтер на клиента. Има статия за ssh и пренасочване на портове в [линк] интересува некой ако е правил подобно нещо да даде некой съвет или да ме насочи към някаква документация.

mislia /ne sam go pravil/ che s CUPS i malko scripting ste stane , prosto si go digas dinamichno printera spored zelanieto ti / e razbira se clienta triabva da e exportnal printera predi tova/

[линк]

DrFrancky

Ето прекрасен пример колко е трудно използването на отдалечени ресурси в Линукс :)

trudno e zastoto koncepciata na linux e da se polzvat malki tools kombinirani da svursat goliamata rabota .. problema e che tezi tools se pishat ot idin boluk hora koito imat razlichni idei .. da ne govorim che saglasuvaneto mezdu otdenlite ekipi razrabotvasti tezi tools e ravno na 0

DrFrancky

Именно. Движението за отворения софтуер върши добра работа когато трябва да се реализира вече съществуваща архитектура. Но да се измисли нещо ново принципно различно и по-добро, изобщо не ги търси.

Затова все още използваме концепции на 30 години позакърпени тук-там да изглеждат нови.

За съжаление Майкрософт също не са много добри в измислянето на нови неща. Не ми е ясно защо, предполагам че има бизнес причини.

колкото по-бавно влиза новото, толкова повече парички се правят от старото. Естествено има баланс между новото и старото за да се доят максимално клиентите. Не че одобрявам тази практика, но това е същността на капитализма, какво да правим...

USER ERROR: replace user and press any key to continue.

толкова малко хора използват / реализират като отворен код по-напредничавите системи, например Plan 9?

Въпросът ми е съвсем сериозен - защо хората толкова държат на старото и познатото и се страхуват да опитат новото? Инерция, предпазливост, новото не е чак толкова нужно или не си струва усилията, не виждаме достатъчно надалеч?

Или просто е по-добре рисковете да се поемат постепенно? Когато е сигурно, че достатъчно хора са склонни да рискуват с новото?

Хмм, много философски въпроси :) Предполагам, че всички отговори са верни за различни типове хора. Бизнеса не би приел ново решение от предпазливост, домашният потребител поради липса на време и/или знания няма време да се занимава с експерименти и иска да си свърши работата (обикновено несвързана с писане на експериментален софтуер :). Остават хората в университетите и лабораториите, но пък и те трябва да следват модите, ако искат статиите им да се приемат на конференции и списания.

Отделно системите с малък брой последователи в един момент се израждат, фанатизират се и голяма част от членовете им с поведението си отблъскват влизането на нови хора и идеи. Лошото е, че такова поведение прави преноса на идеи от съответната система, към други по-популярни и динамични също трудно.

Конкретно за Plan9 обяснението е просто -- прагът за започване на използването е невероятно висок. Няма браузър, графичната среда е минимална, шела е непознат, липсват много стандартни Юникс команди (например няма find), на практика единственият език за програмиране е C (не съвсем спазващо стандартите), има портове на Perl и Python, но не идват стандартно инсталирани и вероятно 99.9% от инсталациите ги нямат. След инсталацията на Plan9 програмиста се оказва без браузър, в непозната графична среда, с непознат шел, много добра документация, много добър, но съвсем различен текстов редактор и съвсем различен начин за правене на повечето неща. Изведнъж се оказва, че стрелките нагоре и надолу не показват предните команди, Tab не допълва имената на файловете, ^C не спира изпълнението на командите, vi е линкър за MIPS процесори, а не текстов редактор, няма emacs, няма find и т.н. Няма библиотека еквивалентна на gtk или qt. Колко време би издържал ти в такава среда? :)

аз съм дърто магаре (макар че и магарето, казват, върви според тоягата )

Предполага се, че нещата са различни за по-добро. А щом е така, защо в университетите не се учи Plan9, а Unix? Младите момци ще оценят много лесно предимствата, а значи ще има и кой да напише порт за qt. После вече е по-лесно ...

Ами за да преподаваш нещо, трябва да го познаваш. А преподавателите обикновено и те са дърти магарета :)

А порта за qt не е никак лесен -- първо някой трябва да напише C++ компилатор ;)

Всъщност май има порт на Tk за С.

достатъчно пари в преподаването, аз с удоволствие бих отделял част от времето си за него. Съответно, бих учил и опитвал какво и как се прави с най-различни технологии.

Предполагам, при теб преподавателите не са от най-бедните, така че има и способни и ентусиазирани ...

Мярнах по разни листи, че си се занимавал с порт на gcc. Значи си по-наясно от мен трудно ли е да се направи порт за Plan9?

> Предполагам, при теб преподавателите не са от най-бедните, така че има и способни и
> ентусиазирани ...

Не съм много запознат, но мисля, че и тук преподавателите не са много добре платени.

> Мярнах по разни листи, че си се занимавал с порт на gcc. Значи си по-наясно от мен
> трудно ли е да се направи порт за Plan9?

Доста е трудно. Проблемът е, че както всичко други, и стандартния toolchain в Plan9 е много по-различен от тези в Linux и Windows. За разлика от Юникс, обектния файл не е колекция от машинен код и таблици от символи, а бинарно представяне на асемблерен код. Идеята е, че линкера, имайки кода на всички файлове може да направи по-добри оптимизации при генерирането на машинния код, отколкото компилатора, който работи на един файл. Поради тази причина е много трудно да се направи GNU binutils да генерира обектните файлове на Plan9. От друга страна е сравнително трудно да се направи gcc да използва Plan9-ския асемблер (който също е доста различен, и по-опростен, от Юникските асемблери). Забравих да спомена, че C calling convention-a в Plan9 е различен от останалите :) За разлика от Юникс и Windows, правилото в Plan9 e, че функциите трябва да запазят регистрите, които ги интересуват (caller saves). Изобщо не е лесно да се накара gcc да работи в такъв режим, и да поддържа неща като alloca и масиви с променлив размер в стека.

Всъщност аз успях да подкарам C frontend-a на gcc, но нещо се оплетох в реализацията на exception handling в C++, изоставих го за известно време и повече не се върнах да го довършвам.

Има и друг подход за портването на gcc. Всъщност порт на gcc-3.0 има отдавна (направен от David Hogan), но той използва gnu binutils с техните си обектни файлове. Това води до голямо объркване кой изпълним файл с кои библиотеки трябва да се свърже, с кой дебъгер да се дебъгва и т.н. От известно време мисля по въпроса за дистрибуция на Plan9 използваща само gcc (което също си е доста работа, защото C диалекта в Plan9 има някои разширения, които стандартното C ги няма). Някой ден като ми омръзнат нещата с които се занимавам в момента може да се позабавлявам с това (и да си спечеля анатема от die-hard Plan9 последователите :)

Как беше ... no good deed goes unpunished Принципно правилния подход на създателите на Plan9 е наказан с масовото разпространение на значително по-незрелите технологии в Unix/Windows света

Почвам да се чудя дали все пак да не благодаря на Microsoft (усещам, че и над мен зависва възможност за анатема ) за наблягането им в посока .Net, където (съдейки по познанията си за Java) двоичните файлове повече приличат на описаните от теб обектни файлове в Plan9.

Ей, много ме хваща яд понякога на нетехнологичните причини да се забавя и дори отхвърля определено развитие на технологиите. Примерно, идеята компилатора и линкера да са максимално независими повече вреди, отколкото помага. Очевидно е, че зависимост има от гледна точка на цялата програма - да кажем наличието на определен символ, което е достатъчно линкера да се почувства щастлив, далеч не гарантира, че символът е от правилен от гледната точка на програмиста тип. И защо е така след толкова много години съществуване на C? Ами просто - понеже твърде много програмисти са свикнали така

Ето още пример за тезата ти, че само могъщи организации могат да направят нещо смислено на фундаментално ниво, просто защото всички ще се съобразят с тях (отделно от наличието на ресурси в тяхно разположение).

Мисля си, все пак, че е по-полезно да се научи gcc на различните от Unix toolchain-ве, обектни формати и calling конвенции, отколкото да се подкара Plan9 като просто още един Unix. Сигурно е трудно, но все пак не се налага да се препише целия код генератор, а само някои негови части, ако разбирам правилно ... Е, без съмнение, и ld ще претърпи сериозни модификации.

Разбира се, ако това е твърде трудно, има и друг вариант - на практика това, което правиш в момента - да интегрираш интересното от Plan9 в Linux.

Точно така ще стане. Интересното от Plan9 ще влезе в Linux, BSD и т.н., както явно е ставало.
По-големият проблем е, че още дълго време ще се пазят архаизми заради съвместимостта, което винаги е водило до тромавост.

"It's called 'reading'. It's how people install new software into their brains."

nesto ne mi se vruzva ...
sestam se za edna podobno firma .. i te taka .. zemat hubavoto /plastat si go pri tova/ no gi narekoha kradci
kak taka tez sega ne sa kradci ?

btw
spored men e po dobre da si nai-dobur v 1 max 2 nesta otkolkoto nai-skapan v 100-200

DrFrancky

Проблемът е, че за да влезе интересното, трябва да се сменят много отдавна установени неща (във VFS например). Ако знаеш какви бози трябва да се добавят във v9fs за да се приспособи 9P към VFS. Чак съжалявам горките програмисти дето ще трябва да го пишат (дано да не съм аз :).

А иначе от Al Viro вече няколко години очакваме да добави възможност за едновременно монтиране на няколко файлови системи на едно и също място (union mount). Очевидно заради архаизмите това изобщо не е просто.

От нещата, които си разказвал във форума, оставам с впечатлението, че Linux може по естествен начин да се доразвие до платформа, съдържаща голяма част от новите и добри идеи на по-съвременните като концепция ОС като Plan9.

Наистина, архаизмите пречат, дума да няма. Но понеже новите идеи са развитие на старите, май няма принципен проблем да се направи, като се запази обратната съвместимост?

Даже, теоретично поне, двоичния формат на обектните файлове не би следвало да е нерешим проблем, имайки предвид, че GCC е де-факто стандарт и няма особена нужда от десетки инструменти за създаване и манипулиране на обектни файлове (а съществуващите, включително gdb могат да се развият).

Като се замисля, подобно смело решение за замяната на ELF със съответния формат на Plan9 (а защо не и по-добър) спокойно може да послужи за оповестяване на ядро 3.0

Обектния формат на Plan9 е дребна подробност.

Наистина важната новост, която трябва да се прехвърли в Линукс е представянето на _всички_ ресурси като файлове, и манипулирането им чрез архитектурно-независим протокол. Почти всички останали предимства и решения в Plan9 са логично следствие на този основен принцип.

И, естествено, забравих да го спомена

Ми щом е ключово, да викаме ключаря, в краен случай свети Петър и да го правим

От доста време ми е интересно като как точно са успели момците да постигнат тази абстракция, но нищо не съм направил за изясняването й В *nix е ясно - можем да пишем/четем в блокови/символни файлове; на някои устройства се съпоставят специални файлове и готово.

Явно това не е достатъчна абстракция, затова, моля, ако не е много трудно и няма да ти отнеме много време, би ли могъл с няколко изречения да посочиш основния принцип, или да дадеш линк към сравнително кратко въведние?

Също така, интересно ми е как се адресират ресурсите на другите машини в мрежата по прозрачен начин и как се гарантира идентичността на потребителите.

Знам, че мога да намеря всичко това в google, но ако ти е лесно да ми посочиш подходящи ресурси ...

Единствената "статия" на български е това, което бях публикувал тук преди 3 години: [линк]

По-нова статия, описваща примерни Plan9 файлови сървъри (т.е. как различни ресурси се представят като файлове):[линк]

И разбира се, всички статии от [линк]