Originally posted by tildearrow
View Post
Announcement
Collapse
No announcement yet.
Microsoft Teams Is Coming To Linux
Collapse
X
-
Originally posted by tildearrow View Post
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.
Idiotic concept.
- Likes 1
Comment
-
Originally posted by angrypie View PostReplacing 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.
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.
Comment
-
Originally posted by DoMiNeLa10 View PostWindows sticks way too hard to legacy stuff.
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.
Comment
-
Originally posted by Bsdisbetter View PostLOL 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.
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.
- Likes 1
Comment
-
Originally posted by fsfhfc2018 View PostOne 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?
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.
PSOC5 floppy disk imaging interface. Contribute to davidgiven/fluxengine development by creating an account on GitHub.
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.
- Likes 2
Comment
-
Originally posted by oiaohm View PostThat my problem with Devuan. They are spending resources maintaining solutions that don't work instead of focusing effort on openrc and the like.
They last for some time, and then they begin to rot.
Comment
-
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.
Seriously?
Idiot.
Comment
-
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.
The scale of idiocy on here knows no bounds, it seems.
Comment
Comment