на 19.06.2019 г. в 6:38, Ивайло Димов написа:

Ха ха хахахаххаха ..............радо би счупил всичко ........имам арч на лаптопа и на настолната машина .........па още нищо не се е счупило 

Аз от една година и малко повече съм с "Манджаро" и си е здрав.  На Радо май това му е хобита - да чупи инсталации

преди 13 минути, Иванчов написа:

fuseblk не може ли до означава и NTFS? 

Може да се види в gparted или с командата

lsblk -no name,fstype

https://unix.stackexchange.com/questions/332712/how-do-i-find-out-what-filesystem-fuse-is-using

преди 34 минути, Иванчов написа:

fuseblk

А какво е това чудо?

преди 31 минути, jojopara написа:

Аз от една година и малко повече съм с "Манджаро" и си е здрав.  На Радо май това му е хобита - да чупи инсталации

И да мяука редовно за нещо,сега мяука за KDE

преди 2 минути, petie1 написа:

А какво е това чудо?

blk-то е май block devices

а фузето сега ходих да го вида ей тук:

https://en.m.wikipedia.org/wiki/Filesystem_in_Userspace

преди 4 минути, Иванчов написа:

blk-то е май block devices

а фузето сега ходих да го вида ей тук:

https://en.m.wikipedia.org/wiki/Filesystem_in_Userspace

И аз такава файлова система не бях чувал fuseblk та затва се учидих

blksize=4096 обединено с ro-то, ги навързах... най-вероятно невярно.

А бързото стартиране е изключено, правилно, веднъж завинаги и вовеки веков.

В краен случай - търсене за forcefsck или ntfsfix би помогнало, предполагам само.

преди 21 часа, petie1 написа:

@malosi я дай и df -h да видим кое как монтирано

 

Подчертаното е дялът.

/dev/sdb2   Linux                      /dev/sdb4  windows 

 

И ново 20 !!!?  Вече може !!!   Но не се именува както преди  DATA 

 

Редактирано 24 юни 20196 г. от malosi (преглед на промените)

преди 2 часа, malosi написа:

 

Подчертаното е дялът.

/dev/sdb2   Linux                      /dev/sdb4  windows 

 

И ново 20 !!!?  Вече може !!!   Но не се именува както преди  DATA 

 

Ей тия дългите /mnt/FE нещо си те иинтересува предполагам си го създава сама и си го монтира с нейни права

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

На единия диск ми е уиндоуса. На другия направих 2 дяла- единия 100 мб, другия всичкото останало до терабайт. Преди си спомням, че имах проблеми (вече забравих какви точно) като се опитах да отделя целия диск за линукса. И двата ги форматирам в нтфс. Слагам флашката с минта и бутвам. Като стигна до дяловете на дисковете указвам, че искам там да се сложи минта, да се форматира в екст 4, и да е с / - е те тоя знак. Толкоз. Повече нищо не пипам. Когато пусна компютъра ми тръгва минта, но имам 9 секунди да избера уиндоус- време предостатъчно.

Имам и един въпрос. Когато съм в уиндоус и реша да мина в линукс рестартирам компютъра. Като започне да зарежда линукса всички вентилаторите (или поне този на процесора, че най шумен и се чува най силно) започват да работят на 100% и не спират. Така може да работят часове. Ако обаче изключа компютъра и после го включа всичко е наред. Не че е голям проблем, но може ли да има по лесно решение от изключване и включване.

на 27.06.2019 г. в 21:58, Димитър Маневски написа:

Имам и един въпрос. Когато съм в уиндоус и реша да мина в линукс рестартирам компютъра. Като започне да зарежда линукса всички вентилаторите (или поне този на процесора, че най шумен и се чува най силно) започват да работят на 100% и не спират. Така може да работят часове. Ако обаче изключа компютъра и после го включа всичко е наред. Не че е голям проблем, но може ли да има по лесно решение от изключване и включване.

Не е нормално да прави така. Най-вероятно видео-картата ти бръмчи. Забелязъл съм, че откакто направиха феноменалната глупост, да прехвърлят X.Org в Userspace-а термалния мениджмънт не се активира всеки път. Ако не се активира, картата може да включи вентилаторите на Max или да почне да прави други мизерии.

Ако видиш, че става така, опитай да рестартираш още един път. Засега не съм намерил просто решение на проблема.

Възможно е и да е друго, но определено термалния мениджмънт не е сработил като хората при зареждане....

Никой не може да ти каже или гарантира какво прави Лайняндос при рестартиране и изключване и дали то е едно и също. Затова си изключваш компютъра (тук пак има някакви шитни като фаст буут или подобни глупости на М$) и си пускаш Линукс-а.

как да подкарам X11Forwarding на dropbear? версията е последната: 2019.78:

https://matt.ucc.asn.au/dropbear/dropbear.html

Features

• A small memory footprint suitable for memory-constrained environments – Dropbear can compile to a 110kB statically linked binary with uClibc on x86 (only minimal options selected)
• Dropbear server implements X11 forwarding, and authentication-agent forwarding for OpenSSH clients
• Can run from inetd or standalone
• Compatible with OpenSSH ~/.ssh/authorized_keys public key authentication
• The server, client, keygen, and key converter can be compiled into a single binary (like busybox)
• Features can easily be disabled when compiling to save space
• Multi-hop mode uses SSH TCP forwarding to tunnel through multiple SSH hosts in a single command.

причината да го предпочета пред openssh е, че линкса, който съм инсталирал на няколко доста стари компютри е лубунту 12.04 (ползвах teamviewer, обаче изведнаж ми се резна достъпа, с грешка че трябвало да разреша конекциите от сървъра, предполагам че е защото е версия 12 - последната работеща на убунту 12.04 и за това искам нещо дето не зависи от 3-rd party programs и външни сървъри), а там openssh е стара версия и не поддържа ecdsa криптация, която е по сигурна... dropbear обаче я поддържа, не зависи от едн куп библиотеки и без проблем се компилира, за разлика от openssh...

