FreeBSD 12.0-RC2

 ( trey | 2018. november 25., vasárnap - 11:06 )

Tesztelhető a FreeBSD 12.0 második RC-je. A freebsd-update(8) bináris frissítő patchek is elérhetők az 12.0-RC2-höz.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Délelőtt 11 táján lefutott a frissítés a netbookon (szokatlanul gyorsan amúgy).

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

FreeBSD-n mennyire tapasztalható azonos hardveren a frissült csomagok lassulása, elhízása, a frissítések után?

Van valaki, aki azonos hardveren használ BSD-t mondjuk 8 éve?

A BSD-k szoftverkínálatában elég nagy az átfedés a Linuxokéval, vagy épp a Solariséval; a specifikus cuccokat leszámítva.

A FreeBSD 9-ben debütált új csomagkezelőről, az apt klón pkgng-ről viszont elég sok rosszat olvastam.
Például ellentétben a korábbi pkg programokkal ez nem működik együtt a ports-szal, nem ismeri fel, ha onnan van valami telepítve és ütközéseket csinál, amiket még feloldani sem lehet.
Vagy az upgrade rész bajai, hogy ha upgradelni akarsz egy csomagot, akkor először kézzel le kell törölni a régit, valamint az, hogy nem követi rendesen a telepített és igényelt verziókat és ha felteszel valamit, aminek a függősége nálad ugyan telepítve van, de újabb verzió kellene belőle, akkor simán felrakja a kért csomagot és ezzel el is töri, ahelyett, hogy meggátolná a telepítést, vagy upgradelné az érintett függőséget.
Továbbá bár ez csomagkezelő, de repository nincs hozzá, neked kell csinálnod helyben egy jail-t, abba pakolhatod a helyi portsból forgatott csomagokat, ahonnan a csomagkezelő majd telepíthet; ennek ha megfeszülök se értem az értelmét: ha már úgyis forrásalapú csomagkezelésre vagyok kényszerítve, akkor minek ez a hercehurca a sima ports helyett?
Az autoremove opció törött, olyan csomagokat is töröl, amik élő függőségei más csomagoknak, amik ezáltal el is törnek.
Ezeken felül a csomagok adatait egy SQLite3 adatbázisban tárolja, ami egyszerűen overkill és a tetejébe még corruption-prone is.

Nem flame-nek szántam, csak leírtam, amit én tudok róla.

Tehát sikerült ezt is elbaszni legalább már egy idealizmussal. Köszi a beszámolót.

Nincs mit.

Mondanám, hogy próbáld ki a TrueOS-t (FreeBSD fork), abban AppCafe csomagkezelő van (a minőségéről semmi infóm nincs), de ahhoz mindenképpen 64-bites CPU kell, tehát Pentium III-ason nem fog menni. Szerezz be egy K8-as (Athlon 64, Opteron, Sempron, Turion 64) gépet. RAM-ból elég 1 GB is (de ajánlott a 4 GB).

Ha ragaszkodsz a P3-hoz, akkor a FreeBSD 8.4-et próbáld, vagy annak a forkjait.

Valami félreértés van itt. Igaz, hogy nálam nem FreeBSD 9, hanem 11 van, de nem is pkgng, hanem pkg, és normálisan működik. Az hogy ne lenne hozzá repó, az teljes képtelenség.
--
ulysses.co.hu

Menetközben átnevezték a pkgng-t pkg-ra. A többire csak azt tudom mondani, hogy nincs kizárva, hogy elavultak az infóim.

Igen, elavultak (bár szerintem bizonyosak sose voltak igazak).

