Microsoft Teams Is Coming To Linux

[fsfhfc2018]

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.

Monitoring is difficult, though it seems like "init systems can't manage services" is a bit of a stretch. Surely that's only true in a certain (perhaps broad or conventional) context. I'm not entirely new to this sort of debate, though I won't pretend to be versed on every detail either.

[Bsdisbetter]

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.

LOL and how is that a bad thing? A service crashes for a reason, you might want to solve that before you let some other process continually attempt to restart it. Just saying.
Idiotic concept.

[Guest]

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.

That's the point. Windows sticks way too hard to legacy stuff. Plenty of things are old, and there are superior solutions in production. Windows uses a 26 year old file system (unless you pay a fortune for the workstation edition), and it's possible to install drivers that are over a decade old, and designed for Vista on the newest release without issues. Windows doesn't seem to understand that processors have their own cache, and doesn't try to assign processes to them in a way that remotely makes sense.

Considering how good Wine is these days, there isn't much software out there that explicitly requires use of Windows, and will probably allow for a better workflow when used via Wine. When that's not the case, there's virtualization, which is vastly superior with KVM. I simply can't find a good use for Windows these days.

[fsfhfc2018]

Windows sticks way too hard to legacy stuff.

One of the things that made me fall in love with GNU/Linux is that it doesn't drag people along from one fad to another. Take the floppy driver-- we are talking about an insignificant amount of code compared to other things, which basically never needs much maintenance. What's the advantage of creating more e-waste when Windows still supports the floppy?

