1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Go - schnelle…
  6. Th…

Die Zukunft heist Managed Code !!!

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


  1. Re: Bitte lass der Technik doch ihren Namen.

    Autor: Newbe 12.11.09 - 10:47

    Alptraum schrieb:
    --------------------------------------------------------------------------------
    > > Damit meine ich .net und java.
    > Die Technik heißt Bytecode und nicht ManagedCode (oder wie auch immer)
    > Managedcode ist nur ein neuer Name, mit dem versucht wird fehlende
    > Innovation durch BWL-Taugliche Buzzwords zu ersetzen.
    In der .NET-Terminologie gelten alle Programme, die innerhalb der CLR laufen, also für .NET geschrieben wurden, als managed, alle anderen als unmanaged.
    .Net -> managed code bedeutet: läuft auf Bytecode
    .Net -> unmanaged code bedeutet: (wegen Mischung unterschiedlicher Sprachen) nicht nur als Bytecode

    Java -> Bytecode

    Managed ist ein MS-Buzzword.



    >
    > .Net wird Java nie ersetzen können. Ist nämlich einfach nur ein Me-Too mit
    > einer Klassenbiliothek mit Bloatware format.
    >
    > Und ich dachte von einem Fachinformatiker könnte man mehr Kompetenz
    > erwahrten.
    > So kann sich irren. Die scheinen wohl alle schon von MS indoktriniert
    > worden.

  2. Re: Bitte lass der Technik doch ihren Namen.

    Autor: Alptraum 12.11.09 - 11:11

    > Managed ist ein MS-Buzzword.

    Hab ich etwa was anderes behauptet? Nein! Also hättest du dir dein Kommentar sparen können.

  3. Re: Die Zukunft heist Managed Code !!!

    Autor: Erfahrung mit Java 12.11.09 - 11:26

    Newbe schrieb:
    --------------------------------------------------------------------------------
    > Der vielzitierte Geschwindigkeitsnachteil von Java
    > gegenüber C/C++ ist in keinster Weise nachvollziehbar. Ich kenne genug
    > aufwendige Java-Programme, die auf einem Pentium-III mit 500 MHz und 512 MB
    > Hauptspeicher effizient und schnell arbeiten.

    Dann hast du Java wahrscheinlich bisher nur unter Windows gesehen (falls es dort tatsächlich so schnell wie native Programme sein soll, bezweifle ich aber irgendwie).

    Unter Linux merkt man da schon einen deutlichen Unterschied, sowohl im Speicherverbrauch (unter 100-200 MB kommt man da kaum weg, selbst bei kleinsten Programmen) als auch wie schnell die Programme grundsätzlich reagieren. Die Prozessorlast ist selbst bei Dual-Core jenseits von gut und böse, und mein Rechner ist noch nicht so alt. Und wenn ich eine andere Java-VM als die von Sun nehme, sieht es noch schlechter aus. Also erzähl mir nicht, Java sei schnell :/

    > Java und .net sind wohl dann die ausgewählten Sprachen, wenn es um die
    > schnelle Umsetzung eines Projekts geht.

    Schnell erstellt vielleicht ja, vielleicht auch eine praktische Bibliothekensammlung dabei, aber dann hört es auch schon auf mit den Vorteilen. Sorry, aber Java habe ich schon immer nur als "Notlösung" gesehen, aber nie als vollwertigen Ersatz für native Programme. Ich brauche als Nutzer meine Resourcen andersweitig als dass bei jedem Programmstart erstmal das Universum im Hintergrund kompiliert wird oder dass die VM sie großzügig verbrät.

  4. Re: Bitte lass der Technik doch ihren Namen.

    Autor: mr. blabla 12.11.09 - 11:29

    > > So kann sich irren. Die scheinen wohl alle schon von MS indoktriniert worden.

    Und ich dachte von einem "richtigen" Informatiker kann man wenigstens eine gute Rechtschreibung erwarten.


    Natürlich kann .Net Java nicht ersetzen. Warum sollte es auch? Java läuft auf so vielen unterschiedlichen Plattformen dass es mittlerweile schwierig wird sie alle aufzuzählen.

    Microsoft ist nur an ihren eigenen Produkten interessiert. Deshalb läuft die MS-CLR auch nur unter MS-Produkten.

    Java ist cool wenn ein und das selbe Programm unter möglichst vielen Plattformen laufen soll. (z.B: der Oracle-Installer)

    Und zum Thema Speicher: Speicher ist nicht mehr so teuer wie er mal war. Wenn ihr so viel Angst um euren wenigen Speicher habt, kauft euch doch einfach noch ein paar Riegel!

    Hier mal die max Ram Werte von Windows 7 (64-Bit natürlich):
    Starter: 8GB
    Home Basic: 8GB
    Home Premium: 16GB
    Professional: 192GB
    Enterprise: 192GB
    Ultimate: 192GB

  5. Re: Bitte lass der Technik doch ihren Namen.

    Autor: Hm ... 12.11.09 - 11:56

    mr. blabla schrieb:
    --------------------------------------------------------------------------------
    > Und zum Thema Speicher: Speicher ist nicht mehr so teuer wie er mal war.
    > Wenn ihr so viel Angst um euren wenigen Speicher habt, kauft euch doch
    > einfach noch ein paar Riegel!

    Klar, wenn eine Software viel mehr verbraucht als sie soll, machen wir einfach die Augen zu und kaufen mehr RAM. Warum nicht gleich noch einen neuen Prozessor mit mehr Kernen dazu? Am besten noch ein paar zusätzliche Festplatten, wenn wir gerade dabei sind. Eine neue Grafikkarte wäre auch nicht schlecht, wieso eigentlich nicht gleich einen neuen Rechner? Sorry, aber das ist doch Mist!

    > Hier mal die max Ram Werte von Windows 7 (64-Bit natürlich):
    > Starter: 8GB
    > Home Basic: 8GB
    > Home Premium: 16GB

    Was, mehr nicht?

    > Professional: 192GB
    > Enterprise: 192GB
    > Ultimate: 192GB

    Das wäre wohl das mindeste :/

  6. Re: Java und Co

    Autor: Yannick 12.11.09 - 12:24

    MarkusS schrieb:
    --------------------------------------------------------------------------------
    > Nun haltet mal den Ball flach. Jede Programmiersprache hat ihre
    > Daseinsberechtigung. Ich habe schon Bildverarbeitungssoftware in Delphi und
    > C++ geschrieben, das sind einfach Aufgaben, an denen Java krepieren würde.
    > Die wichtigsten Routinen sind dabei mit MMX- und SSE-Befehlen in Assembler
    > umgesetzt und laufen systemabhängig bis zu einer Größenordnung (Faktor 10)
    > schneller als man es in Java je hinbekäme, das liegt in der Natur der
    > Sache. Ich habe aber ebenfalls schon wiederholt mit Javaprogrammen
    Leider beweißt du mit deinen Aussagen auch mehr als Unwissenheit.
    Auch mit Java kann man durchaus schnelle GUIs programmieren die ebenfalls schnelle Bildverarbeitungsoperationen durchführen.
    Als Beispiel seit z.B. die Quake Portation auf Java genannt die unter gewissen Umständen sogar mehr FPS als das C-Original hatte.

  7. Re: Bitte lass der Technik doch ihren Namen.

    Autor: Zingel 12.11.09 - 12:32

    mr. blabla schrieb:
    --------------------------------------------------------------------------------
    > Und zum Thema Speicher: Speicher ist nicht mehr so teuer wie er mal war.
    > Wenn ihr so viel Angst um euren wenigen Speicher habt, kauft euch doch
    > einfach noch ein paar Riegel!

    Es geht hier nicht darum, sich noch einen riegel zu kaufen.
    Mehr speicher bedeutet auch immer längere Ladezeiten, längere Zugriffszeiten, ...
    Garbage Collection? Super Idee. Aber man muss auch daran vorbei kommen. Was nutzt mir eine Garbage Collection, wenn ich mit Daten rumhantieren muss, die niemals in den Speicher passen könne, egal wie viele reigel ich drinnen habe? Natürlich gibt es z.B. weak-references, die Funktionierren in Java aber nicht so toll, dass man sich keine Gedanken um den Speicher machen braucht. Garbage-Collector selbst aufmuntern zum aufräumen? Ja, das geht. Macht das Programm aber so unsäglich langsam, und brint auch nicht viel.



    und ja, in Java kann man Applikationen sehr schnell entwickeln, vo allem verteilte Anwendungen. Dank JEE z.B. braucht man wirklich nur noch den Anwendungscode zu scheriben, und keinen Netzwerkcode oder sonstigen Stuss.
    Und? dafür habe ich auch in C++ Libraries. Dafür gibt es in jedem größeren Unternehmen mehrere! Leute, die sich nur noch ausschlißlich mit der Konfiguration von Applicationservern rumschlagen. Glaubt ihr nicht? Ich bin viele Jahre in solchen großen Unternehmen gewesen, als Java Entwickler. Und meine Absicht war es, zu Entwickeln. Aber irgendwann wurde der Konfigurationsaufwand immer größer. JEE, Struts, Hibernate. Alles besteht aus 3 Zeilen Code und 100 Zeilen Konfiguration. Das macht keinen Spaß.
    Jetzt bin ich wieder C++ Programmierer, und tue das, was ich mag. Programmieren!

  8. Re: Bitte lass der Technik doch ihren Namen.

    Autor: Alptraum 12.11.09 - 12:47

    OMG! Programmier doch in Assembler wenn du den Speichervernrauch über alles stellst.
    Es interessiert wohl wirklich niemanden, ob Java 1kb mehr verbraucht als C++, oder ob C++ Programmen einen geschwindigkeitsvorteil von einer Pikosekunde gegenüber Java haben.
    Desshalb, darf man sich aber bei C/C++ mit geniestreichen zugekiffter Entwickler rumschlagen.

  9. Re: Bitte lass der Technik doch ihren Namen.

    Autor: Zingel 12.11.09 - 12:54

    Alptraum schrieb:
    --------------------------------------------------------------------------------
    > OMG! Programmier doch in Assembler wenn du den Speichervernrauch über alles
    > stellst.
    > Es interessiert wohl wirklich niemanden, ob Java 1kb mehr verbraucht als
    > C++, oder ob C++ Programmen einen geschwindigkeitsvorteil von einer
    > Pikosekunde gegenüber Java haben.
    > Desshalb, darf man sich aber bei C/C++ mit geniestreichen zugekiffter
    > Entwickler rumschlagen.


    Ok. Mein letztes (mini) Projekt in Java: Eine riesige Datei mit vielen, vielen Datensätzen eines Kunden ( Produktivdaten von ca 3-5 GB ) einlesen, und darstellen.
    Dabei gab es eine Tabelle, in der alle Datensätze angezeigt werden sollten, und eine weitere Maske, in denen die Details der Datensätze angezeigt werden sollten. Das ganze geht natürlich niemals in den Speicher. Also schreibt man sich einiges an Unfug zusammen, damit nur die momentan sichtbaren Datensätze in der Tabelle im Speicher sind. Hat wunderbar funktioniert, solange man nur sehr wenige Datensätze auf- und Ab- gescrollt hat.

    In C++ hätte ich meinen Speicher einfach mit Free, bzw. Delete freigeben können. Geht in Java aber nicht.

    Aber jemand wie du denkt wahrscheinlich in zu kleinen Kategorien. Bloß weil du mal ein Progrämmchen geschrieben hast, weißt du, wovon andere reden. Klasse! Weiter so!

  10. Re: Die Zukunft heist Managed Code !!!

    Autor: user 12.11.09 - 19:09

    Wie wäre es damit: Die Zukunft heißt Koorporation !!!

    Ich selbst hatte die wahl entweder Java ODER C zu lernen.
    Und ich habe mich für C entschieden. Warum? Weil es mich an QBasic erinnerte...

    Wenn der Programmierer sehr schlampig arbeitet (goto) oder wichtige sicherheitsaspekte vergisst darf man der verwendeten Sprache nicht die Schuld geben.

    z.B. buffer [50][30][100] <---das ist vergleichbar mit Java ^^

    aber leute mal wieder zurück zum Thread...jeder hat eine eigene Meinung und soll er doch machen wie er möchte. der eine schreibt gern webapplikationen der andere programmiert lieber mit der w32api.

    jedem seins.

  11. Re: Java und Co

    Autor: Der Kaiser! 13.11.09 - 03:18

    > Auch mit Java kann man durchaus schnelle GUIs programmieren die ebenfalls schnelle Bildverarbeitungsoperationen durchführen.

    > Als Beispiel seit z.B. die Quake Portation auf Java genannt die unter gewissen Umständen sogar mehr FPS als das C-Original hatte.
    Quelle?

    ___

    Die ganz grossen Wahrheiten sind EINFACH!

    Wirkung und Gegenwirkung.
    Variation und Selektion.
    Wie im grossen, so im kleinen.

  12. Re: Die Zukunft heist Managed Code !!!

    Autor: Mister X 13.11.09 - 19:34

    @Alptraum so so du bist also ein echter Informatiker und kennst nichtmal den Unterschied zwischen .NET und JAVA
    Das was du als ByteCode bezeichnest ist nur ein zwischenschritt.
    Ich bin übrigens auch nuuuuuur ein Fachinformatiker. Hier für dich auf Englisch.

    When you compile a Microsoft.NET language, the complier generates code written in the Microsoft Intermediate Language (MSIL). MSIL is a set of instructions that can quickly be translated into native code.

    A Microsoft.NET application can be run only after the MSIL code is translated into native machine code. In .NET Framework, the intermediate language is complied "just in time" (JIT) into native code when the application or component is run instead of compiling the application at development time. The Microsoft.NET runtime consists of two JIT compilers. They are standard JIT compiler and the EconoJIT compiler. The EconoJIT compiler compiles faster than the standard JIT compiler, but the code it produces is not as optimized as the code obtained from the standard JIT compiler.

  13. Re: Die Zukunft heist Managed Code !!!

    Autor: Mister X 13.11.09 - 20:14

    Nochwas .net 2.0 Applikationen welche mit vb2005 erstellt wurden, laufen auch ohne neu Kompelierung mit mono unter Linux. Probiere es aus.

    Etwas schwieriger wird es wenn du auf das Dateisystem zugreigen möchtest. Jedoch lässt sich das mit einem einfachen select case abfangen.

    Jedem seine Programiersprache.
    .net ist übrigens Programmiersprachen unabhänig. (wenn mann sich auf gewisse normen einigt.)
    Ich kann problemlos in c# mit vb Klassen arbeiten und umgekehrt.
    Gerade desshalb ist .net auch für Große Projekte geeignet. Jeder Programmiert mit seiner Lieblingssyntax und alle sind fröhlich.

  14. Re: Bitte lass der Technik doch ihren Namen.

    Autor: GodsBoss 13.11.09 - 22:57

    > Ok. Mein letztes (mini) Projekt in Java: Eine riesige Datei mit vielen,
    > vielen Datensätzen eines Kunden ( Produktivdaten von ca 3-5 GB ) einlesen,
    > und darstellen.
    > Dabei gab es eine Tabelle, in der alle Datensätze angezeigt werden sollten,
    > und eine weitere Maske, in denen die Details der Datensätze angezeigt
    > werden sollten. Das ganze geht natürlich niemals in den Speicher. Also
    > schreibt man sich einiges an Unfug zusammen, damit nur die momentan
    > sichtbaren Datensätze in der Tabelle im Speicher sind. Hat wunderbar
    > funktioniert, solange man nur sehr wenige Datensätze auf- und Ab- gescrollt
    > hat.
    >
    > In C++ hätte ich meinen Speicher einfach mit Free, bzw. Delete freigeben
    > können. Geht in Java aber nicht.

    Auch da könnte man durchaus nur die sichtbaren Datensätze (und noch solche, von denen man vermutet, sie könnten als nächstes angeschaut werden) im Speicher belassen, indem man auf die anderen keine Referenzen mehr verweisen ließe, so dass sie vom Garbage Collector eingesammelt werden. Die Lösung dürfte der C++-Lösung wahrscheinlich gar nicht so unähnlich sein, nur dass man nichts explizit freigibt.

    > Aber jemand wie du denkt wahrscheinlich in zu kleinen Kategorien. Bloß weil
    > du mal ein Progrämmchen geschrieben hast, weißt du, wovon andere reden.
    > Klasse! Weiter so!

    Warum wurde eigentlich keine ordentliche Datenbank verwendet (hat natürlich nichts mit dem eigentlichen Problem zu tun, einer korrekt programmierten Lösung wäre egal, ob die Daten aus einer Datei, einer Datenbank oder der Nase des Benutzers entspringen)?

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  15. Re: Die Zukunft heist Managed Code !!!

    Autor: foo_bar 16.11.09 - 16:43

    BildschirmMensch schrieb:
    --------------------------------------------------------------------------------
    > >Das liegt daran, dass man bei Java auf unsigned-Typen verzichtet hat.
    > >
    > >*brauchen wir nicht, wurde gesagt!
    > >
    > >Nun wie speichert man effizient Zahlen im Bereich 0-255 (8bit)?
    > >-> Antwort natürlich mit short(16bit)!
    > Die "korrekte" Antwort lautet char, dieser Type entspricht nämlich genau
    > dem von dir genannten Wertebereich (8bit) (zumindest in C auf einem 32-bit
    > System)
    > Effizient mag das vielleicht vom Speicherplatz her sein, schneller ist aber
    > in den meisten Fällen auf einem 32-bit System auch ein 32-bit int.


    In Java ist ein char aber 16 bit… Einen 8 bit unsigned typ gibt es nicht in Java.

  16. Re: Die Zukunft heist Managed Code !!!

    Autor: GodsBoss 16.11.09 - 19:50

    > Ich selbst hatte die wahl entweder Java ODER C zu lernen.
    > Und ich habe mich für C entschieden. Warum? Weil es mich an QBasic
    > erinnerte...

    Schon verstanden, nur nichts Neues lernen. ;-)

    > Wenn der Programmierer sehr schlampig arbeitet (goto) oder wichtige
    > sicherheitsaspekte vergisst darf man der verwendeten Sprache nicht die
    > Schuld geben.

    Doch, darf man. Wie dumm müsste sich ein Java-Programmierer anstellen, um in eine Bildverarbeitungssoftware eine Sicherheitslücke einzubauen, bei der das Öffnen eines präparierten Bildes zum Ausnutzen reicht? In C reicht ein Buffer Overflow.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  17. Re: Die Zukunft heist Managed Code !!!

    Autor: TomTom 01.12.09 - 15:24

    Ja, dem stimme ich zu 100% zu! Java ist nicht nur ein schlechter Weg, ein Programm zu schreiben sondern gleichzeitig auch der lahmste! Kaum ein ernster wird sich mit dem lahmen Zeuch von Java Mist beschäftigen wollen (außer ein paar Zeilen im Studium) und kaum jemand hat bemerkt: Die Hochzeit von Java ist lange vorbei! Heute spielt Java nur in Nischenbereichen eine Rolle, sonst nirgens es ist O U T !

    Bei .NET kann man nur folgendes sagen:

    1. Mega lahmer Start der Anwendung
    2. Nur unsicherer Bytecode, der nur mit enormen Geldmittel halbwegs gesichert werden kann
    3. Ein enormer Resourcenverbrauch (siehe z.B. PowerShell ein Lacher schlechthin)
    4. Total überladene IDEs mit nutzlosen Funktionien, die z.B. ein normaler Entwickler kaum bruacht
    5. Insgesamt sehr viel langsamer als nativer Code da der Kram wie das veraltete Java in einer VM ausgeführt wird

    Ahc ja noch etwas: JEDES Java und .NET Programm kann zu 100% OHNE Probleme in den Ursprungsoce zurück gesetzt werden, ein natives Programm kann NICHT und zwar unter GAR KEINEN Umständen jemals dekompiliert werden, dies ist technisch NICHT möglich!

    Also Fazit: .NET/Java ist was für Bastler aber kaum ein grosses Unternehmen wird jemals mit .NET/Java arbeiten, ohne vorher tausende Euros in den Schutz der Programme zu investieren (und auch dann sind diese keineswegs sicher!)

    Die native Kompilierung ist:

    a) absolut sicher
    b) mit Abstand das schnellste, was es gibt
    und

    Ich hasse Java und den ganzen .NET Mist ist beides der grösste Blödsinn und wurde nur aus Bequemlichkeit erfunden (.NET ist ein Nachfahre von Java also der gleiche Schrott).

  18. Re: Die Zukunft heist Managed Code !!!

    Autor: DingsDa 01.12.09 - 15:43

    TomTom schrieb:
    --------------------------------------------------------------------------------
    > Ja, dem stimme ich zu 100% zu! Java ist nicht nur ein schlechter Weg, ein
    > Programm zu schreiben sondern gleichzeitig auch der lahmste! Kaum ein
    > ernster wird sich mit dem lahmen Zeuch von Java Mist beschäftigen wollen
    > (außer ein paar Zeilen im Studium) und kaum jemand hat bemerkt: Die
    > Hochzeit von Java ist lange vorbei! Heute spielt Java nur in
    > Nischenbereichen eine Rolle, sonst nirgens es ist O U T !
    >
    > Bei .NET kann man nur folgendes sagen:
    >
    > 1. Mega lahmer Start der Anwendung
    > 2. Nur unsicherer Bytecode, der nur mit enormen Geldmittel halbwegs
    > gesichert werden kann
    > 3. Ein enormer Resourcenverbrauch (siehe z.B. PowerShell ein Lacher
    > schlechthin)
    > 4. Total überladene IDEs mit nutzlosen Funktionien, die z.B. ein normaler
    > Entwickler kaum bruacht
    > 5. Insgesamt sehr viel langsamer als nativer Code da der Kram wie das
    > veraltete Java in einer VM ausgeführt wird
    >
    > Ahc ja noch etwas: JEDES Java und .NET Programm kann zu 100% OHNE Probleme
    > in den Ursprungsoce zurück gesetzt werden, ein natives Programm kann NICHT
    > und zwar unter GAR KEINEN Umständen jemals dekompiliert werden, dies ist
    > technisch NICHT möglich!
    >
    > Also Fazit: .NET/Java ist was für Bastler aber kaum ein grosses Unternehmen
    > wird jemals mit .NET/Java arbeiten, ohne vorher tausende Euros in den
    > Schutz der Programme zu investieren (und auch dann sind diese keineswegs
    > sicher!)
    >
    > Die native Kompilierung ist:
    >
    > a) absolut sicher
    > b) mit Abstand das schnellste, was es gibt
    > und
    >
    > Ich hasse Java und den ganzen .NET Mist ist beides der grösste Blödsinn und
    > wurde nur aus Bequemlichkeit erfunden (.NET ist ein Nachfahre von Java also
    > der gleiche Schrott).

    naja, recht haste :-) j java und net sind halt lahm und auch ich progge nicht damit, ist halt unsicher und lahm *ggg*

  19. Re: Die Zukunft heist Managed Code !!!

    Autor: TomTom 03.11.10 - 15:14

    Welcher Entwickler unter Windows nutzt den Java Scheiss??? Wasn das fürn Quatsch! Die Zukunft heisst nicht Managed Code Irrglaube rund 70% alller Applikationen sind im Jahr 2010 NICHT auf Managed Code basierend und auf Java Müll schon gar ned! Java ist mega lahm und bestenfalls fürs Handy gedacht. Das .NET Framework ist an einigen Stellen toll aber hat auch Nachteile:

    - kein Codeschutz möglich
    - umständliche Laufzweit Umgebung muss installiert werden
    - Im Vergleich zu nativen Code langsamer
    - keine Systemprogrammierung machbar

    Java und .NET das ich ned lache *ggg* C++ ist und bleibt die wichtigste Sprache hert doch mal langsam auf mit Eurem Java und .NET getue es gibt kaum Software, die den Kram wirklcih ernsthaft nutzt außer Otto Normal Progs kein Spiel, kein Office Paket, kein wichtiges Programm wurde jemals in C# oder gar Java Müll entwickelt.

    Gruss

  20. Re: Die Zukunft heist Managed Code !!!

    Autor: TomTom 03.11.10 - 16:13

    Java die Sprache für WebApps? Hör ich echt zum ersten mal! So ein Bullshit den Du da erzählst vielleicht auf Deinem Handy oder Eierfon nicht aber im Profibereich da ist PHP. ASP die erste Wahl aber nicht der Java Dreck!

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. itsc GmbH, Hannover
  2. PHOENIX Pharmahandel GmbH & Co KG, Fürth, Mannheim
  3. Automation W+R GmbH, München
  4. Hays AG, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 299,00€ (Bestpreis! zzgl. Versand)
  2. 555,55€ (zzgl. Versandkosten)