Ami biztosan igaz: a ports és a pkg két külön állatfaj, és a pkg nem tud olyat, hogy ha valami nincs repóban, akkor majd lefordítja neked. Ellenben ebből a mondatból az is következik, hogy de, van(nak) repók. Jelenleg 11.x-ig bezárólag i386 és amd64 architektúrákhoz . ez talán változik a 12.0-val, és a sokak által várt Arm és Arm64 (hivatalos nevén Aarch64) repók is megjelennek. (Én legalábbi nem szívesen fordítgatok a málnán.)
Kétféle repó létezik: alapból a telepítéskor a -quarterly (kb: stable) kerül bekapcsolásra, de akinek kedve van, az válthat a -latest nevűre. Az első, mint neve is mutatja, kb 3 havonta frissül, az utóbbi kb 2-3 naponta. Én kb 2 éve használom ez utóbbit, tán 3-4-szer fordult elő, hogy valami miatt 1-1,5 hétig nem volt repó frissítés.
Amennyiben valami nincs meg a bináris repóban, akkor két lehetőség:
- felrakod portsból: cd /usr/ports/x/y && make all install clean # ekkor valóban kissé zűrzavaros lesz, hogy most akkor mi honnan is van, helyette javasolható a másik módszer
- csinálsz egy saját repót (egyetlen egyszer, a továbbiakban feltételezzük, hogy az alapértelmezett helyet akarod használni, azaz a /usr/ports/packages könyvtárat), és a telepítés: cd /usr/ports/x/y && make all package clean && pkg repo /usr/ports/packages && pkg update && pkg install x/y # ez láthatóan igényel 3 plus parancsot, de innentől a rendszer tudni fogja, hogy a ez a csomag a saját repódból jött.
Természetesen frissíteni is lehet az ilyen csomagokat (is). és csak érzékeltetésként: 311 csomag van a asztali desktop gépemen, és összesen 3 db saját repóból: libdvdcss, lame és faac. Ebből az első kettő olyan, hogy a bináris terjesztésnek jogi akadályai vannak, a harmadikban meg korábban valamit lokálisan mókoltam (és most látom, hogy már nem lenne szükséges, azzal is válthatok a hivatalosra. (Azaz igazából nálam 2 csomag van lokális repóból, kevesebb, mint 1%.) Hopp, komoly mellélövés, ez a NAS-om, az asztali gépen 1242 / 8 az arány :-) (Keveselltem is a csomagokat.)

Természetesen a latest repóval időnként akadnak problémák - de általában a következő 2-3 nap múlva esedékes frissítésnél megoldódik; mint ahogy a saját repóval is lehet szívni. Én pl. korábban az egyik csomagomat lelockoltam, mert nem akartam, hogy egy frissítés véletlenül felülírja a központi repóból jövővel (tudtommal ez a hiba már megszűnt, lévén mint írtam, számon tartja, hogy melyik repóból jött). Aztán ezt a lockolást szépen elfelejtettem, és rohadtul nem értettem, hogy vagy 3/4 év múlva amikor jött egy frissítés, akkor vajon miért nem tudom a repómból frissíteni. (Mondjuk ezt például jelezhetné a pkg upgrade.)

Szóval nem annyira szar az a pkgNG.

Ui (jav): a korábbi pkg_XXX sem működött együtt jól a ports-ból jövő dolgokkal, nem véletlenül volt portmaster (és még valami portsból felrakható másik)

Ui2: elég régóta használom a pkg autoremove-ot, hacsak nem force-olsz valamit, akkor valaminek a függőségét nem szedte le még soha.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Mint mondtam én csak olvastam róla, saját tapasztalatom nincs a pkgng-vel, mert FreeBSD-t először csak ARM-on és PowerPC64-en használtam, ott meg nem voltak bináris csomagok, csak ports; x86-on meg felraktam, aztán nem volt több időm kísérletezni vele... Viszont a neten rengeteg rosszat olvastam róla; lehet, hogy ezeket azóta javították. Az SQLite3 persze maradt. Azon vitatkozhatunk, hogy overkill-e, vagy sem, de az, hogy neked nem sérült le sose, az nem jelenti, hogy másnak sem; jópár ilyen topic van a neten, hogy elcrashelt a pkgng db-je. Hogy aztán ez user error volt-e, vagy sem, az már más kérdés, de ettől még sokkal corruption-prone-ebb, mint a dir/textfile alapú: ott egy lesérült fájl, nem érintette az egész repository-t, másrészt egy szöveges fájlt akár kézzel is ki lehet javítani.

