Re: [gentoo-dev] Changing order of default virtual/udev provider
Sent from my Verizon Wireless BlackBerry -Original Message- From: Ben Kohler Date: Wed, 17 Feb 2016 08:01:32 To: Reply-to: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao wrote: > > > eudev has every commit scrutinized by people who care about using it on > Gentoo. systemd-udev does not. Consequently, eudev has avoided the system > boot breaking regressions that prompted its creation. That is a good reason > to make it the new default. If it fails to fulfill its duties, then this > could be revisited, but that should be unlikely. > > I think if someone could enumerate those specific breakages and present it as evidence, that could get more people on board for this change. Moreso than just "upstream doesn't care about us" or "eventually split udev will be impossible". -Ben
Re: [gentoo-dev] The Beauty of Unix
Pp Sent from my Verizon Wireless BlackBerry -Original Message- From: Gregory Woodbury Date: Wed, 10 Feb 2016 14:30:56 To: Reply-to: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] The Beauty of Unix I agree with Paul Varner's comment. There are places where a tight-coupling makes sense (the kernel) and places where it doesn't (system admin and userspace development.) My objections to the systemd plans is philosophical. There are some folks who want to make Linux into a Desktop System environment that works out of the box in the manner of Windows. There are reasons to do this, and there are reasons not to do this. On the one hand, to compete with MS Windows one must become MS Windows; on the other hand. doing that cuts deeply into the things that make Linux (and all the *NIX's) powerful and adaptable. When SysVInit was developed (circa 1981) there were serious limitations on the hardware it ran on in terms of speed and memory. Additionally, there were missing software algorithms and methods to solve some of the problems it had to deal with. A decision was made to punt some of the problems to a capable human mind rather than to spend precious time and resources trying to solve them computationally. This is, of course, the need for the admins to look at the services dependency graph and let them adjust the startup sequencing by hand. Hardware capabilities and software methods advanced quite fast and Sys V Init (being standardized) did not keep up with the times. Various extensions and replacements for the Init/startup methods were developed, and most added dependency descriptions and automatic solving to the mix, while trying to preserve the ease of using shell scripts for getting things done. OpenRC is one of the contenders and it is highly adaptable as new technologies are introduced (such as automatic device configuration a la eudev.) Systemd's method, though, rips out huge chunks of many different system components and replaced them with a monolithic structure that takes control of everything between the kernel's construction of the first process and the startup of the selected desktop environment. It also imposes strict interface requirements on the API of service daemon startup and which desktop environments it wants to support. The monolithic structure and resource requirements severely limit the hardware that can be used (to fairly recent amounts of memory and processor speed.) This, like Microsoft's methods, leaves a lot of not-so-old hardware out in the cold in a forced obsolescence. Additioinally, the development methods used, and the future plans for systemd, make it clear that its objective is to make a tighly integrated system that can compete with Microsoft in its own arena. [And don't get me started on the personalities involved!] I use systemd when required, and I can even tweak the internals when necessary. But for my own use, I much prefer the freedom to customize and construct things on my own. Perhaps I am and "old fogey" living in the past, but I think some other folks would object to that characterization. I have been involved in computing since 1958, and have made (and continue to make) some significant contributions to the field (even if my name is not publicly associated with them.) I have been in the trenches of (F)OSS for a long time and would love to see Linux+GNU in a significant number of non-technical users' hand and homes. However, I do not think that the only way to accomplish that is by becoming another Microsoft. This discussion should not be about which system is better or worse. There should be room in the concept space that preserves to ability to choose what a person wants on their machine, rather than having the environment dictated by some corporate entity looking to achieve market dominance. The "average users" these days have no concept of the magic behind the buttons on the screen and the keyboard, and most are just willing to consider the devices unrepairable when they fail and just go get another one. The advertising driven consumer culture really doesn't want the consumers' to know what is going on behind the scenes. but it still requires that some do know and can keep the infrastructure running and advancing. That is enough ranting for now. Carry on. -- G.Wolfe Woodbury redwo...@gmail.com
Re: [gentoo-dev] [RFC] Wine Project
Sent from my Verizon Wireless BlackBerry -Original Message- From: NP-Hardass Date: Thu, 31 Dec 2015 21:33:17 To: Reply-to: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Wine Project -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 31 Dec 2015 21:29:11 -0500 Andrew Udvare wrote: > > On 2015-12-31, at 17:03, NP-Hardass wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Mostly just a formality... > > > > Firing off an email RFC for the Wine Project[1]. The only purpose > > of this project is to maintain Wine and Wine related packages, > > taking over the place of the former Wine herd. > > Just saying, since Wine updates relatively infrequently compared to > bugs reported for newer apps, I would love to see more support for > the patched Wine versions somehow. > > https://github.com/wine-compholio/wine-patched in particular. > > Andrew > > Hi Andrew, We have wine upstream pushed updates almost biweekly. In addition, wine-patched is wine with the staging patchset already applied. We currently have that available to users via the "staging" use flag. If you have any other ideas of something that we might be missing, feel free to let us know. - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWheWCAAoJEBzZQR2yrxj7ql0QAJVMBEhJmTvRkGXGzf8wbbCj h/ri4r7Pb0IuVa+kcCzSLjS6JC3jOPa59pMe7kffKsSbI96YU+bfGoZj0jzctryp bRQ1GFFLU7Ndpfnz7ax1XrnVlxytEbJ37G4aAME8CIteXwFi85pjctU+oCz4LFVb FVVzKyniomk4M8u9NiTFCu8BuKm/hAuGAIHE+9WjWd+u2ousMG/GsSd2X9iZt6Ue 31SXRHFJ+GvfmyHXSw9QfWI/USfq8wMQ+cJ3GSVT0rW45DY8oNY2mi4U8O5NZ1I3 6ryTeM0M23Agc9xp2NX3HoXly2/lghaArZ2M5I9T/IscdPQnHLpOCqN1ZJx/aRAh oOoKxDTopeMPNGKpW4jz6IICNekL/e3azNakwUcvmQW5/KV4XMxFiZwJTIp9fOz5 OdH705vrFN3dkPueqGYnmmm/p5wY1M2m9yawIQjtb0nx3kbhCC9H7HiatV7zDn9l xBibI8TZ/hiWpobzbbjcOdMSAnHjk7jr3S6XLmcKhOfP72XY4dDrfcBscr5b6ysX AULyrd4I6hr2agaAS7IU0iKGpmAeUqGUnOfHBoZQXMM+m07nSWtLdReql0F2rar/ teFCqcsPBxbsQSLWtSTsYsFYQ8Z7UHD6WeWnofvrUsiVyATazi2KL3Sdk7Sdjik+ nh2tgv7QDxMjw4AgbwVZ =E/nt -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Wine Project
Q Sent from my Verizon Wireless BlackBerry -Original Message- From: NP-Hardass Date: Thu, 31 Dec 2015 21:33:17 To: Reply-to: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Wine Project -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 31 Dec 2015 21:29:11 -0500 Andrew Udvare wrote: > > On 2015-12-31, at 17:03, NP-Hardass wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Mostly just a formality... > > > > Firing off an email RFC for the Wine Project[1]. The only purpose > > of this project is to maintain Wine and Wine related packages, > > taking over the place of the former Wine herd. > > Just saying, since Wine updates relatively infrequently compared to > bugs reported for newer apps, I would love to see more support for > the patched Wine versions somehow. > > https://github.com/wine-compholio/wine-patched in particular. > > Andrew > > Hi Andrew, We have wine upstream pushed updates almost biweekly. In addition, wine-patched is wine with the staging patchset already applied. We currently have that available to users via the "staging" use flag. If you have any other ideas of something that we might be missing, feel free to let us know. - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWheWCAAoJEBzZQR2yrxj7ql0QAJVMBEhJmTvRkGXGzf8wbbCj h/ri4r7Pb0IuVa+kcCzSLjS6JC3jOPa59pMe7kffKsSbI96YU+bfGoZj0jzctryp bRQ1GFFLU7Ndpfnz7ax1XrnVlxytEbJ37G4aAME8CIteXwFi85pjctU+oCz4LFVb FVVzKyniomk4M8u9NiTFCu8BuKm/hAuGAIHE+9WjWd+u2ousMG/GsSd2X9iZt6Ue 31SXRHFJ+GvfmyHXSw9QfWI/USfq8wMQ+cJ3GSVT0rW45DY8oNY2mi4U8O5NZ1I3 6ryTeM0M23Agc9xp2NX3HoXly2/lghaArZ2M5I9T/IscdPQnHLpOCqN1ZJx/aRAh oOoKxDTopeMPNGKpW4jz6IICNekL/e3azNakwUcvmQW5/KV4XMxFiZwJTIp9fOz5 OdH705vrFN3dkPueqGYnmmm/p5wY1M2m9yawIQjtb0nx3kbhCC9H7HiatV7zDn9l xBibI8TZ/hiWpobzbbjcOdMSAnHjk7jr3S6XLmcKhOfP72XY4dDrfcBscr5b6ysX AULyrd4I6hr2agaAS7IU0iKGpmAeUqGUnOfHBoZQXMM+m07nSWtLdReql0F2rar/ teFCqcsPBxbsQSLWtSTsYsFYQ8Z7UHD6WeWnofvrUsiVyATazi2KL3Sdk7Sdjik+ nh2tgv7QDxMjw4AgbwVZ =E/nt -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Wine Project
Sent from my Verizon Wireless BlackBerry -Original Message- From: NP-Hardass Date: Thu, 31 Dec 2015 21:33:17 To: Reply-to: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Wine Project -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 31 Dec 2015 21:29:11 -0500 Andrew Udvare wrote: > > On 2015-12-31, at 17:03, NP-Hardass wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Mostly just a formality... > > > > Firing off an email RFC for the Wine Project[1]. The only purpose > > of this project is to maintain Wine and Wine related packages, > > taking over the place of the former Wine herd. > > Just saying, since Wine updates relatively infrequently compared to > bugs reported for newer apps, I would love to see more support for > the patched Wine versions somehow. > > https://github.com/wine-compholio/wine-patched in particular. > > Andrew > > Hi Andrew, We have wine upstream pushed updates almost biweekly. In addition, wine-patched is wine with the staging patchset already applied. We currently have that available to users via the "staging" use flag. If you have any other ideas of something that we might be missing, feel free to let us know. - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWheWCAAoJEBzZQR2yrxj7ql0QAJVMBEhJmTvRkGXGzf8wbbCj h/ri4r7Pb0IuVa+kcCzSLjS6JC3jOPa59pMe7kffKsSbI96YU+bfGoZj0jzctryp bRQ1GFFLU7Ndpfnz7ax1XrnVlxytEbJ37G4aAME8CIteXwFi85pjctU+oCz4LFVb FVVzKyniomk4M8u9NiTFCu8BuKm/hAuGAIHE+9WjWd+u2ousMG/GsSd2X9iZt6Ue 31SXRHFJ+GvfmyHXSw9QfWI/USfq8wMQ+cJ3GSVT0rW45DY8oNY2mi4U8O5NZ1I3 6ryTeM0M23Agc9xp2NX3HoXly2/lghaArZ2M5I9T/IscdPQnHLpOCqN1ZJx/aRAh oOoKxDTopeMPNGKpW4jz6IICNekL/e3azNakwUcvmQW5/KV4XMxFiZwJTIp9fOz5 OdH705vrFN3dkPueqGYnmmm/p5wY1M2m9yawIQjtb0nx3kbhCC9H7HiatV7zDn9l xBibI8TZ/hiWpobzbbjcOdMSAnHjk7jr3S6XLmcKhOfP72XY4dDrfcBscr5b6ysX AULyrd4I6hr2agaAS7IU0iKGpmAeUqGUnOfHBoZQXMM+m07nSWtLdReql0F2rar/ teFCqcsPBxbsQSLWtSTsYsFYQ8Z7UHD6WeWnofvrUsiVyATazi2KL3Sdk7Sdjik+ nh2tgv7QDxMjw4AgbwVZ =E/nt -END PGP SIGNATURE-
