No announcement yet.

Microsoft Teams Is Coming To Linux

  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Back on March 8, 2017, Microsoft announced they were working on Microsoft Teams for Linux and people could sign up to test it.

    On September 6, 2019 (912 days later), the update is they are working on it. We already knew that, they said it 912 days ago! What progress was made in those 912 days?!

    I think at this point it is more realistic that Microsoft will be honoring their promise of donating code from Silverlight v4 to the Moonlight project.

    Microsoft Teams for Linux will not be coming anytime Zune now.


    • #62
      Absolutely best article... for something like "crappy corporate newspaper" or so. Hey, when phoronix changes its name to zdnet?
      Last edited by SystemCrasher; 11 September 2019, 04:22 AM.


      • #63
        This is like learning the devil is coming to the sanctuary. I wish this announcement was in print form so I could wipe my ass with it.


        • #64
          Originally posted by starshipeleven View Post
          You have just been using the wrong applications I guess.
          I'm talking about things like file system performance, not software I can use there, as my preferred tools have native Windows ports.


          • #65
            Originally posted by DoMiNeLa10 View Post

            I'm talking about things like file system performance, not software I can use there, as my preferred tools have native Windows ports.
            Replacing Windows Defender with a lighter antivirus helps with I/O to an extent. You can't do much about the less-than-ideal multicore performance though.


            • #66
              Originally posted by oiaohm View Post

              Really Devuan case is simple

              This single line should be enough with Devuan to make you break down laughing. Most people don't see what the joke is. Its a stupid impossible statement

              Init systems portable does not equal secure. Why because coding portable means you don't use the host kernel features to be-secure.

              portable, compatible, small, fast would be possible. But lets go down Devuan init offering. Secure is wrong.

              sysvinit is based around pid files to tracking services and messaging. This is broken for process tracking due to PID recycling and why Linux has just added files for process ids for messaging. So sysvinit is insecure as it will at times kill the wrong process that might result in a DOS or equal problem. So this is insecure and broken.

              sinit has no service management so it cannot really start up a modern day server alone. The developer of that recommends Daemontools-encore this depend on posix set session (setsid) that does not in fact work exactly right on Linux because sid like pid can be recycled and processes can decide to change their own session id so disassociate themselves with parent so process leak. So that combination is insecure and broken. Of course deamontools-encore might be fixed once its basically just a front end for openrc. Question why not just use openrc then instead of having this???

              runit interest enough this is also exactly like the sinit/daemontools-encore only chance to fix this so proceses cannot leak from service management is integrate with openrc. So runit is another insecure option.

              openrc cgroup feature is not fully working. This feature is required to prevent openrc leaking service processes. Once openrc does work it will have sections in it configuration file that are not portable and will depend on Linux kernels newer than X versions. So far I have not found a single secure init included because there is not one. Yet Devuan goes head and claims bull crap.

              Not a single include init system that in fact is secure. The include one that could come secure is not going to remain portable.

              Lets look on the 2 on the consideration list of inits.

              s6 another one based on deamontools idea has the same deamontools fault that is fixed by integrating with openrc with cgroup support. Again why not just go with openrc???

              Shepherd from GNU could in fact work but its not include in Devuan at this time.

              Lets say we go with what is possible by dropping portable. compatible, small, fast and secure and we weed out the init systems Devuan to give what that promise. The result would be 2 competitor init systems. Openrc and Shepherd. After you have openrc working then you can revisit s6 and runit. sinit core pid1 is not smaller than the openrc one so it really make no sense and Deamontools-encore really needs openrc to work right.

              This is why Devuan is a joke its not Redhat people hating them. Its anyone who understand the state init systems know that the Devuan promise is bogus dangerous crap so they need to be threat like a joke. I will stop considering Devuan a joke once they get real and start promising what can be delivered.

              If Devuan developers were focused on init systems that could deliver openrc and shepherd might be something competitive right now.

              There is no point having lofty ideals with no way of achieving them. Worse is promising lofty ideals like Devuan and providing a false road to no where to achieve them.
              nice b8 Lennart, I can rel8


              • #67
                Originally posted by angrypie View Post

                Replacing Windows Defender with a lighter antivirus helps with I/O to an extent. You can't do much about the less-than-ideal multicore performance though.
                • Use gpedit.msc to turn off Windows defender (make sure to disable the anti-tamper bullshit in the settings too).
                • Use the application firewall to block everything other than firefox (inbound but most importantly outbound).
                Now your Windows has barely any thrashing. I know they say it isnt the case but the updates, telemetry and logs is very detrimental to hard disks. If you want a more extreme solution involving a VM as an "airgap"; check out my blog entry here:



                • #68
                  Originally posted by dovla091 View Post

                  tell us again, how many new devices are BSD supporting? or perhaps how many programs are made for that distro...?
                  Which 'bsd' are you referring to? You show your total ignorance (which makes you a great fit here) by referring to any *bsd as a 'distro'.


                  • #69
                    Originally posted by kpedersen View Post
                    All that is left then is to ridicule users rejecting it (such as IBM/RedHat is doing with the Devuan community) and then Microsoft is almost completely in control of consumer Linux.
                    Thanks for the welcome. It was all I needed to feel at home here. Cheers.


                    • #70
                      Originally posted by rmoog View Post

                      nice b8 Lennart, I can rel8
                      It's not bait. It is true that init systems can't manage services and hence if a service crashes, it won't recover and the service will be down until you decide to start it up again.