Jelenleg 11.x-ig bezárólag i386 és amd64 architektúrákhoz . ez talán változik a 12.0-val, és a sokak által várt Arm és Arm64 (hivatalos nevén Aarch64) repók is megjelennek.
Arm-ra már van egy jó ideje (ld. itt), az RPi-s img-ben ez a működő repó be is van állítva.
Bár ahogy írják, only quarterly is updated.

felrakod portsból ... ekkor valóban kissé zűrzavaros lesz, hogy most akkor mi honnan is van
Ekkor a repository "unknown repository" lesz (ld. pkg query "%n %R" csomagneve). Persze nem feltétlen csak a ports-ból telepítetteké, hanem a pkg add paranccsal telepített is.

Ez nekem nagyon kellett :) thx

Baromi sok fals infó, lásd másik hozászólásom is, valamint
- nem kell jail a local repóhoz
- régebben dir/file alapú adatbázisa volt, most SQLite3. Hogy mennyire overkill azt nem tudom, de még sose sérült
- működik a csomagok frissítése csont nélkül (itt néha vannak spéci lépések, amiket a pkg updating ki is ír, hogy mit kell tenni, azaz azt értelmes ember a frissítés részeként futtatja); illetve időnként voltak valban elcseszett frissítések (de ez az alapértelmezett repó használata esetén igen nagyon ritkán áll elő, a latest-nél is elég ritka)

stb

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A másik szálban válaszoltam erre is.

olvastam
Olvasni sok mindent lehet. Ahogy a példa mutatja, nagyon sok hülyeséget is.

Lehet. De feltételezem, hogy az userek nem az ujjukból szopták ezt akkoriban. Inkább az lehet, hogy a FreeBSD projekt eltakarította a problémák egy részét.

Értem. És ezekről a hibákról tudnál is forrást adni? Pl. fórumbejegyzés, bug report, stb.
Ui. kb. a kezdetektől fogva használom a pkgng-t (a váltás környékén kezdtem el a FreeBSD-t használni, nem csak olvasni róla), és egyrészt az általad jelzett hibák jelentős részével nem találkoztam, még a fórumon sem.

Persze a pkgng közel sem tökéletes, igen sok sebből vérzik (pl. itt és itt egy-egy hibajegyem). A régi csomagkezelővel nem tudom összehasonlítani (felhasználóként), mert azt nem használtam jelentős ideig (bár egyébként szerintem az sem működött együtt a ports-fával).

Már régen olvastam őket, most csak ezt találtam egy gyors keresésre: http://www.ivoras.net/blog/tree/2015/Feb-why-freebsds-pkg-sucks.html Illetve blogposztot többet is, de azok nem írnak konkrét hibákról, hanem csak általánosságban. Meg egy SQLite3 corruption issue-t is találtam: https://serverfault.com/questions/591590/freebsd-pkg-database-deleted (Mondjuk ebből többet is láttam, de egy része user-error volt.)

A FreeBSD-t egyébként én is használtam korábban, csak a pkgng maradt ki.

csak a pkgng maradt ki
Akkor kvittek vagyunk, mert nekem az elődje :)

http://www.ivoras.net/blog/tree/2015/Feb-why-freebsds-pkg-sucks.html
Pont a php, amiről pont az előbb írtam. Egyébként amennyire tudom, ez már megoldott:

# pkg install php56-ctype
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   6.8MB/s    00:01
Processing entries: 100%
FreeBSD repository update completed. 32579 packages processed.
All repositories are up to date.
Checking integrity... done (2 conflicting)
  - php56-ctype-5.6.38 conflicts with php71-ctype-7.1.22 on /usr/local/include/php/ext/ctype/config.h
  - php56-5.6.38 conflicts with php71-7.1.22 on /usr/local/bin/php
Checking integrity... done (0 conflicting)
The following 4 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        php56-ctype: 5.6.38
        php56: 5.6.38

Installed packages to be UPGRADED:
        php71: 7.1.22 -> 7.1.24
        php71-ctype: 7.1.22 -> 7.1.24

Number of packages to be installed: 2
Number of packages to be upgraded: 2

The process will require 21 MiB more space.
3 MiB to be downloaded.

Proceed with this action? [y/N]: ^C