Haben wir etwas übersehen?

E-Mail an news@golem.de


HR-Analytics: Weshalb Mitarbeiter kündigen
HR-Analytics
Weshalb Mitarbeiter kündigen

HR-Analytics soll vorhersagbare und damit wertvollere Informationen liefern als reine Zahlen aus dem Controlling. Diese junge Disziplin im Personalwesen hat großes Potenzial, weil sie Personaler in die Lage versetzt, zu agieren, statt zu reagieren.
Ein Bericht von Peter Ilg

  1. Frauen in der IT Ist Logik von Natur aus Männersache?
  2. IT-Jobs Gibt es den Fachkräftemangel wirklich?
  3. Arbeit im Amt Wichtig ist ein Talent zum Zeittotschlagen

Indiegames-Rundschau: Der letzte Kampf des alten Cops
Indiegames-Rundschau
Der letzte Kampf des alten Cops

Rollenspiel deluxe mit einem abgehalfterten Polizisten in Disco Elysium, unmöglich-verdrehte Architektur in Manifold Garden und eine höllische Feier in Afterparty: Golem.de stellt die aktuellen Indiegames vor.
Von Rainer Sigl

  1. Indiegames-Rundschau Killer trifft Gans
  2. Indiegames-Rundschau Überleben im Dschungel und tausend Tode im Dunkeln
  3. Indiegames-Rundschau Epische ASCII-Abenteuer und erlebnishungrige Astronauten