And as long as you can buy computers that have floppies installed (I bought one this year, I admit, I wasn't trying to find one) what is the real advantage of deleting the driver? Separating it and making it not included by default I can appreciate-- smaller kernel that compiles faster. But just deleting it? Why?

The thing is, industries would love for us to just throw everything away all the time-- I read an article recently that lamented that people keep their phones for as long as 3 years.

I can appreciate if someone needs to upgrade more often than that. But it is incredibly destructive and wasteful (and expensive) to push that sort of feature churn onto everyone. Great for industry-- at the expense of everyone else. This stuff isn't free to produce, it isn't free to upgrade (and it isn't free to maintain, I understand that.) But surely there are needs other than those of the tech giants? Like the needs of say, everybody else? So baffled by the idea that we need to make everything disposable. Seems like a fallacy designed for profit, not sanity. But it's not my intent to disregard maintenance costs entirely. It just seems like there other important things they have to be in balance with, rather than have all else sacrificed to an idol of what the industry would prefer.

[oiaohm]

LOL and how is that a bad thing? A service crashes for a reason, you might want to solve that before you let some other process continually attempt to restart it. Just saying.
Idiotic concept.

No this you being narrow minded. Lets that the service that has just crashed happens to be an aircraft glass system. So while the service is crashed the pilot of the aircraft now crashes into the ground and you land at the pearly gates with him because you were onboard and you were the idiot who thought automatic restarting of services was a bad idea and disabled it.

So it really does depend what the service is.
Now lets do that aircraft one with sysvinit. You have a watchdog process that triggers because the glass system has not reported in and it tells sysvinit scripts to restart the glass. Problem PID tracking does not work so only part of the glass application gets shutdown now the pilot again has a black screen because the service will not start back up because part of that fail service is still running so stopping the new service starting. Again everyone on that aircraft die. This applies basically to all service management on Linux that is not using cgroups.

systemd will kind of work. That the restart will in fact work. Restarting ever 5 seconds if you can start up in 3 and render 1 frame of current data on a screen that holds output is in fact functional yes 12 frames per min.

Lot of the complaints about too much being in PID1 is true about systemd. Lot of this is caused by stupid things like one point in history with the Linux kernel to modify cgroups you had to be PID1 of course the code around cgroups has changed since then but systemd still has this legacy design crap. The reality here is current systemd is not matched to the current Linux kernel features. Systemd is matched to a historic version of the Linux kernel long gone.

Openrc with light PID1 process and reasonable service management design is looking very good just items like cgroup support is not fully completed.

Systemd is basically a prototype that shows what we can do. Not how we should do it. True init freedom should really be aiming to give uses the best possible init/service management solution for their system.

Min standard should be when you tell a service management to stop a service it in fact does completely stop that service anything that cannot do that is not worth having. That my problem with Devuan. They are spending resources maintaining solutions that don't work instead of focusing effort on openrc and the like.

Gentoo developers who started openrc I see as one of the true groups going after proper functional init freedom.

[tildearrow]

That's the point. Windows sticks way too hard to legacy stuff. Plenty of things are old, and there are superior solutions in production.

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

[oiaohm]

One of the things that made me fall in love with GNU/Linux is that it doesn't drag people along from one fad to another. Take the floppy driver-- we are talking about an insignificant amount of code compared to other things, which basically never needs much maintenance. What's the advantage of creating more e-waste when Windows still supports the floppy?

And as long as you can buy computers that have floppies installed (I bought one this year, I admit, I wasn't trying to find one) what is the real advantage of deleting the driver? Separating it and making it not included by default I can appreciate-- smaller kernel that compiles faster. But just deleting it? Why?

This is a interesting one. Linux kernel is removing the on motherboard floppy controller driver. Not the means to use a floppy drive completely. The USB floppy driver is remaining in the Linux kernel.

Interesting point is most common usages of the motherboard floppy driver controller has been hacking virtual machines.

Also you mention e-waste that is the big problem with floppy discs. http://hxc2001.free.fr/floppy_drive_emulator/ lot of devices that use to take floppy discs you will find a emulator replacement for the floppy drive. Disc images on fat formatted sd cards or usb flash drives instead of physical floppy discs. This is stage one.

Stage 2 is the fact the last new floppy disc was made in 2011. If you buy a box of so called new floppy discs today they have been sitting in a warehouse for at least 8 years now. So there is a finite supply of floppy discs left. As you use floppy discs you wear the surface leading to their doom. Yes your solid state storage uses less material to make and last longer. So from ewaste point of view sooner floppy is no more the better.

No new supply of discs with floppy drives. This now means the common thing you will be wanting floppy drive for is data recovery/imaging. The motherboard floppy controller is not designed for data recovery.

https://github.com/davidgiven/fluxengine

Yes there are speciality floppy controllers you buy/build to attempt to get data out your floppies. The specialist has way better odds of getting a correct read than motherboard controllers. Most of them are not using long cables but having the controller as close to the read head as possible to extract the cleanest analog read they can.

Really i cannot make a valid argument why you would be using a floppy disc using motherboard controller. If you are needing a floppy to boot a old system because of bios limitation you most likely should replace that drive with a solid state floppy drive emulator. That has your floppy images stored on sd card/flash drive so you don't need kernel motherboard floppy driver with that.

Every argument for why keep the motherboard floppy controller driver in Linux most ends in you should not be using it for that anyhow. So open up your wallet and spend the money you should and image your floppy discs while discs still in fact work.

I guess this is not the answer you were expecting.

[tildearrow]

That my problem with Devuan. They are spending resources maintaining solutions that don't work instead of focusing effort on openrc and the like.

This is the case for most anti-systemd distros. I once moved to Artix Linux (Arch Linux with OpenRC instead of systemd), and although it worked out for the first months, later there were big incompatibilities and delays that made me go back to normal Arch Linux with systemd.
They last for some time, and then they begin to rot.

[Bsdisbetter]

No this you being narrow minded. Lets that the service that has just crashed happens to be an aircraft glass system. So while the service is crashed the pilot of the aircraft now crashes into the ground and you land at the pearly gates with him because you were onboard and you were the idiot who thought automatic restarting of services was a bad idea and disabled it.

So it really does depend what the service is.
Now lets do that aircraft one with sysvinit. You have a watchdog process that triggers because the glass system has not reported in and it tells sysvinit scripts to restart the glass. Problem PID tracking does not work so only part of the glass application gets shutdown now the pilot again has a black screen because the service will not start back up because part of that fail service is still running so stopping the new service starting. Again everyone on that aircraft die. This applies basically to all service management on Linux that is not using cgroups.

systemd will kind of work. That the restart will in fact work. Restarting ever 5 seconds if you can start up in 3 and render 1 frame of current data on a screen that holds output is in fact functional yes 12 frames per min.

Lot of the complaints about too much being in PID1 is true about systemd. Lot of this is caused by stupid things like one point in history with the Linux kernel to modify cgroups you had to be PID1 of course the code around cgroups has changed since then but systemd still has this legacy design crap. The reality here is current systemd is not matched to the current Linux kernel features. Systemd is matched to a historic version of the Linux kernel long gone.

Openrc with light PID1 process and reasonable service management design is looking very good just items like cgroup support is not fully completed.

Systemd is basically a prototype that shows what we can do. Not how we should do it. True init freedom should really be aiming to give uses the best possible init/service management solution for their system.

Min standard should be when you tell a service management to stop a service it in fact does completely stop that service anything that cannot do that is not worth having. That my problem with Devuan. They are spending resources maintaining solutions that don't work instead of focusing effort on openrc and the like.

Gentoo developers who started openrc I see as one of the true groups going after proper functional init freedom.

What a lot of noise to say "Aircraft use Ubuntu so let's ensure we re-run failed startup scripts".
Seriously?
Idiot.

[Bsdisbetter]

This is the case for most anti-systemd distros. I once moved to Artix Linux (Arch Linux with OpenRC instead of systemd), and although it worked out for the first months, later there were big incompatibilities and delays that made me go back to normal Arch Linux with systemd.
They last for some time, and then they begin to rot.

Then why do you care so much? All this hate for anti-systemd is just as STUPID as the hate for systemd. Use what suits you and STFU about the rest. Choice is not something only you have.
The scale of idiocy on here knows no bounds, it seems.