Software-update: Fan Control 157

Versie 157 van Fan Control is uitgekomen. Met dit programma, dat van het opensource-Libre Hardware Monitor-project gebruikmaakt, kunnen de ventilatoren in de computer worden beheerd en in de gaten worden gehouden. Zo is het onder meer mogelijk om met meerdere profielen en configuraties de computer koel of juist stil te houden. Fan Control kan overweg met de meeste fans en controllers, en via een plug-insysteem is dat verder uit te breiden. De changelog voor deze uitgave kan hieronder worden gevonden.

Changelog for version 157

• Add warning for InpOut
• Update LibreHardwareMonitorLib
• Small bug fixes

Versienummer	157
Releasestatus	Final
Besturingssystemen	Windows 10, Windows 11
Website	Fan Control
Download	https://github.com/Rem0o/FanControl.Releases/blob/master/FanControl.zip?raw=true
Licentietype	Freeware

Reacties (20)

[scholtnp]

Uit de LICENSE file van de github repository:

You may not modify, reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code of this software.

Ik dacht dat github voor open source projecten bedoeld was, maar dat is dit niet. Doet toch afbreuk aan het idee dat je hier kunt inspecteren wat je draait en er eventueel aan bij te dragen
Toch maar eens naar codeberg.org kijken.

[lenwar]

Nou ja... Niet dus.
De focus ligt er wel op, maar er staat nergens dat je er alleen open sourcesoftware in kan zetten. Je hebt zelf de keuze wat je publiek maakt en onder welke licentie je dat doet.

Men kan ook de code open en bloot publiceren, maar met een licentie dat niemand er wat mee mag doen. (( geen kopieën en zo maken dus, en dan even los van hoe makkelijk dat te controleren is ))

[scholtnp]

Als er steeds meer gesloten binaries op github komen te staan, heb je als gebruiker niet de mogelijkheid om te controleren of de code security vulnerabilities bevat. En dat maakt het voor mij minder interessant.

Men kan ook de code open en bloot publiceren, maar met een licentie dat niemand er wat mee mag doen.

Zelfs dat zou nog kunnen bijdragen aan de security, je kunt de auteurs dan nog waarschuwen mocht je iets verkeerds zien.
@MacPoedel Ik heb github altijd als dienstverlener gezien, een gesloten en onzichtbare repository waar je (als bedrijf) voor betaald leek me een correct verdienmodel. En ik vermoedde dat ze gebruikers aantrokken door open source gratis te hosten.

[lenwar]

heb je als gebruiker niet de mogelijkheid om te controleren of de code security vulnerabilities bevat

Ik denk dat dit voor ongeveer 100,0% (iets minder) van de gebruikers niet relevant is aangezien dat percentage niet daadwerkelijk de code zal doorspitten, of überhaupt de kennis in huis heeft om dit te doen.

Daarnaast kan je moeilijk controleren of de aangeboden software daadwerkelijk een compilatie is van de gepubliceerde code. Je zou uiteraard zelf kunnen compileren in plaats van de aangeboden voorgecompileerde software te gebruiken, maar gevoelsmatig zullen niet veel mensen dit doen. (misschien dat ik dit onderschat).

Maar goed. Even los van bovenstaande.
Github is primair een ontwikkelingsplatform/samenwerkingsplatform voor softwareontwikkeling. Het staat los van of je die code daadwerkelijk open publiceert (al is dat denk ik wel gebruikelijk?). Dat is aan de ontwikkelaar. De makers van dit programma hadden er ook voor kunnen kiezen om hun software op een ander platform beschikbaar te maken en (bijvoorbeeld) Github alleen 'intern' te gebruiken. Dan hadden we nooit het verschil gezien of waarschijnlijk zelfs niet eens geweten dat zij Github gebruiken.