SQLite3 corruption issue
Hát igen, ebből a szempontból a sok kicsi fájl valóban hibatűrőbb megoldás, mint egy darab fájl.

> Egyébként amennyire tudom, ez már megoldott:

Erre mondtam, hogy nem tudom mit oldottak meg eddig és mit nem.

> Hát igen, ebből a szempontból a sok kicsi fájl valóban hibatűrőbb megoldás, mint egy darab fájl.

Esküdni mernék rá, hogy pár poszttal feljebb ugyanezt írtam le Zahynak...

Esküdni mernék rá, hogy pár poszttal feljebb ugyanezt írtam le Zahynak...
Igen. Ezzel csak azt akartam mondani/jelezni, hogy az sqlite vs. sok fájl történet ezen aspektusával egyetértek, viszont további pro vagy kontra érveket (hozzá nem értés miatt) nem tudok mondani.

Akkor csak végig gondolva a dolgokat.
Az SQLite esetében elég egy fájlt megnyitni és le tudod ellenőrzi a konzisztenciát, így kibukik a sérülés. Egy fájl esetében gyorsabb is kikeresni a relációkat, hiszen a mérete miatt (repo tartalomjegyzék, vagy konfigurációs beállítások) jószerivel úgy is memóriatömbben (vagy csak pufferben) dolgoznak vele.
Ha meg több fájl van (tipikusan táblánként egy) akkor ez kicsit bonyolultabb, több fájlnyitással és azokban külön külön navigálással jár. Mondjuk ez mind programozói szempont.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Csakhogy itt nem 1 SQLite3 tábla vs. sok SQLite3 tábla volt a téma, hanem 1 SQLite3 tábla vs. sok textfile.

Nem SQLite tábláról volt szó, hanem adatbázisról. (végig néztem) Abban meg ki tudja hány tábla van?
Kisméretű adatbázisok esetében nem sérülékeny az SQLite. Miért lenne? Valószínűleg fájlméret szerint sem nagyobb mint a korábban használt sok fájlos rendszer.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Az egész onnan indult ki, hogy csomagkezelésre az SQLite3 overkill és corruption-prone-ebb, mint a sok kis kicsi textfile. Textfile. Szó nem volt arról, hogy az SQLite3 lenne több fájlban.

Egy szóval nem mondtam, hogy az SQLite több fájlban lenne. Ettől még tartalmazhat több táblát.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Nem, te azt mondtad, hogy "Ha meg több fájl van (tipikusan táblánként egy) akkor ez kicsit bonyolultabb", de itt ilyesmiről szó sem volt előtte, nem az SQLite3-at akarta bárki több részre darabolni, textfile-okról volt szó.

Engem azért egy kicsit csak furdal a kiváncsiság:
dpkg / apt illetve rpm / yum (vagy épp yum helyett zypper, vagy dnf) esetén milyen módon tárolják ezt az "Installed Product Database" infót a FreeBSD-nél sokkal elterjedtebb Linux terjesztések? Csak mert én ezt az életben nem néztem, de van egy halvány sejtésem arról, hogy ott is valamilyen - nem feltétlenül SQL(ite3) - adatbázis. (Azaz a feltételezésed szerint 1 vagy több error-prone bináris fájl.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A dpkg a /var/lib/dpkg/info könyvtárban tárolja az egyes csomagokhoz tartozó fájllistákat (csomagnév.list), md5 összegeket (csomagnév.md5sums), a konfigfájlokat (csomagnév.conffiles) és az install/uninstall idején futtatandó szkripteket (csomagnév.[pre/post][inst/rm]). A telepített csomagok infói a /var/lib/dpkg/status fájlban vannak tárolva, az elérhető csomagok a /var/lib/dpkg/available fájlban; ezek sajnos nincsenek csomagokra bontva, viszont szövegesek, bináris adatbázis nincs.

Az apt a /var/lib/apt/lists/ alatt tartja az egyes repository-k csomaglistáit, minden repo egy szöveges file, sajnos ez sem úgy van, hogy a repo a könyvtár a csomaginfó a fájl, de bináris adatbázis itt sincs.

A többi disztribúció csomagekezelőiről nincs infóm.

Viszont én egy szóval nem mondtam, hogy a Linuxos csomagkezelőket kell másolni.

> Viszont én egy szóval nem mondtam, hogy a Linuxos csomagkezelőket kell másolni.

Mint ahogy én sem.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem mondtam, hogy mondtad.

Függetlenül mindenféle Linuxos csomagkezelőtől, sokkal jobban jár az, aki dir/textfile felállással csinálja a csomaginfók tárolását. Az igaz, hogy ott van egy minimális parsing, de egy ini-like microtext parse-olása még mindig kisebb rendszerterheléssel és kevesebb hibalehetőséggel jár, mint egy monolitikus BLOB, meg az oda tartozó DB engine; pusztán a felépítés egyszerűsége miatt.

sokkal jobban jár az, aki dir/textfile felállással csinálja a csomaginfók tárolását
Érdemes lenne megkérdezni a RedHat/Fedora ill. FreeBSD döntéshozóit, hogy milyen szempontok alapján döntöttek egy adatbázis mellett a korábbi rendszer ellenében. Nem hinném, hogy az SQLite-os banda megfinanszírozta őket :)

