Announcement

Collapse
No announcement yet.

Microsoft Teams Is Coming To Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by Bsdisbetter View Post
    What a lot of noise to say "Aircraft use Ubuntu so let's ensure we re-run failed startup scripts".
    Seriously?
    Idiot.
    http://linuxgizmos.com/compact-aircr...t-with-ubuntu/

    Ubuntu is serous-ally avionics OS that could be running the glass system that person flying the aircraft is depend on for information.

    This is not the only life or death example I could bring up that desktop Linux distributions get used with where a service not restarting even if will fail again will increase risk of fatality. I have seen it with linuxcnc where you need the service to restart know it crashed and stop the cnc machine from doing highly dangerous things. sysvinit failure to be able restart stuff with linuxcnc effectively resulted in taking out a key building support in one example I have seen. When you have Linux desktop distribution controlling a CNC with a 1.5 ton bit of metal on it adds a new side to dangerous. Again this is talking about using your normal off the shelf Ubuntu and Debian.

    There are times you need service management to work. Imperfect is better to not at all in a lot of cases. That linuxcnc is not perfect because they service will crash again due to ram fault or other issue the fact the service detect it had been incorrectly shutdown and restarted proceeds to put the system into safe stopped state.

    As I said you are narrow minded Bsdisbetter. So its kind of important that rerun failed functionality in fact works in something like Ubuntu. Also it would be good to have a nice way to disable rerun failed when it makes no sense.

    Desktop distributions are not just used for normal desktop workloads so what you require in service management needs to be quality or someone may die because service management is not quality.

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by dovla091 View Post

    I am showing ignorance? You Bozo need to compile program from a source code to match number of applications which are available for Linux, tell me again how big is your app repository and your community in comparison to let's say Debian? Second of all, name me one distro which has support for touch screen or fingerprint reader or similar on your BSD, except Apple crap ware? I wonder why I waste time on idiots...
    And how big is your Loonix community compared to Windoze? What stupid comparisons.
    Stop typing, you make an idiot look like a genius.

    Leave a comment:


  • dovla091
    replied
    Originally posted by Bsdisbetter View Post

    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'.
    I am showing ignorance? You Bozo need to compile program from a source code to match number of applications which are available for Linux, tell me again how big is your app repository and your community in comparison to let's say Debian? Second of all, name me one distro which has support for touch screen or fingerprint reader or similar on your BSD, except Apple crap ware? I wonder why I waste time on idiots...

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by tildearrow View Post

    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.

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by oiaohm View Post

    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.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by oiaohm View Post
    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by fsfhfc2018 View Post
    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.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by DoMiNeLa10 View Post

    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Bsdisbetter View Post
    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.

    Leave a comment:


  • fsfhfc2018
    replied
    Originally posted by DoMiNeLa10 View Post
    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.

    Leave a comment:

Working...
X