=== eTeddy1 is now known as eTeddy [07:55] Hallo, woran wird für den Laien wie mich ergennbar das der Server Code von SNAP propäritär ist, wofür Snap oft kritisiert wird? https://github.com/snapcore/snapd [07:55] Title: GitHub - snapcore/snapd: The snapd and snap tools enable systems to work with .snap files. (at github.com) [08:00] interrobangd: er ist nicht proprietär im sinne der software lizenz, sondern der infrastruktur. -> niemand nutzt es ausser canonical, und der "shop" wird von ihnen betrieben. [08:02] "Selbst ein alternativer Snap-Store sei nicht möglich. Der Servercode dazu ist proprietäre Software von Canonical." Quelle: https://www.golem.de/news/ubuntu-canonical-verteidigt-snap-store-gegen-kritik-von-linux-mint-2006-148980.html [08:02] Title: Ubuntu: Canonical verteidigt Snap-Store gegen Kritik von Linux Mint - Golem.de (at www.golem.de) [08:03] Also was jetzt \o/ [08:03] auch in den Kommentaren wird gesagt das der Store propäritär ist. [08:04] interrobangd: der artikel ist da etwas unspezifisch. so wie ich es interpretiere ist es in etwa so: der snap-server code ist opensource. der shop-server code ist es nicht. [08:04] was völlig legitim und betriebswirtschaftlich einleuchtend ist. [08:08] interrobangd: auch wenn der vergleich etwas hinkt: facebook z.b. ist einer der grössten contributoren zu vielen serverprojekten, wie z.b. php. was open source ist. was sie aber nicht rausgeben, ist der code ihrer webseiten. ich denke das ist ähnlich gelagert. [08:48] schon, hinkt aber wirklich der vergleich, weil ein eigenes facebook bauen kann ich mir, aber nicht mein eigenen snap store. [08:48] warum nicht? [08:49] weil interrobangdbook sich keiner merken kann. [08:49] oh, hier ist ontopic. sorry. [08:49] hrhr [08:50] Letothe2nd, siehe kritik von den mint entwicklern [08:50] wo mit sich der kreis wieder schließt, weshalb ich gefragt habe [08:52] interrobangd: ohne jetzt mich in die tiefen der aussagen der mint-entwickler zu begeben, gibt es da viel interprestationsspielraum. den ich bin mir ziemlich sicher dass deren "geht nicht" sich nur drauf bezieht "da gibts nichts offenes also gehts nicht, denn selber schreiben können/wollen wir den store nicht" [08:53] was it denn die frage? irgendwie habe ich beim scrollen keine gefundne. [08:54] LupusE: "warum behauptet mint dass der snap store proprietär ist?" [08:56] das wuerd eich eher in #linuxmint-de fragen (wenn es den channel gibt). upuntu ist ja auch nicht gerade fuer das leben der GNU philosophie bekannt. [08:57] für mch klingt es ein wenig nach "hey wir wollen dass ihr die ganze basisarbeit macht, und dann wissen wir alles besser und noch dazu stehen wir gut da" - wogegen canonical ein klassisches gewinnorientiertes unternehmen ist das geld verdienen will/muss. [08:59] ob man das jetzt gut oder schlecht findet sei dahin gestellt. aber erst eine nutzniesserdistro zu erstellen und dann stunk zu machen weil derjenige der die arbeit macht bitte schön auch selber ernten möchte finde ich ein wenig unangebracht. [09:09] ich behaupte das es der verbreitung von Snaps nicht zu gute kommt wenn es kein freien server gibt [09:10] zur kenntnis genommen. [09:11] andernfalls hätte sich der DPKG nicht so breit durchsetzen können [09:11] was hat nun das eine mit dem anderen zu tun? [09:11] das ist eine philosophische diskurssion. meinst du die leite verzichtne auf die Nvida oder ATI reiber, weil die nicht quelloffen sind? Warum sollten die sich also fuer einen reposetory interessieren? [09:12] LupusE: bingo [09:12] "es funktioniert, fertig" [09:16] Letothe2nd, es sind beides Möglichkeiten Software zu verteilen (.snap und .deb) [09:17] aber ich kann mir lokal kein eigenen snap store/server einrichten, im gegensatz zu deb. selber spiegeln, im unternehmen bspw. welches linux einsetzt sehr sinnvoll [09:18] interrobangd: nein. jetzt setzt du gerade infrastruktur mit einem dateiformat gleich. [09:18] nein, ich meine nicht das format sondern genau die infrastruktur [09:18] interrobangd: dass es für .deb frei verfügbares tooling gibt sagt genau gar nichts darüber aus ob das format nun gut oder schlecht ist. [09:19] ich meine nicht das format, sondern die infrastruktur [09:19] egal.. [09:19] interrobangd: dann stimm doch einfach mit den füßen ab und benutz ubuntu nicht, wenn dich die snaps stören. genau diese wahl hast du immer. [09:20] ja ich bin auf der seite der mint entwickler und nutze mint [09:21] also was ist dann das problem? [09:21] idiologie [09:21] *sigh* [09:21] da bin ich raus. [09:23] Klar, wer Snap nicht mag, braucht es nicht zu benutzen. Der Stein des Anstoßes kam aber daher, dass Ubuntu Chromium *nur noch* als Snap anbietet. Das DEB Paket ist ein Transitional Paket, das das Snap nachinstalliert. [09:23] Heavy91: ich sehe immer noch das problem nicht. [09:25] nuja, du kennst die problematik mit dem apple store und porno-apps? [09:25] Letothe2nd: Ich auch nicht. Mint forkt von Ubuntu und stört sich daran, dass Ubuntu eine bestimmte Entscheidung getroffen hat (nämlich Chromium nicht mehr als DEB anzubieten). [09:25] Canonical bietet eine Distribution an, dafür ein bestimmtes Paket und sorgt dafür dass es bei bestimmungsgemäßer Verwendung funktioniert. Sich hinzustellen un zu sagen "Uns passt nicht dass ihr eure internen Prozesse ändert weil ihr das so entschieden habt, und das ist ganz schlimm und überhaupt" (mit dem primären Hintergedanken die Package Feeds und damit Buildfarmen unentgeltlich weiter zu [09:25] nutzen) finde ich schlicht unangebracht. === it_diver1 is now known as it_diver [09:26] Meine Antwort ist, dass Mint eben Chromium selber paketieren muss, wenn sie mit dem vorhandenen nicht zufrieden sind... [09:26] Heavy91: sehe ich ebenso. [09:27] ja, sehe ich auch so - was der verbreitung von snaps nicht zuträglich ist [09:27] Ich bin mit Snap auch nicht 100% zufrieden, nutze sie aber trotzdem, weil die Vorteile für mich eindeutig überwiegen. [09:27] Heavy91, also der gnome taschenrechner ist das beste beispiel das man es auch übertreiben kann :D [09:27] hinsichtlich ladezeit [09:28] interrobangd: Sagt mir nichts. Was wird da übertrieben? Ich nutze kein Gnome sondern MATE. [09:29] gut, den habe ich auch und zwar via dpkg und nicht als snap :D [09:30] der gnome calculator wurde in ein snap gepackt und die winzige anwendung, welche in weniger als eine sekunde gestartet ist, brauch nun 2-4 [09:30] ok, das ist natürlich Unfug. ;-) [09:30] ja [09:30] jaein. [09:31] buildtechnisch ist das kein unfug, weil man sich sparen will zwei infrastrukturen zu pfelgen. [09:31] dass das resultat vielleicht in dem fall dann optimierungsbedürftig ist, darüber kann man reden. [09:32] Wenn man zu viele Kleinstapplikationen in eigene Snaps packt, hat man irgendwann hunderte von /dev/loop Devices. Dann kriegt man ganz andere Probleme. Snap ist für große Applikationen da. [09:32] depends (TM) [09:34] in dem fall bin ich in den details nicht drin, also keine aussage von mir. ich kann nur sagen dass distrobau und pflege ziemlich komplex und aufwändig sind, oft an stellen die man nicht vermuten würde. und daher sind oft die entschiedungen von aussen betrachtet merkwürdig bis unverständig. [09:37] Es kann mir niemand erzählen, dass Canonical den Gnome Calculator in einen Snap packt, weil die Pflege des DEB zu aufwändig ist, während der Rest des Gnome Desktops als DEB verteilt wird. Ich denke eher, dass dass eine Demo-Applikation ist, mit der man die Möglichkeiten von Snap aufzeigen kann. [09:38] Heavy91: natürlich kann es ein testballon sein, keine frage. wie gesagt: von aussen betrachtet muss nicht alles sinnvoll erscheinen was es tatsächlich ist. === it_diver1 is now known as it_diver === it_diver1 is now known as it_diver [12:10] Gibt es sowas wie den "screen" Befehl auch für Browser? [12:10] du meinst, tabs die beim nächsten mal wieder aufgehen? "anheften" heißt das afaik [12:11] Also dass, wenn der Client offline geht, die Brwosersitzung trotzdem bestehen bleibt und später verbunden werden kann. [12:11] das macht so jetzt nicht direkt sinn als frage [12:11] warum nicht? [12:12] der client ist der browser... ich glaub, das kann so nicht gehen... [12:12] wahrscheinlich nicht. [12:12] spätestens bei https gibt es Probleme. [12:13] serverseitig kann man da viel machen :) [12:13] Es geht mir um Jupyter Notebooks. [12:14] doev: serverseitig kann man viel machen. [12:14] bzw, serverseitig + local storage. [12:15] wenn ich mir godbolt.org anschauen, da kann ich schalten und walten, zu machen, nächstes mal beim öffnen gehts an genau der stelle weiter. aber das muss der webdienst regeln, nicht der browser. [12:18] arg, Ich merke gerade, dass die sowieso weiter laufen und wieder aufgeriffen werden können. Build in sozusagen. Ich Depp. [12:18] dürfen wir dich zitieren? [22:15] hi. hätte mal eine kurze frage zur installation von ubuntu 20.04 server. zwar würde mich interessieren ob man bei der installation schon btrfs als FS angeben kann. [22:16] ich würde denken das geht schon ne ganze weile, aber würde jetzt auch nicht die hand dafür ins feuer legen wollen [22:16] dann hab ich noch eine partition die mit btrfs gelabeled ist, das würde ich nur gern fixen dass er für sdb1 das FS anzeigt aber bür sdb nicht. [22:16] zumal der installer ja gewechselt hat [22:16] gut, dann teste ich das einfach morgen mal [22:18] mir ist unklar ob du dich da eben auf ein dateisystemlabel oder ein partitionslabel beziehst (und dann auf welchen partitionstabellentyp) [22:19] *bezogst [22:19] beziehe mich auf die ausgabe von lsblk [22:19] sdc 8.2T btrfs [22:19] └─sdc1 8.2T btrfs /srv/samba [22:20] parted sagt folgendes Number Start End Size File system Name Flags [22:20] 1 1049kB 4001GB 4001GB btrfs [22:22] lsblk gibt dateisystemtypen an [22:23] wenn man ihm sagt er soll sie anzeigen ja [22:23] lsblk -o name,size,fstype,mountpoint [22:24] genau, wenn du volume labels willst müsstest du dort LABEL hinzufügen [22:24] "dann hab ich noch eine partition die mit btrfs gelabeled ist" [22:25] volumelabel ist mir egal, mir geht es nur drum den fstype von sdb web zu bekommen, dort gibt es kein fs, nur auf sdb1 [22:27] lsblk zeigt also für sdb einen fstype anzeigt der nicht "disk" ist? [22:28] äh sorry, ich habe TYPE und FSTYPE verwechselt [22:29] passiert, ist schon spät ^^ [22:29] type für sdb ist korrekt disk, für sdb1 part [22:29] ist das nicht einfach nur ein label für die platte? [22:30] aber fstype für sdb ist "btrfs", ja? [22:32] ja, kommt von einem fail von mir mit mkfs.btrfs /dev/sdb. hatte dann noch mal mit parted eine partition angelegt, mkfs.btrfs /dev/sdb1 -f [22:33] also sdb hat tatsächlich kein filesystem, daher ist es nur mehr ein cleanup [22:37] hmm, das müsste dann ja irgendwo innerhalb der partitionstabelle oder den ersten blöcken gespeichert sein [22:39] wenns nicht anders geht zieh ich ein backup und mach das layout neu. dachte nur gibt vielleicht ein einfacheren weg [22:40] mir ist immer noch unklar welches tool mit welchem befehl das störende "btrfs" für sdb selbst (nicht sdb1, sdb2, ...) ausgibt. [22:41] lsblk gibt das aus [22:41] in welchem feld? [22:42] ah im feld FSTYPE für sdb, stimmt, das hatten wir schon [22:42] was ist wenn du das label mit btrfs einfach auf nichts setzt? [22:42] bin wohl wirklich zu müde [22:44] btrfs filesystem label /dev/sdc "" [22:44] oder so [22:44] würde aber vorher gucken, dass die backups taugen, bevor ich da anfange rumzuspielen :) [22:45] wipefs wäre da das tool der wahl um die dateisystemsignatur von sdb zu löschen [22:50] ich teste es mal mit wipefs. aber sicherheitshalber mit backup [22:50] der findet 3 signaturen, 2 mal gpt und ein mal pmbr [22:50] sdb 0x200 gpt [22:50] dann bringt das nichts. [22:50] sdb 0x3a3817d5e00 gpt [22:50] sdb 0x1fe PMBR [22:50] oder wird er die in ruhe lassen? [22:51] ist dann doch das falsche tool. [22:53] vielleicht schreibst du einfach mal die partitionstabelle neu [22:54] werd ich auch tun