Szerintem egyszerűen a kényelem miatt döntöttek így. Sokkal egyszerűbb egyszerű SQL kéréseket írni, mint parsert.

Ez akkor lenne teljesen elfogadható érv, ha most állnánk a döntés előtt, hogy milyen legyen a majdani csomagkezelő. De a régi pkg már rendesen megvolt akkor már nagyon sok éve. (Nekem személy szerint az upgrade hiányzott belőle, de egyrészt ezt megoldotta nekem a portmaster, másrészt nyilván jó részét át lehetett volna venni az OpenBSD-ből, ahol viszont a "régi" csomagkezelővel is létezik frissítés.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Akkor passz.

A görcs tudja - már csak azért, mert alapvetően elég szűkre szabott információk lekérése a reális, azaz pl. fájllista, függőségek (mindkét irányban), fájl "gazdája", meg persze alapvető infók a csomagról (pár szavas leírás, honlap, stb.), és kb. ennyi.
Azaz pl. a "listázd ki az a betűvel kezdődő csomagokban található, legalább X byteos /usr/local/lib-ben levő fájlokat" összetettségű lekérdezésekre túl nagy igény nincs (legalábbis úgy gondolom).

Az alap-lekérdezések meg már eleve adottak voltak, ahogy Zahy írta.

Lehet, de senki nem mondta, hogy nem lehet "indexeket" építeni a különféle csomagok különféle értékeiből - ezek sima szöveges listák lennének, ahol egy sor egy csomag + érték (vagy egy sor a csomag és egy sor az érték, most hirtelen nem tudom melyik lenne a gyorsabb) és minden értékre van egy lista - hogy lehessen benne dirscanning és hasonló nyalánkságok nélkül keresni. Erre persze lehet mondani, hogy ezt az SQL engine-ok alapból tudják, de:
- Ezek a listák nem szerves részei a csomagok kezelésének, nem tárolnak kritikus adatot, csak egy helyre vannak gyűjtve keresés céljára, mivel ezekkel csak keresni lehet, tehát senkit nem érdekel, ha lesérülnek, rebuild és kész, míg az SQL-nél az index is a DB-ben van.
- Pár sallang nélküli szöveges lista még mindig kevesebb helyet foglal, mint egy táblákkal, triggerekkel és egyéb nem-biztos-hogy-itt-szükséges-cuccokkal teli DB.
- Egy sima szöveges listában egy értéket még mindig gyorsabban fog megtalálni a gép, mint egy komplex DB-ben.
- És ennek az implementációja még mindig több nagyságrenddel kevésbé komplexebb, mint egy full SQL DB.

Nyilván, ahogy a szűrési igények egyre komplexebbé válnak, úgy kezd el a mérleg az SQL felé billenni, de ahogy írtad is, itt nincs szükség igazán komplex szűrésekre.

Rövid válasz:

"Since RPM 4.13, the RPM database has been able to be stored in multiple database formats. As of RPM 4.14, there are three database formats: BDB, LMDB, and NDB."

És hogy az élet (itt) sem olyan egyszerű, pl:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2SX3LXSUQE2657IQAX63A6YVP6P76LC3/

https://bugzilla.redhat.com/show_bug.cgi?id=1086784

https://github.com/SUSE/kiwi/issues/546

Arch Linux esetén se SQL, hanem csomagonként egy tar.gz-be csomagolt könyvtár.

Hát mondjuk a dir/file OK, de ezt targézába rakni szerintem rosszabb, mint ha valódi adatbázis lenne. Ugyanúgy bináris, csak épp a tömörítés miatt itt egy bithiba elképesztő korrupciót tud okozni. (Csomagoltam már ki pár 10 KB-os archívumot, ami szépen teleírta a szabadon levő néhány száz MB-os /tmp-t.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

+1, a becsomagolással kb. adtak a szarnak egy pofont, főleg mivel ha csomagonként van egy .tar.gz és más nincs benne, mint a leírók, akkor most betömörítettek pár darab pártíz byte-os fájlt.

Ez így ebben a formában nem igaz, mint ahogy az általad linkelt wikihivatkozásból sem ez olvasható ki :)
Nem csomagonként, hanem reponként (core, community, stb) van tar.gz-be rakva mappastruktúrában az adott repohoz tartozó összes csomag desc fájlja a /var/lib/pacman/sync/ mappában, ezt hívja a pacman csomag adatbázisnak. De nem csak itt tárol adatokat a csomagokról, és nem is csak a pacman tárol adatokat a csomagokról.

Akkor mi a rendszer, főleg a telepített csomagokat illetően? Nagyon régen használtam Arch-ot.

ha upgradelni akarsz egy csomagot, akkor először kézzel le kell törölni a régit
Ó, azt hiszem, rájöttem, mire gondolsz (vagy legalábbis mit olvashattál).
Igen, vannak olyan csomagok, amelyekből egyszerre több verzió is elérhető, pl. a samba, amiből jelenleg 4.6, 4.7 és 4.8 elérhető, samba46, samba47 és samba48 csomagnevekkel. Igen, ha a samba 4.6-ról 4.7-re akarsz frissíteni, akkor valóban ez a mondás, mint ahogy pl. itt le is írják. Hasonló egyébként a php is (meg néhány más esetben). De ezekben az esetben a csomag nevéből sejthető, hogy elérhető több verzió is.
Amúgy ezeken kívül a pkg upgrade általában jól megy, csak ilyen esetben szükséges (ha igény mutatkozik rá) kézi beavatkozás.

Dehát szó szerint ezt írtam le én is: "ha felteszel valamit, aminek a függősége nálad ugyan telepítve van, de újabb verzió kellene belőle, akkor simán felrakja a kért csomagot és ezzel el is töri, ahelyett, hogy meggátolná a telepítést, vagy upgradelné az érintett függőséget."

Így kezdtem: Ó, azt hiszem, rájöttem, mire gondolsz - csak részleteztem :)

