Microsoft Teams Is Coming To Linux

[tildearrow]

Deleted Post

Yes, I can read and comprehend. Do you really think they let you revoke your school graduate documents here? No, right?

You know what? I'm not responding to you anymore. It is very clear you are a troll.

[Bsdisbetter]

That was one of many parts that are Ubuntu. That comms solution can be linked to the glass system and can be required to be up so the glass system behaves itself. Yes there are many glass systems that need to send there logs back to base. So com solution being down can be fatal.

This is not pure gold this is how stupid the things are with how complex we make control systems in aircraft these days. So the ubuntu system on coms restarting self and running long enough to receive and transmit off logs keeps systems on aircraft happy.

There are many locations where systems must restart and attempt to run even if they are broken because by running while broken they prevent other things from miss behaving. On a gerneral desktop not so much. In aircraft coms or aircraft control or cnc control kind of critical that restart stuff works.

In a word: nonsense.

[oiaohm]

In a word: nonsense.

No you want to call it nonsense so you can keep on the idea that items like sysvinit are good enough.

[Guest]

Maybe Windows does this for compatibility. Microsoft is excellent in this regard.

Considering that there is a superior way to get compatibility with old win32 software called Wine, I think they are doing it the wrong way. Windows 10 isn't great when it comes to compatibility with old software. You can't even run 16-bit software on 64-bit windows, where as Wine has a way to accomplish that.

[fsfhfc2018]

I guess this is not the answer you were expecting.

No, it's a lot smarter and more reasonable, and actually I didn't expect much of an answer at all. Thanks very much. Incidentally, I'm one of the people least happy with systemd but I appreciate a lot of the comments you've made about it-- originally noticed on Techrights IRC and also this forum-- I've waited years for a defense of it that is as reasonable as yours. We may not agree on everything but you're an unusually smart guy, oiaohm. You've got loads of perspective. Cheers.

[SystemCrasher]

Oh wow, its nearly 1st time in my life I see someone "banned" on phoronix.

p.s. as for systemd saga, I don't like some things about it, most notably, I guess it is time to split things like networkd and somesuch into some separate, optional projects (otherwise it becomes bloatware) - and it lacks modularity. However I can't readily propose how to do modularity in things like this. Sysv approach ignored plenty of management, reliability and security problems - so it isn't an answer. Say I like ability of systemd to watchdog critical processes via api. Same for its ability to sandbox processes and set most key parameters (user, priority, schedulers, limits ...).

[tildearrow]

Considering that there is a superior way to get compatibility with old win32 software called Wine, I think they are doing it the wrong way. Windows 10 isn't great when it comes to compatibility with old software. You can't even run 16-bit software on 64-bit windows, where as Wine has a way to accomplish that.

Yeah, I agree they've been doing it wrong lately, but Linux devs have always done worse until now. (or maybe not? I'm not that old to remember the first Linux distros)

[oiaohm]

Considering that there is a superior way to get compatibility with old win32 software called Wine, I think they are doing it the wrong way. Windows 10 isn't great when it comes to compatibility with old software. You can't even run 16-bit software on 64-bit windows, where as Wine has a way to accomplish that.

That is not exactly true that you cannot run win16 on windows 64 bit windows.

https://github.com/otya128/winevdm

its one of the more strange ports of the wine project code. You cannot run win16 on Windows 64 using the parts Microsoft provides but if you are willing to go third party you can.

[oiaohm]

p.s. as for systemd saga, I don't like some things about it, most notably, I guess it is time to split things like networkd and somesuch into some separate, optional projects (otherwise it becomes bloatware)

This is ignoring history. Sysvinit based distributions has a lot of third party parts in individual distributions you need. When systemd was started systemd lead developer went around attempt to contact all those upstream. Only about 1/4 of those up-streams in fact still had a maintainer. Some of those maintainers were in fact dead physically and no one had noticed. Others had changed jobs where they could not work on open source project any more. Part or the reason why systemd pulled so much into itself was to reduce this hit by bus problem by increasing the number of maintainers with project access.

I would recommend a different idea. Start automated testing building individual parts of systemd from systemd source code and getting more distributions making systemd more custom install-able.

systemd(collection) and coreutils(gnu) have a lot in common its all about making sure you have enough people who can maintain the code. Yes the animation of systemd eating different parts skips over how many of those parts systemd took in no longer had maintainer responding to bugs. Systemd project lead can be a jerk but its better than main sysvinit project where the project lead was missing for 4 years completely so you post bugs no answer at all. This was before systemd started. Yes this is one of the places where the person who was marked as responsible was in fact dead.

So one of the questions you have to answer is how are you going to maintain these projects and not end up with a key project bit rotting because there is no one to maintain it. Lot of people don't know how big of a disaster sysvinit world was. Yes people yelling about systemd taking in projects most of that taken was because that project no longer had a maintainer and no one less was stepping up for the job to take care of that project.

Systemd should have been a wake up call to work out the maintenance side because what was getting projects eaten by systemd was in fact maintenance problems.

[tildearrow]

That is not exactly true that you cannot run win16 on windows 64 bit windows.

https://github.com/otya128/winevdm

its one of the more strange ports of the wine project code. You cannot run win16 on Windows 64 using the parts Microsoft provides but if you are willing to go third party you can.

I think there is ntvdm64 as well.