Edit: Even ter volledigheid:
Ik vind open source als 'mechanisme' een heel goed idee. Je hebt iets gecreëerd en je geeft een stukje terug aan het publiek. Dit publiek kan dan geïnspireerd raken of geholpen worden om zelf ook mooie dingen te maken. Dit is denk ik gewoon goed. Ook kunnen mensen makkelijker (kleine) bijdrages leveren.
Als het gaat om beveiliging, denk ik dat open source als zodanig niet heel veel toevoegt. Op papier kan 'iedereen het controleren', maar in de praktijk zijn dat natuurlijk maar een relatief handje vol mensen die het 'kunnen', laat staan die het doen. Aan de andere kant van de medaille hebben we natuurlijk ook de kwaadwillenden die hiermee geholpen zijn. Zij kunnen een kwetsbaarheid vinden en die voor zichzelf houden. Het mes snijdt dus aan twee kanten.

Als we historisch kijken zien we dat er zelfs bij hele 'high level' open source projecten dat er jaren en jaren hele grote gaten aanwezig waren. (Projecten als OpenSSL). Gaten die al die tijd door 'het publiek' en zelfs 'auditors' gemist zijn. (( auditors staan natuurlijk los van open source )). Een aantal van die gaten waren al tijden bekend en misbruikt door kwaadwillenden. We zouden natuurlijk kunnen bediscussiëren dat die fouten dan misschien 'nog later' hadden gevonden en dat ze eventueel nog langer misbruikt hadden geworden, maar allicht hadden de misbruikers de fout dan zelf ook niet gevonden. Daar kunnen we denk ik in praktische zin niks over zeggen.

Dus nogmaals. Ik vind open source echt een goed idee en een mooi mechanisme, maar het hoeft van mij niet per se het doel te zijn.

[Reactie gewijzigd door lenwar op 23 juli 2024 04:04]

[MacPoedel]

Sorry maar het is wel ironisch dat je dit dan aandraagt over een Windows software.

Controleren op kwetsbaarheden in de beveiliging is een mooi argument voor open source software, maar gaat niet op voor 99% van de gebruikers die geen code lezen en is ook helemaal niet waterdicht gebleken. Het gaat ook nauwelijks op voor deze software want FanControl is niet veel meer dan een GUI voor LibreHardwareControl, als er al kwetsbaarheden zijn, zou je die daar verwachten en dat is een open source project.

Ik zou ook liever hebben dat dit een open source project was, in de eerste plaats dan omdat er dan meer garantie is op de verdere ontwikkeling dan wanneer het door één persoon gedragen wordt. Als Rem0o er nu mee stopt, sterft dit project gewoon.

Een heel groot deel van de downloads waar naar gelinkt wordt hier op Tweakers is closed source, ik zie het onderscheid er niet in dat dit nu gehost wordt op Github of elders.

[Jerie]

Controleren op kwetsbaarheden in de beveiliging is een mooi argument voor open source software, maar gaat niet op voor 99% van de gebruikers die geen code lezen

Het gaat er ook niet om dat de gebruiker dat kan doen, maar dat de gebruiker een onafhankelijke third party kan betalen om dat te doen.

en is ook helemaal niet waterdicht gebleken.

Met dit argument kun je de brandweer ook wel afschaffen.

[MacPoedel]

Ik denk dat audits effectiever zijn dan er op vertrouwen dat gebruikers zelf op kwetsbaarheden gaan controleren, wat wél scholtnp's argument was. Dat kan open source of closed source.

[Jerie]

Closed source audits, ja, dat kan. Het kan ook sneeuwen in Nederland in de zomer.

[MacPoedel]

Er staat in de readme van deze repository op Github dat dit alleen een release repository is en closed source software. Dat is helemaal geen probleem, Github is zeker niet alleen voor open source software, je kunt daar ook een private repository aanmaken die je met niemand of beperkt aantal personen deelt.