Ahogy fentebb írták, a csomagok kb. ugyanazok, mint bármely Linux rendszeren. Így nem feltétlen a FreeBSD fejlesztőin múlik, hogy az adott (más által fejlesztett) program mennyire lassul vagy hízik.
Ami esetleg előny lehet, hogy vannak opciók is, azaz sok esetben beállíthatod, hogy kell-e adott funkció a programba vagy se. Sajnos ez azzal jár, hogy saját magadnak kell az adott programot fordítanod, és frissítésnél (pkg upgrade) figyelni kell, hogy a forrásból fordított programod ne íródjon felül.
Néhány program esetén választhatsz, hogy qt4 vagy qt5 verzió kell-e (pl. vlc), mindkettő verzió szerepel a repóban.

Hopp, erre nem reagáltam:

> Van valaki, aki azonos hardveren használ BSD-t mondjuk 8 éve?

Szégyen gyalázat, már nem annyira, kb fél évvel ezelőtt lecseréltem a fő asztali gépemet. Kb 10 éves ~ 1,8 GHz-es C2D volt. (És egy i3 váltotta :-) )
Az is igaz, hogy a most már kevéssé használt (de még aktív) laptopom egy CoreDuo-s HP 2 GB memóriával - no az egy cseppet lassúnak tűnik a mai modern szarokhoz, ezzel együtt is időnként Linuxot is futtatok benne VirtualBoxban a FreeBSD alatt :-) (persze szigrúan karakteres felületű szerverdisztrókat teszt célokból). És persze folyamatosan frissen tartom, egyike lesz azoknak a gépeknek, amelyiken hamar meglépem majd a 11.2 -> 12 váltást.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Most a free bsd, vagy a net bsd a "biztonságosabb"?
Mert volt erről valami flame és hitvita is, de egyébként van erre valami "hivatalos" adat?

