Не че нещо но защо не пробваш с нещо по-леко за начало - ubuntu вместо fedora.. от опит - това е най-user friendly дистрибуцията с която съм работил

Хора, това не може да е толкова сложно колкото се опитвате да го направите

При инсталация правиш следното:
1. Линукса ти трябва да е primary partition, а не extended (виж с някое livecd и gparted си го настрой)
2. Grub-a го инсталираш в MBR а не в първия партишън

има и по-сложно описание тук: https://help.ubuntu.com/community/Installation/FromCForUSBStick

аа и виж UEFI-то да ти е изключено в БИОС-а: http://www.kaldata.com/forums/topic/207239-%D0%B8%D0%BD%D1%81%D1%82%D0%B0%D0%BB%D0%B8%D1%80%D0%B0%D0%BD%D0%B5-%D0%BD%D0%B0-linux-%D0%B8-uefi-secure-boot/

Здравей, за какъв ти е да стартираш неща от /sbin като user?

Иначе тук има интересна тема точно за дебиан: http://debian.2.n7.nabble.com/Change-default-PATH-for-Jessie-wheezy-1-td1031967.html

пс: Освен в /etc/profile виж и в ~/.bash_profile

Поздрави и успех.
Николай

http://www.linuxforums.org/articles/howto-recover-root-password_54.html
- тука има описано...

Моята конфигурация:

http://www.alsa-project.org/db/?f=c8a7f6c04726d11873b9ac0384a83b498197f138

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

pulseaudio -vvv

дава следния изход:
I: module-alsa-sink.c: Underrun!
I: module-alsa-sink.c: Underrun!
I: module-suspend-on-idle.c: Source alsa_input.pci_10de_55c_sound_card_0_alsa_capture_0 idle for too long, suspending ...
I: module-alsa-source.c: Device suspended...
I: module-alsa-sink.c: Underrun!
I: module-alsa-sink.c: Underrun!
... и това Underrun! се повтаря доста често.


Също като правя тестове със звуци от всякъде (audacious, Ubuntu -> System -> Preferences -> Sound) и излизат така.

В старата версия на убунту, 8.10 работеше нормално.

Пичове, какво да правя по-нататък за да го оправя това - mp3-ките да си работят нормално???

smplayer рулира

под убунту:
1 ред инсталация, няколко цъка и имаш субтитри на кирилица, още 1 ред и имаш кодеците...

Имам следното питане: Имам кирилица, в неизвестно какъв енкодинг и трябва да я доведа до UTF-8 - да се четат нормално там нещата.

Четох че ставало с iconv, обаче как да разбера това:

# Ñòðóêòóðà íà òàáëèöà `address_book`

-----

voyager@voyager-desktop:~/bin$ hexdump test.txt
0000000 2023 91c3 b2c3 b0c3 b3c3 aac3 b2c3 b3c3
0000010 b0c3 a0c3 c320 c3ad 20a0 b2c3 a0c3 a1c3
0000020 abc3 a8c3 b6c3 a0c3 6020 6461 7264 7365
0000030 5f73 6f62 6b6f 0060                   
0000037
--------

(края на текста е "на таблица" )

какъв енкодинг е, и ще мине ли само с един iconv да се преведат думите в UTF-8 формат? Тва windows-1251 е ебаси шита (не е 1251 - пробвах iconv -f windows-1251 -t utf8 ... - не пробаца

---------------------
намерих решение

Привет,

На web server има страници с кодировка cp1251 - като ги сваля през ftp и ги отворя със geany или друг редактор и кирилицата става на маймуница. (През браузър се вижда нормално страницата). Сменям енкодинга - никакъв резултат (маймуните си остават същите). Сменям editor-а и енкодинг-а - същата бира. При запис ми гърми с грешка: "An error occurred while converting the file from UTF-8 in "WINDOWS-1251". The file remains unsaved." а в началото ми пише че показва в ISO-8859-1 кодировка (въобще това по всички дефиниции си е бъг от страна на програмистите писали системна библиотека която се ползва от тия едитори, въпроса е че сега нямам време да се боря с бъгове - просто искам да си свърша работата.)

Дистрото е стандартно Убунту, всичко си е правилно конфигурирано (очевидно щом пиша и чета кирилица нормално във всички останали случай). Идеята ми е:

1) Защо това не работи?
2) Как да го преодолея тоя проблем?