Als je overigens echt in code voor Fan Control wilt duiken, dit project maakt wel gebruik van een paar open source bibliotheken zoals LibreHardwareMonitor dus zo kun je wel bijdragen aan de code.

[Creesch]

Ik dacht dat github voor open source projecten bedoeld was, maar dat is dit niet.

Nee wat GitHub is, is het volgende

GitHub, Inc. (/ˈɡɪthʌb/[a]) is an Internet hosting service for software development and version control using Git. It provides the distributed version control of Git plus access control, bug tracking, software feature requests, task management, continuous integration, and wikis for every project.

Dit als commerciële dienst waar je als ontwikkelaar geld voor betaalt als je deze diensten wil gebruiken voor commerciële (gesloten) software (het is iets complexer, maar uitgebreid de prijsplannen van GitHub bespreken in een reactie is iets overdreven). Er zijn dan ook honderden bedrijven die hun code en ontwikkelprocess beheren via deze github diensten en waarvan jij nooit de code zal zien.

Dit is ook best logisch als je er iets langer bij stil staat, want GitHub moet ergens geld mee verdienen. Een dergelijk platform kan simpelweg niet bestaan zonder een vorm van inkomen.

Waar de verwarring bij jou vandaan zal komen is het feit dat de GitHub diensten ook gratis te gebruiken zijn als je repository ook open is. Op het moment dat je prive repositories wil met alle bijbehorende diensten moet je alsnog betalen.

Dit model maakt GitHub uitermate aantrekkelijk voor open source projecten aangezien de code daarvan sowieso publiekelijk beschikbaar moet zijn. Dat is dan ook de reden dat GitHub zo populair is bij dit soort projecten en men al snel denkt dat het alleen maar voor open source projecten is bedoelt. Maar dat is dus zeker niet zo.

[Reactie gewijzigd door Creesch op 23 juli 2024 04:04]

[guillaume]

Alternatief: https://github.com/lich426/FanCtrl

[pelidee]

Top software

[MiesvanderLippe]

Wow, dat hardware monitor project is echt een draak om te onderhouden lijkt me. Als ik zo de commits zie, zijn het individuele moederborden waarvoor ze ondersteuning toe moeten voegen...

[kid1988]

Yes, maar die LibreHardwareMonitorLib is ideaal voor ontwikkelaars van dit soort apps, een stabiele voorspelbare API..

Op dit soort interfaces is niet echt een standaard, vandaar dat iedere fabrikant zijn eigen RBG, fancontrol etc. apps heeft. Er zijn wel wat collabs tussen fabrikanten, maar het is echt droevig.

Meen me te herinneren dat de makers van OpenRGB zelfs issues hadden gehad dat ze bepaalde MSI moederborden konden bricken door de manier waarop ze de RGB aanstuurden.

[Reactie gewijzigd door kid1988 op 23 juli 2024 04:04]

[BramT]

Kan iemand een lichtje schijnen op hoe dit samenwerkt met aanwezige fancontrol software? Zaken als iCue e.d. kan je uitzetten natuurlijk, maar hoe zit het met de fancontrol van b.v. de AMD driver of BIOS?

[Aloys Riswick]

Kan problemen geven. Uit mijn ervaring de volgende 2 voorbeelden:

Bij Asus:
FanControl neemt prioriteit, je kan in ArmouryCrate FanStop aanzetten en dan werkt dat ook in FanControl, maar de rpm bij 100% in FanControl is nu ook een stuk lager dan wat de fan daadwerkelijk aankan.
eg: LianLi AL120 heeft normaal 2000 rpm op 100% maar als je FanStop aanzet in Armoury, dan draait hij nog maar op ~1000 rpm. Reden om FanStop aan te zetten is natuurlijk omdat niet alle fans uitgaan op 0% (en Asus heeft vgm ook een minimum fan speed?). Maar het werkt verder perfect.