Nyilván nem teljes ezzel a kép, de "mostanság" divatos biztonsági rés:
https://hardenedbsd.org/content/freebsd-and-hardenedbsd-feature-comparisons
https://en.wikipedia.org/wiki/Address_space_layout_randomization
https://forums.freebsd.org/threads/aslr-on-freebsd.31651/

FreeBSD: https://www.freebsd.org/security/advisories.html
Persze a használt programokon is nagyon sok múlik.

Szerintem úgy jobban tudna hozzáértő (nem én) tanácsot adni, ha pontosan leírnád (vagy legalább vázolnád), hogy mire szeretnéd használni.

Akkor már az OpenBSD, azoknak ez a mániájuk, specialitásuk. Csak közben lassan már az egész rendszert kidobják vagy letiltják. :/

Létezik még egyáltalán a NetBSD? (Mondjuk én még használom, de a distrowatch listájáról lecsúszott.) Mert ha nem létezik, akkor kijelenthető, hogy baromira biztonságos.
--
ulysses.co.hu

Hogy a fárasba ne létezne, alig 4 hónapja jött ki a 8.0.

Boccs az off-ért:

sh-ban kellene egy 3 soros szkriptet írnom, de nem bírom összehozni a syntax-ot :(
cmp 2 db fájl-ra pl. cmp /etc/1 /etc/2, ha különböznek (vagy bármilyen error van), akkor cp /etc/2 /etc/1 művelet, ha egyezés van, akkor szimplán kilép.

Köszönet!
--

Gondolom, cmp /etc/1 /etc/2 || cp /etc/2 /etc/1.

De ez egy sor, neki 3 kell! Ráadásul *szépen* nem is igen lehet 3 sorba tördelni (nyilván nem a sorvégi backslash-re gondolok).

if ! cmp /etc/1 /etc/2
then cp /etc/2 /etc/1
fi

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszönet! Minden példában szerepelt [] ezért aközé akart tenni a feltételt.
--

Ez azért van, mert az "if" *parancsot* vár (nem pedig feltételt), és ennek a parancsnak az igaz státusza esetén megy a "then" (hamis státusz esetén az opcionális "else") ágra. A [ (bal szögletes zárójel) nevű *parancs* pedig a Unix világban a "test" parancs szinonímája (némely megvalósításban egy bináris két hardlinkjeként implementálva).

Ha az x/y fájl (megléte és) olvashatósága estén akarsz valamit csinálni, akkor vagy azt írod, hogy:

if test -r x/y
then
....

vagy pedig a vele teljesen ekvivalens
if [ -r x/y ]
then
...
[/code]
formát. Annyit kell tudni, hogy a ] (záró szögletes zárójel) csak a szimmetria kedvéért van ott, az a nyomorult test parancs úgy van leprogramozva, hogy ha nem "test", hanem [ néven indítják, akkor ellenőrzi: ha a paraméterlista utolsó eleme a ] - akkor jó, ha bármi egyéb, akkor hibaüzenetben kéri, hogy add meg.

(OK, az if után parancssorozat is írható, akkor közülük az utolsó státusza számít; vagy épp összetett parancsok: a || b vagy épp a && c. Meg nyilván van még egymillió apróság.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszönet, sejtettem h. valami ilyesmi van a háttérben, csak más szkriptnyelvben ezt könnyebben felfogtam.
--