четох че трябва да се добави нещо в DROPBEAR_EXTRA_ARGS=

но като добавя X11Forwarding yes и сервиза вади грешка че няма такъв аргумент:

/etc/default/dropbear: X11Forwarding: not found

преди 42 минути, the professor написа:

как да подкарам X11Forwarding на dropbear? версията е последната: 2019.78:

Виж това да не ти разваля играта:

https://git.archlinux.org/svntogit/community.git/tree/trunk/localoptions.h?h=packages/dropbear

localoptions.h
.......................
/*
 * Arch Linux configuration for DropBear
........................
/* Disable X11 forwarding on the server */
#define DROPBEAR_X11FWD 0

Явно и Arch Linux са го изключили.

преди 1 час, the professor написа:

как да подкарам X11Forwarding на dropbear? версията е последната: 2019.78:

https://matt.ucc.asn.au/dropbear/dropbear.html

 

Че това не е въпрос за начинаещи, за да е в тази тема.
По подразбиране имаш пуснат x11 forwarding във версия 2019.78 и не необходимо нищо да до-конфигурираш.
Разгледай default_options.h за всички стойности по подразбиране, а на тези, които не ти харесват им правиш override през localoptions.h

#define DROPBEAR_X11FWD 0

аз си мислех че като има # значи е коментирано и не се ползва (не съм програмист, това че мога да го компилирам, не значи че знам какво прави кода и как работи...) ... но ще го компилирам наново като

#define DROPBEAR_X11FWD 1

ще го пробвам.

10x за съветите

преди 1 час, the professor написа:

аз си мислех че като има # значи е коментирано и не се ползва

Даже не съм видял шибанг-а отпред.  

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

преди 1 час, the professor написа:

#define DROPBEAR_X11FWD 1

Недей, трябва да е:

преди 1 час, the professor написа:

define DROPBEAR_X11FWD 1

Иначе пак ще е изключено. Разбира се, виж какво е написал @Тамболианеца за default_options.h . Може би там е по-правилно да го активираш.  

Объркал съм се, но не мога да редактирам стария пост.

Последно трябва да е:

преди 16 часа, the professor написа:

#define DROPBEAR_X11FWD 1

Защото е C сорс код.

Някой може ли да каже как да реша следния проблем с прехвърлянето на файлове при Убунту (GNOME среда):

когато прехвърлям голям файл, например филм, на флашка, индикаторът за оставащо време не показва правилно оставащото време. В началото тръгва добре и като стигне някъде към 99%, застива. Реално и тогава прехвърля, но не индикира това по никакъв начин.  Ако файловете са по-малки, нямам проблеми. Само с големите файлове се получава.

Проблемът е стар, из гугъл пише, че първо файловете се прехвърляли в буфер в РАМ паметта, а след това на физическия носител. В такъв случай Убунту показва скоростта на прехвърляне и оставащото време на копиране в РАМ-а, а когато дойде време файлът да се запише на флашката, се насмита и не показва нищо, освен че е на 99% готов

на 20.07.2019 г. в 9:59, tremal написа:

Проблемът е стар, из гугъл пише, че първо файловете се прехвърляли в буфер в РАМ паметта, а след това на физическия носител. В такъв случай Убунту показва скоростта на прехвърляне и оставащото време на копиране в РАМ-а, а когато дойде време файлът да се запише на флашката, се насмита и не показва нищо, освен че е на 99% готов

Да, така е. Мернах някъде, че можеш да промениш някакви параметри за този кеш и да го намалиш. Като изключим това не съм виждал друго решение. Явно няма как средата да получи адекватен статус на прехвърлянето от ядрото.

Много пъти съм търсил инфо за намаляването на кеша - не намирам такова.

А не мога да си обясня този проблем - има го само под GNOME 3

Nautilus има настройки в dconf - провери какво има там като опции.

 

Изпратено от моят Mi A2 с помощта на Tapatalk

 

 

 

 

Нищо

Или поне аз не намирам

преди 2 часа, tremal написа:

Много пъти съм търсил инфо за намаляването на кеша - не намирам такова.

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

Затова сега се разрових по-подробно да видя какви са възможностите. За съжаление проблемът няма смислено решение на този етап. 🙁 

Може да се опита с промяна на някои параметри, но като цяло ядрото е оптимизирано с логика за вътрешни дискове, като дори третира всички дискове по един и същи начин за цалата машина или контейнер. В мрежата е писано за следните параметри, но с тях не се постига желаната задача.

hdparm -W 0 /dev/sda

# echo "40" > /proc/sys/vm/pagecache

vm.vfs_cache_pressure

memory.limit_in_bytes

Естествено, навсякъде се проповядва, че това поведение е „оптимизирано“ и всъщност точно то е правилното.

https://www.linuxatemyram.com/

https://unix.stackexchange.com/questions/210950/content-cached-in-ram-while-writing-to-disk-linux

https://unix.stackexchange.com/questions/253816/restrict-size-of-buffer-cache-in-linux

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/tuning_and_optimizing_red_hat_enterprise_linux_for_oracle_9i_and_10g_databases/sect-oracle_9i_and_10g_tuning_guide-memory_usage_and_page_cache-tuning_the_page_cache

преди 3 часа, tremal написа:

А не мога да си обясня този проблем - има го само под GNOME 3

Всъщност поведението е идентично във всички среди и даже в конзолата. Не знам защо мислиш, че е само в GNOME. Не съм пробвал специално под KDE, но се обзалагам че ще е същото.