Neuer Streamingdienst von Disney: Disney+ ist stark bei Filmen und schwach bei Serien
Neuer Streamingdienst von Disney
Disney+ ist stark bei Filmen und schwach bei Serien

Das Hollywoodstudio Disney ist in den Markt für Videostreamingabos eingestiegen. In den USA hat es beim Start von Disney+ technische Probleme gegeben. Mit Blick auf inhaltliche Vielfalt kann der Dienst weder mit Netflix noch mit Amazon Prime Video mithalten.
Von Ingo Pakalski

  1. Disney+ Disney korrigiert falsches Seitenverhältnis bei den Simpsons
  2. Videostreaming im Abo Disney+ hat 10 Millionen Abonnenten
  3. Disney+ Disney bringt seinen Streaming-Dienst auf Fire-TV-Geräte

  1. Red Dead Redemption 2 PC: Hohe Bildraten schaden nicht mehr der Gesundheit
    Red Dead Redemption 2 PC
    Hohe Bildraten schaden nicht mehr der Gesundheit

    Mit Updates versucht Rockstar Games, die technischen Probleme der PC-Version von Red Dead Redemption 2 zu lösen - inklusive eines kuriosen Fehlers bei hohen Bildraten. Die Entwickler haben eine Übersicht mit noch nicht korrigierten Bugs ins Netz gestellt.

  2. Auslandskoordination: Telekom dreht LTE an den Grenzen voll auf
    Auslandskoordination
    Telekom dreht LTE an den Grenzen voll auf

    Nach Vodafone nutzt jetzt auch die Telekom die Leistung ihrer LTE-Stadion an den Auslandsgrenzen. Während es bei Vodafone 50 Stationen waren, stellt die Telekom gleich 500 auf volle Leistung.

  3. Benzinpreis-Proteste: Internet in Iran bleibt weiter gesperrt
    Benzinpreis-Proteste
    Internet in Iran bleibt weiter gesperrt

    Seit mehreren Tagen ist das Internet in Iran nach blutigen Protesten weitgehend gesperrt. Nur fünf Prozent des normalen Traffics werden registriert.


  1. 17:44

  2. 17:17

  3. 16:48

  4. 16:30

  5. 16:22

  6. 16:15

  7. 15:08

  8. 14:47