Предстои ми скоро време и преработване на една база данни cp1251 -> utf8 (тъй като въобще не съм фен на cp1251). Въпроса ми е - някой от вас правил ли го е това, и как става най-бързо и лесно?

Поздрави,
Николай Георгиев

----
FYI: Оказа се че това е някакъв бъг действително някъде по веригата, оправих се с проблема като набих default encoding cp1251 при отваряне на файловете.

ето ти примерен скрипт които проверява за точно това в продължение на 24 часа:

Код:

#!/bin/bash
$IP = "1.1.1.1"

for $i in `seq 1440`
   do
       date +%H:%M
       ping $IP -c 1|grep bytes
       sleep 60
   done

- това ти праща един ICMP пакет в минута до дадено ИП в продължение на 24 часа. Предполагам че не ти трябва точната секунда на включване... На изхода виждаш timestamp и ако другата машина е включена, нещо от сорта на:
13:54
64 bytes from 1.1.1.1: icmp_seq=1 ttl=255 time=1.50 ms
(и това ще го виждаш докато е включена, спре ли да е включен отсрещния комп това 64 bytes ... изчезва, остават само timestamp-ове)

Това решение прави само 1440*64*2 или 184,320 байта (грубо 200 килобайта).

Само да допълня нещо за по-екзотичните wlan chipset-и...

има ndis wrapper за картите за които няма драйвери/линукс драйвера не работи както се очаква. За повече инфо - http://en.wikipedia.org/wiki/Ndiswrapper

sharkydog, ping ако отсреща работи обикновен user...

Като получиш icmp reply и знаеш че компютъра е активен, +-овете са че решението е тривиално да си го направиш, дори с малко повече фантазия можеш и лог файл да направиш. - - ако отсреща има някой "хакер" които си следи трафика... (и по-точно - аномалиите в трафика, получаването на icmp пакети от някъде откъдето по принцип не трябва да получаваме лично аз го считам за "аномалия заслужаваща внимание")

Другото което можеш да направиш е със netcat (nc) да слушаш за трафик, като видиш че от МАC-а на компютъра които те интересува почват да фърчат ARP пакети от/към... +-а на това решение е че е практически незасечимо...

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

виж погледни и изхода от dmesg там дали няма да има някакъв хинт...

[Примерен код]

Привет, ето и моите 10 цента:

- Пробвай да направиш tcpdump/wireshark на ppp0 и да видиш какво реално минава през интерфейса и какво получаваш като отговор.

Виж все пак дали нямаш -P FORWARD DROP някъде в iptables-a... знам че е тъпо, но и с това съм имал 1 път проблем... '>

- Пробвай следния код:

Примерен код

EXT=ppp0 INT=eth1  #или eth0, където ти е вързан комп2. sysctl -w  "net.ipv4.ip_forward = 1" iptables -F iptables -t nat -F iptables -t mangle -F iptables -X iptables -P FORWARD ACCEPT # iptables -t nat -A POSTROUTING -o $EXT -j MASQUERADE # obsolete iptables -t nat -A POSTROUTING -o $EXT -j SNAT --to-source `ip addr list ${EXT}|grep inet|grep -v inet6|tr "/" " "|awk {'print $2'}` ## това не съм го тествал дали така може в shell script, но идеята е да вземеш ip на ppp0 интерфейса iptables -t mangle -A PREROUTING -i $EXT -j TTL --ttl-set 64 iptables -t mangle -A POSTROUTING -s 192.168.0.0/24 -o $EXT -j TTL --ttl-set 64

успех!

Да, и аз го имах този проблем със suspend-a, след ъпдейт се оправи. Явно някакъв бъг е било...

Преди време имаше такъв проект, виж поразрови... може и да изскочи нещо.