Bij Asrock:
Asrock heeft fanstop in de bios (beter dan Asus dus), maar de Asrock fan curve in de bios vecht met FanControl. Om dit op te lossen heb ik de fancurve in de bios alle control points naar 0%/100 C gesleept. Het probleem was namelijk dat als je CPU een van de control points raakte van de bios curve, dat dan de bios curve weer overnam. Door alle control points naar 0% /100 C te slepen, raakt de CPU nooit meer een control point en werkt FanControl perfect. Nu is het wel zo dat de fans uitstaan terwijl windows opstart, maar dat is voor mij geen probleem. Je kan misschien nog een andere oplossing vinden zoals de curve in FanControl niet statisch maken, of "Force Apply" aanzetten. Misschien verhelpt dat ook het probleem

[BramT]

Komt er dus eigenlijk op neer dat de fans dat door 2 'processen' beheerd worden en dat je het andere proces zo min mogelijk (liefst geen) signalen wilt laten geven. Thanks voor de info!

[Imprezzion]

Ik gebruikte het op de ASUS B550-F en op de MSI B550 Unify-X ook om mijn radiator fans op GPU temperatuur te laten reageren bijvoorbeeld en heb een fan op de RAM zitten die ik met fancontrol op de DIMM temperatuur last reageren (met hwinfo64 plugin).

Op ASUS is er weinig incompatibiliteit en neemt fan control eigenlijk altijd de leiding wel ongeacht je BIOS instellingen. Ik had alles gewoon op defaults in de BIOS.

Op MSI echter is het zeer belangrijk dat de fans op alle headers in de BIOS op PWM staat en niet Auto en ook op een static snelheid. Dus ik heb alle punten in advanced control op minimale aantal graden staan en 20%. Anders loop ik er vaak tegenaan dat een fan niet meer reageert op fan control en blijft hangen op een bepaald percentage. Ook met force apply.

Zo lang je een static snelheid in je BIOS hebt en geen curve zou er dus weinig mis kunnen gaan.

Nu terug op een luchtgekoelde GPU en die fans werken overigens ook prima alleen zorg er wel voor dat bijvoorbeeld MSI Afterburner het vinkje voor user defined fan control uit heeft en beter nog fan control in MSI AB op static en gewoon een vast percentage. Anders krijg je daar wel problemen mee.

Zero fan mode werkt prima op de MSI Gaming X Trio 4070 Ti met fan control en de kaart reageert veel soepeler op fan control met custom ramp up enz. dan met b.v. MSI Afterburner. <45c GPU fans uit waarbij mijn bodem intake case fans ook reageren op GPU temperatuur via een eigen losse curve. Die zorgen ervoor dat de GPU rond de 38c blijft zonder dat de GPU fans draaien.

Ik heb nog nooit zo'n stille PC gehad in idle vooral en zelfs onder load dankzij de aanpasbare ramp up tijd en temp hysteresis is de overgang naar load ook veel soepeler en stiller.

[robiindonne]

hmm deze update verliep niet direct ok. Fans gaven aan op 26% te draaien terwijl ze op 35% zouden moeten staan en Manual control reageerde niet. Na opnieuw opstarten van de pc is alles ok.

[Reactie gewijzigd door robiindonne op 23 juli 2024 04:04]

[guillaume]

Wow, creepy ding: direct na de eerste setup (standaardinstellingen en met NvApiWrapper uit) wordt mijn hele PC abrupt uitgeschakeld. Verder nauwelijks lokaal iets over te vinden in event log e.d. fancontrol.sys driver wordt geïnstalleerd en boem, uit. https://github.com/Rem0o/FanControl.Releases/issues/1317 En als ik de honderden idioot vergaande issues zie op GitHub, dan raak ik dit ding echt niet meer aan, dat risico ga ik voor zo'n programmaatje echt niet nemen.

Gelukkig heb ik geen enkel probleem met https://github.com/lich426/FanCtrl

[Reactie gewijzigd door guillaume op 23 juli 2024 04:04]