1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Aufräumen von Prozessen beim…

Kein Bug, nur Kommunikationsproblem

  1. Thema

Neues Thema Ansicht wechseln


  1. Kein Bug, nur Kommunikationsproblem

    Autor: Sharra 30.05.16 - 15:18

    Es wurde geändert, und keiner hats gelesen. Das ist das Problem hier. Wenn mans wieder ändern kann, okay. Man hätte es aber auch einfach lassen können. Wer möchte, dass alles gekillt wird, kanns ja aktivieren.

  2. Re: Kein Bug, nur Kommunikationsproblem

    Autor: HiddenX 30.05.16 - 15:40

    Es ist aber das logische Verhalten. Warum sollte man eine Verbesserung zurückhalten um den 7 Leuten die sich dran stören nicht auf die Füße zu treten, sollen sie halt den Changelog lesen oder Googlen was das Problem ist. (Ja, sind vermutlich mehr als 7, aber dennoch ist das kein Grund ein logisches Verhalten nicht zu aktivieren nur weil einige Personen dann einen Config-Eintrag ändern müssen)



    1 mal bearbeitet, zuletzt am 30.05.16 15:42 durch HiddenX.

  3. Re: Kein Bug, nur Kommunikationsproblem

    Autor: Sharra 30.05.16 - 15:42

    HiddenX schrieb:
    --------------------------------------------------------------------------------
    > Es ist aber das logische Verhalten. Warum sollte man eine Verbesserung
    > zurückhalten um den 7 Leuten die sich dran stören nicht auf die Füße zu
    > treten, sollen sie halt den Changelog lesen oder Googlen was das Problem
    > ist.

    Ob es eine Verbesserung ist, liegt, voll und ganz, im Auge des Betrachters. Für manche ist es fraglos eine Verbesserung. Für andere ist es Schwachsinn.

  4. Re: Kein Bug, nur Kommunikationsproblem

    Autor: HiddenX 30.05.16 - 15:43

    Sharra schrieb:
    --------------------------------------------------------------------------------
    > Ob es eine Verbesserung ist, liegt, voll und ganz, im Auge des Betrachters.
    > Für manche ist es fraglos eine Verbesserung. Für andere ist es Schwachsinn.
    Sicher, aber dann sollte man abwägen welche Gruppe wohl größer ist. Und logisch betrachtet macht es eindeutig Sinn alles zu killen was ein User gestartet hat wenn er sich abmeldet.

  5. Re: Kein Bug, nur Kommunikationsproblem

    Autor: yoyoyo 30.05.16 - 15:55

    Es war ja auch vorher (nahezu) so, weshalb ja nun fast jeder Tmux oder Screen benutzt. Das ist nicht wegen der (höhö) tollen Oberfläche der Fall. Und den tmux daemon dann wieder an einen daemon ketten, der selbst wieder eine logind session für den Benutzer aufmacht .. hat mit KISS auf jeden Fall nichts zu tun.

    Scheint fast als würde man mit aller Macht versuchen sich den Zorn der Admins aufzuhalsen.

    Die Großzahl der professionellen (im Sinne von da arbeitet jemand mit) remote login sessions sollen weiter laufen, wenn die Verbindung (kurz) ausgeloggt wird oder einen Timeout erleidet. Das ist die ernsthafte und nicht theoretische Anforderung.

  6. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 16:01

    yoyoyo schrieb:
    --------------------------------------------------------------------------------
    > Es war ja auch vorher (nahezu) so, weshalb ja nun fast jeder Tmux oder
    > Screen benutzt. Das ist nicht wegen der (höhö) tollen Oberfläche der Fall.
    > Und den tmux daemon dann wieder an einen daemon ketten, der selbst wieder
    > eine logind session für den Benutzer aufmacht .. hat mit KISS auf jeden
    > Fall nichts zu tun.

    Nein, dass ist eine "das ging vor 30 Jahren schon so" Argumentation, die in die heutige Systemlandschaft nicht mehr reinpasst.

    Wer in einer eigenen Session laufen möchte (screen, tmux, etc) muss diese auch selbst aufbauen und nicht auf implizites Verhalten setzen.

    > Die Großzahl der professionellen (im Sinne von da arbeitet jemand mit)
    > remote login sessions sollen weiter laufen, wenn die Verbindung (kurz)
    > ausgeloggt wird oder einen Timeout erleidet. Das ist die ernsthafte und
    > nicht theoretische Anforderung.

    Ein Verbindungsabbruch ist etwas anderes als ein Logout. Und ein Logout sollte (muss) auch sein Session-Scope aufräumen; wer einen anderen Scope wünscht, muss entweder einen neue Session aufmachen (PAM, etc) oder dies dem Session Manager mitteilen.

  7. Re: Kein Bug, nur Kommunikationsproblem

    Autor: chseidel 30.05.16 - 16:46

    Nix da.

    Das erste gewünschte Verhalten ist eine Persistierung des Sessionzustandes über den Logout hinweg. Nur weil du dein Mobile ausschaltest, willst du nicht deine Chats - SMS, Whatsapp, whatever - gelöscht haben.

    Bevor man also ach so tolle "Das dient der logischen Geschlossenheit des Systembereiches X und verhindert theoretische Probleme die ein Großteil der Welt nicht hat" - macht, erstmal mit den Nutzern - hier Admins - reden!

    Das kommt in letzter Zeit bei den Entwicklern viel zu kurz!

    Dann hätte man gewusst, das viele Admins (Achtung, zweiter Use Case!) screen &al nutzen um ein länger andauerndes Kommando in Ruhe abzusetzen, um dann nach der verdienten Pause von einem anderen Ort(!) aus weiterarbeiten zu können.
    Oder trotz wackeliger Verbindung sinnvoll am System arbeiten zu können.
    So sieht die Praxis aus.

    Also, wenn ihr aufräumen wollt, bitte schön. Ich bin da ganz bei euch. Nur will ich weiterhin sinnvoll am System arbeiten können. Ohne Hirnverrenkungen.
    Was da gerade passiert ist wie eine Wahlwiederholung, die man vor dem Anruf anmeldemn muß.

  8. Re: Kein Bug, nur Kommunikationsproblem

    Autor: brainslayer 30.05.16 - 21:58

    Einen Daemon starten zu können ohne das er gekillt wird wenn man sich ausloggt ist ein Feature was nicht nur wenige benötigen, sondern Alle. ICH SAGE ALLE. Dieses Feature ist nutzlos und macht Linux kaputt. Damit ist es per definion ein Bug, weil dieses Verhalten so in Unixoiden Systemen nicht vorgesehen ist

  9. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 22:14

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > Dieses Feature ist nutzlos und macht Linux kaputt. Damit ist es
    > per definion ein Bug, weil dieses Verhalten so in Unixoiden Systemen nicht
    > vorgesehen ist

    Weil es bei Unix-Systemen traditionell kein Session-Management gegen hat. Dies wurde mit loginctl nachgerüstet und macht jetzt genau das was es soll:
    * Sessions sauber trennen
    * Resourcen zwischen den Sessions verwalten
    * Leftovers aufräumen

    Wenn ein Prozess als Service laufen soll, dann starte ihn einfach als Service, anstatt das implizite Verhalten auszunutzen, dass nach einem Doppel-Fork ein Prozess nicht mit seinem Urgroßvater getötet wird, wenn der Vaterprozess sich schon beendet hat.

  10. Re: Kein Bug, nur Kommunikationsproblem

    Autor: brainslayer 30.05.16 - 22:20

    hast du schonmal einen server betrieben? das ist ein komplett nutzloses feature und sorgt dafür das ein server nicht mehr server sein kann. ich log mich ein, starte meinen sql dienst neu. log mich aus. ups alles weg. son shit.
    leftovers gehören nicht augeräumt weil man sie mutwillig platziert hat. es sind keine leftovers. das problem ist das systemd gar nicht weis was leftovers sind und was nicht und killt einfach alles was ihm passt. sessions waren schon vorher sauber getrennt. und resourcen wurden auch schon immer zwischen sessions verwaltet. weil das systemd überhaupt nicht tut. resourcen verwaltet der kernel. systemd ist nichts weiter als eine gott applikation die am anfang gestartet wird und dir vorschreibt wie du dein system zu verwenden hast und zwar so und nicht anders und schon gar nicht so wie früher und erst recht nicht kompfortabel und angenehm. schon mal start/stop bootprozesse in systemd konfiguriert? du kriegst das kotzen

  11. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 22:40

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > hast du schonmal einen server betrieben? das ist ein komplett nutzloses
    > feature und sorgt dafür das ein server nicht mehr server sein kann. ich log
    > mich ein, starte meinen sql dienst neu. log mich aus. ups alles weg. son
    > shit.

    Du hast überhaupt nicht verstanden worum es geht.

    > leftovers gehören nicht augeräumt weil man sie mutwillig platziert hat. es
    > sind keine leftovers. das problem ist das systemd gar nicht weis was
    > leftovers sind und was nicht und killt einfach alles was ihm passt.

    systemd kill gar nichts, dass mache loginctl

    > sessions waren schon vorher sauber getrennt. und resourcen wurden auch
    > schon immer zwischen sessions verwaltet. weil das systemd überhaupt nicht
    > tut. resourcen verwaltet der kernel.

    Nein, Prozesse waren getrennt, aber eben keine Sessions (außer du definierst dir eine Shell als Session neu).

    Nicht jede Resource wird vom Kernel vollständig verwalten, e.g. audio Geräte. Woher soll der Kernel wissen welcher User jetzt auf welches Audio Gerät Zugriff hat? Wie schaut es mit Druckern, USB-Sticks (insbesondere an Servern, ... ja tun Leute), etc. aus

    Nur weil du vom Kernel das prinzipielle Recht zum nutzen einer Resource hast, heißt dies nicht, dass du immer darauf Zugriff hast.

    > systemd ist nichts weiter als eine
    > gott applikation die am anfang gestartet wird und dir vorschreibt wie du
    > dein system zu verwenden hast und zwar so und nicht anders und schon gar
    > nicht so wie früher und erst recht nicht kompfortabel und angenehm.

    systemd ist ein Prozessverwaltung, hat aber mit loginctl nicht viel zu tun.

    > schon
    > mal start/stop bootprozesse in systemd konfiguriert? du kriegst das kotzen

    100x mal besser als init.d Script voll von implizitem Verhalten und Shell Hacks *kotz*

    Wo ist das Problem? Einfach ein simples Template nehmen, im Zweifel per
    $ systemctl cat foo.service
    ein paar Beispiel ausgeben.

    ---------------->8--------------------- /etc/systemd/system/foo.service
    [Unit]
    Description=My Foo Server
    After=syslog.target
    After=network.target

    [Service]
    Type=simple
    User=service-foo
    Group=service-foo

    #ExecStartPre=/usr/bin/whatever-pre
    ExecStart=/usr/bin/my-service
    #ExecStartPost=/usr/libexec/whatever-post

    # Give a reasonable amount of time for the server to start up/shut down
    TimeoutSec=300

    # Place temp files in a secure directory, not /tmp
    PrivateTmp=true

    [Install]
    WantedBy=multi-user.target
    ----------------8<---------------------

    $ systemctl enable foo.service
    $ systemctl start foo.service
    $ systemctl status -l foo.service

  12. Re: Kein Bug, nur Kommunikationsproblem

    Autor: brainslayer 30.05.16 - 22:57

    das ist kein shellscript. sondern ein propertiäres config format. es erlaubt mir nicht zu tun was ich möchte sondern schreibt mir vor was ich darf. z.b. ein programm starten. aber ich habe das gefühl das ein bash script irgendwie damals mehr konnte. woher der kernel weis welcher user zugriff auf welches audiogerät hat? mmh anhand der uid und der guid die jedem prozess anhängt und bei jedem filezugriff mitgeführt wird. ahso und auch bei jedem ioctl und systemcall ist es möglich diesen zu ermitteln. alle zugriffe auf die peripherie gehen über den kernel und der kernel kennt die nutzer und gruppen id jedes prozesses der darauf zugreift. sorry. ich programmiere schon sehr lange mit an treibern im linux kernel genauso wie an anderen dingen die ihn betreffen. ich weis sehr gut wie er funktioniert. für rechtemanagement, resourcen und resourcenschutz, thema mmu, genauso wie rechte beim filesystemzugriff etc. das macht kein systemd. das macht der kernel. der verhindert das du auf dinge zugreifst wo du nix zu suchen hast. würde das system im userspace machen wäre das ein gewaltiges sicherheitsproblem. speicherschutz hat seine vorteile, desswegen läuft der kernel isoliert vom userspace, damit kein kaputtes programm ihn manipulieren kann (vorausgesetzt er hat keine sicherheitslücke)

  13. Re: Kein Bug, nur Kommunikationsproblem

    Autor: nille02 30.05.16 - 22:59

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > das ist kein shellscript.

    Zum Glück.

  14. Re: Kein Bug, nur Kommunikationsproblem

    Autor: brainslayer 30.05.16 - 23:03

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > brainslayer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > das ist kein shellscript.
    >
    > Zum Glück.
    spiel weiter mit deinem ubuntu und lass die profis ihre arbeit machen

    oder anders ausgedrückt. Tolles Argument Junge. Frei nach dem Motto ich weis gar nicht was ein shellscript ist und wofür man das braucht, desswegen muss es weg



    1 mal bearbeitet, zuletzt am 30.05.16 23:05 durch brainslayer.

  15. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 23:06

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > das ist kein shellscript.

    Das ist gerade die Idee hinter systemd ... nicht ein verfrickelts Shell Skript, welches außer dem Admin keiner (schnell) versteht, sondern ein klares Konfigurationsformat, welches auch mit dem Server nicht Vertraute schnell und zuverlässig analysieren können.

    > sondern ein propertiäres config format. es
    > erlaubt mir nicht zu tun was ich möchte sondern schreibt mir vor was ich
    > darf. z.b. ein programm starten. aber ich habe das gefühl das ein bash
    > script irgendwie damals mehr konnt.

    Klar kann ein Bash Script mehr, aber dies will man nicht.

    > woher der kernel weis welcher user
    > zugriff auf welches audiogerät hat? mmh anhand der uid und der guid die
    > jedem prozess anhängt und bei jedem filezugriff mitgeführt wird. ahso und
    > auch bei jedem ioctl und systemcall ist es möglich diesen zu ermitteln.
    > alle zugriffe auf die peripherie gehen über den kernel und der kernel kennt
    > die nutzer und gruppen id jedes prozesses der darauf zugreift.

    Darum geht es nicht, sondern darum wer diesen Zugriff konfiguriert und wie sich diese Konfigurationen (schnell) und zuverlässig überprüfen und nachvollziehen lassen.

    > sorry. ich
    > programmiere schon sehr lange mit an treibern im linux kernel genauso wie
    > an anderen dingen die ihn betreffen. ich weis sehr gut wie er funktioniert.
    > für rechtemanagement, resourcen und resourcenschutz, thema mmu, genauso wie
    > rechte beim filesystemzugriff etc. das macht kein systemd. das macht der
    > kernel. der verhindert das du auf dinge zugreifst wo du nix zu suchen hast.
    > würde das system im userspace machen wäre das ein gewaltiges
    > sicherheitsproblem. speicherschutz hat seine vorteile, desswegen läuft der
    > kernel isoliert vom userspace, damit kein kaputtes programm ihn
    > manipulieren kann (vorausgesetzt er hat keine sicherheitslücke)

    loginctl greif auf die Kernelfunktionen zurück, stellt in gewissen Sinne nur ein (sauberes) Interface dafür bereit.

    selbiges gilt für Systemd ... und Hand aufs Herz, wer hat in seinen Shell Script en schon ordentliche Container für alle Dienste definiert?

  16. Re: Kein Bug, nur Kommunikationsproblem

    Autor: nille02 30.05.16 - 23:08

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > > Zum Glück.
    > spiel weiter mit deinem ubuntu und lass die profis ihre arbeit machen

    Du bist drollig. Siehst du deine faulenden Felle davon schwimmen?
    Durch deine Einstellung und Arroganz schadest du GNU/Linux nur und bist vermutlich auch noch Stolz drauf.

    Aber wenn du ein Profi bist, dann ist es vermutlich schlimmer als alle denken.

  17. Re: Kein Bug, nur Kommunikationsproblem

    Autor: xUser 30.05.16 - 23:14

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > brainslayer schrieb:
    > ---------------------------------------------------------------------------

    > Aber wenn du ein Profi bist, dann ist es vermutlich schlimmer als alle
    > denken.

    Das ist (vermutlich) ein "Profi", der seine Init-Skripte immer so verbastelst, das außer ihm niemand den Server Administrieren kann. Das ist eine Form von Arbeitsplatzsicherung (macht unersetzlich).

    Ein klare und nachvollziehbar Konfiguration ist solchen Leuten ein Dorn im Auge, weil dann könnte ja jeder kommen und den Server administrieren.

    In Zeiten von systemd, docker & co schwimmen diesen Leuten natürlich die Felle davon ;)

  18. Re: Kein Bug, nur Kommunikationsproblem

    Autor: wasdeeh 31.05.16 - 10:11

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > hast du schonmal einen server betrieben? das ist ein komplett nutzloses
    > feature und sorgt dafür das ein server nicht mehr server sein kann. ich log
    > mich ein, starte meinen sql dienst neu. log mich aus. ups alles weg. son
    > shit.

    Oida. Nein, so funktioniert das nicht.
    Bitte mal in die Basics von Session-Management, loginctl etc. einlesen (oder schaun, wie's z.B. ein Windows-Server macht. Ja, tatsächlich.), bevor du hier so einen kolossalen Dunning-Kruger baust.

  19. Re: Kein Bug, nur Kommunikationsproblem

    Autor: chseidel 31.05.16 - 10:24

    xUser schrieb:
    --------------------------------------------------------------------------------
    > brainslayer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Dieses Feature ist nutzlos und macht Linux kaputt. Damit ist es
    > > per definion ein Bug, weil dieses Verhalten so in Unixoiden Systemen
    > nicht
    > > vorgesehen ist
    >
    > Weil es bei Unix-Systemen traditionell kein Session-Management gegen hat.
    > Dies wurde mit loginctl nachgerüstet und macht jetzt genau das was es
    > soll:
    > * Sessions sauber trennen
    > * Resourcen zwischen den Sessions verwalten
    > * Leftovers aufräumen
    >
    > Wenn ein Prozess als Service laufen soll, dann starte ihn einfach als
    > Service, anstatt das implizite Verhalten auszunutzen, dass nach einem
    > Doppel-Fork ein Prozess nicht mit seinem Urgroßvater getötet wird, wenn der
    > Vaterprozess sich schon beendet hat.

    [ ] Du weißt was Multics war und was Unix nie sein sollte.
    [ ] Du weißt, daß die Arbeit für die Tonne ist, weil Leute als erstes den Default ändern.
    [ ] Du weißt, daß das Kommunikationsproblem vor der Entwicklung stattgefunden hat.
    [ ] Du weißt, daß man mit relativ wenig Grundwissen und mit i. W. passiven Programmiersprachenkentnissen ein Unix verstehen und betreiben konnte. Jetzt muß man sich immer mehr überkandidelte Objektmodelle reinziehen, bevor man überhaupt irgendwas machen kann.

  20. Re: Kein Bug, nur Kommunikationsproblem

    Autor: wasdeeh 31.05.16 - 15:24

    chseidel schrieb:
    --------------------------------------------------------------------------------
    > xUser schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > brainslayer schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Dieses Feature ist nutzlos und macht Linux kaputt. Damit ist es
    > > > per definion ein Bug, weil dieses Verhalten so in Unixoiden Systemen
    > > nicht
    > > > vorgesehen ist
    > >
    > > Weil es bei Unix-Systemen traditionell kein Session-Management gegen
    > hat.
    > > Dies wurde mit loginctl nachgerüstet und macht jetzt genau das was es
    > > soll:
    > > * Sessions sauber trennen
    > > * Resourcen zwischen den Sessions verwalten
    > > * Leftovers aufräumen
    > >
    > > Wenn ein Prozess als Service laufen soll, dann starte ihn einfach als
    > > Service, anstatt das implizite Verhalten auszunutzen, dass nach einem
    > > Doppel-Fork ein Prozess nicht mit seinem Urgroßvater getötet wird, wenn
    > der
    > > Vaterprozess sich schon beendet hat.
    >
    > [ ] Du weißt was Multics war und was Unix nie sein sollte.

    Tjo, weiter brauchst du eigentlich nicht reden. Wenn das dein erstes (übrigens echt schon verdammt ausgelutschtes) "Argument" ist - warum verwendest du dann überhaupt noch systemd?

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Evangelische Landeskirche in Württemberg, Stuttgart
  2. Deutsche Rentenversicherung Bund, Berlin
  3. über duerenhoff GmbH, München
  4. Dataport, verschiedene Einsatzorte (Home-Office möglich)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. 3er Pack Lüfter LL120 RGB für 102,90€, Crystal 680X RGB Gehäuse für 249,90€)
  2. (u. a. 860 Evo 500 GB SSD für 74,99€, Portable T5 500 GB SSD 94,99€, Evo Select microSDXC 128...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Nitropad im Test: Ein sicherer Laptop, der im Alltag kaum nervt
Nitropad im Test
Ein sicherer Laptop, der im Alltag kaum nervt

Das Nitropad schützt vor Bios-Rootkits oder Evil-Maid-Angriffen. Dazu setzt es auf die freie Firmware Coreboot, die mit einem Nitrokey überprüft wird. Das ist im Alltag erstaunlich einfach, nur Updates werden etwas aufwendiger.
Ein Praxistest von Moritz Tremmel und Sebastian Grüner

  1. Nitropad X230 Nitrokey veröffentlicht abgesicherten Laptop
  2. LVFS Coreboot-Updates sollen nutzerfreundlich werden
  3. Linux-Laptop System 76 verkauft zwei Laptops mit Coreboot

Threadripper 3990X im Test: AMDs 64-kerniger Hammer
Threadripper 3990X im Test
AMDs 64-kerniger Hammer

Für 4.000 Euro ist der Ryzen Threadripper 3990X ein Spezialwerkzeug: Die 64-kernige CPU eignet sich exzellent für Rendering oder Video-Encoding, zumindest bei genügend RAM - wir benötigten teils 128 GByte.
Ein Test von Marc Sauter und Sebastian Grüner

  1. Ryzen Mobile 4000 (Renoir) Lasst die Ära der schrottigen AMD-Notebooks enden!
  2. HEDT-Prozessor 64-kerniger Threadripper schlägt 20.000-Dollar-Xeons
  3. Ryzen Mobile 4000 AMDs Renoir hat acht 7-nm-Kerne für Ultrabooks

Leistungsschutzrecht: Drei Wörter sollen ...
Leistungsschutzrecht
Drei Wörter sollen ...

Der Vorschlag der Bundesregierung für das neue Leistungsschutzrecht stößt auf Widerstand bei den Verlegerverbänden. Überschriften mit mehr als drei Wörtern und Vorschaubilder sollen lizenzpfichtig sein. Dabei wenden die Verlage einen sehr auffälligen Argumentationstrick an.
Eine Analyse von Friedhelm Greis

  1. Leistungsschutzrecht Memes sollen nur noch 128 mal 128 Pixel groß sein
  2. Leistungsschutzrecht Französische Verlage reichen Beschwerde gegen Google ein
  3. Leistungsschutzrecht Französische Medien beschweren sich über Google

  1. Made in USA: Glasexperte Corning und Qualcomm bieten 5G Small Cells
    Made in USA
    Glasexperte Corning und Qualcomm bieten 5G Small Cells

    Mit Corning und Qualcomm sind zwei US-Unternehmen im Bereich RAN aktiv, wie Trump es sich wünscht. Doch die 5G Small Cells arbeiten nur im Millimeterwellenbereich.

  2. 5G SA: Ausbau auf echte 5G-Leistung erfolgt mit Softwareupdate
    5G SA
    Ausbau auf echte 5G-Leistung erfolgt mit Softwareupdate

    Das bisherige 5G-Netz hängt noch stark von LTE ab. Wie sich das ändern lässt, wollten wir von den Ausrüstern genau wissen, weil 5G SA bereits eingesetzt wird.

  3. Youtube: Influencer mögen "Clickbait" nicht
    Youtube
    Influencer mögen "Clickbait" nicht

    Bekannte Influencer wie Unge, Dagi und Bibi nutzen laut einem Medienbericht die Filterfunktion von Youtube, um problematische Kommentare zu blockieren. Besonders unbeliebt sind Wörter wie "Clickbait" und "Fake".


  1. 19:41

  2. 17:39

  3. 16:32

  4. 15:57

  5. 14:35

  6. 14:11

  7. 13:46

  8. 13:23