De Devschuur Coffee Corner - Iteratie ⓬

[mcDavid]

Janoz schreef op dinsdag 24 augustus 2021 @ 10:22:
[...]


1 uitzondering. Wiskundigen. Alhoewel.... Ipv langere namen te gebruiken pakken ze liever extra tekensets erbij.

Voor een wiskundige heeft een variable ook geen betekenis. Dus dat is ook weer niet zo gek.

[.oisyn]

Janoz schreef op dinsdag 24 augustus 2021 @ 10:22:
[...]


1 uitzondering. Wiskundigen. Alhoewel.... Ipv langere namen te gebruiken pakken ze liever extra tekensets erbij.

Check ook Bjarne's proposal voor overloading whitespace in C++ (met name het stukje "Overloading Missing Whitespace" vanaf p. 3)

[Janoz]

mcDavid schreef op dinsdag 24 augustus 2021 @ 10:50:
[...]


Voor een wiskundige heeft een variable ook geen betekenis. Dus dat is ook weer niet zo gek.

Euhm... x, y, z, i, p, N, Z, Q, R, C, π, etc etc

Zelfs functies
∑, ∏, ∫

[Immutable]

Janoz schreef op dinsdag 24 augustus 2021 @ 10:59:
[...]


Euhm... x, y, z, i, p, N, Z, Q, R, C, π, etc etc

Zelfs functies
∑, ∏, ∫

Kunnen we pi vergeten, en voortaan alleen tau gebruiken? sorry ben tau maximalist! Dus graag tau in base12 voor ultieme perfectie.

[Mugwump]

mcDavid schreef op dinsdag 24 augustus 2021 @ 10:50:
[...]


Voor een wiskundige heeft een variable ook geen betekenis. Dus dat is ook weer niet zo gek.

Ik heb als nietige informaticus toch altijd veel meer moeite om zaken te begrijpen als ze in abstracte Griekse symbolen worden gevangen dan wanneer er een betekenisvolle naam aan hangt.

[RayNbow]

.oisyn schreef op dinsdag 24 augustus 2021 @ 10:58:
[...]


Check ook Bjarne's proposal voor overloading whitespace in C++ (met name het stukje "Overloading Missing Whitespace" vanaf p. 3)

Juxtapositie

[.oisyn]

Janoz schreef op dinsdag 24 augustus 2021 @ 10:59:
[...]


Euhm... x, y, z, i, p, N, Z, Q, R, C, π, etc etc

Zelfs functies
∑, ∏, ∫

Dat zijn geen variabelen

[Koenvh]

.oisyn schreef op dinsdag 24 augustus 2021 @ 12:14:
[...]


Dat zijn geen variabelen

$x, $y, $z, $i, $p, $N, $Z, $Q, $R, $C, $π

Zo beter?
Ha, toch een PHP-grap

[Voutloos]

Gelukkig kan je in PHP prima zsm een mooie globale constante declareren: https://3v4l.org/duNBv

[Koenvh]

@Voutloos Alleen zo lastig met typen (of zit de pi op een azerty-toetsenbord? Ik kan 'm op m'n qwerty-toetsenbord niet vinden). Overigens wist ik niet dat pi in PHP 8 preciezer is geworden. Lijkt me enigszins onnodig.

[ Voor 25% gewijzigd door Koenvh op 24-08-2021 13:55 ]

[Woy]

.oisyn schreef op dinsdag 24 augustus 2021 @ 10:58:
[...]


Check ook Bjarne's proposal voor overloading whitespace in C++ (met name het stukje "Overloading Missing Whitespace" vanaf p. 3)

Hij heeft goede argumenten

This may seems Draconian at first . However, since we now have the full Unicode character set available,
we don't actually need hard-to-read long names. Such long names only make code obscure by causing
unpleasantly long lines and unnatural line breaks. Multi-character names are a relic of languages that
relied heavily on global name and encouraged overly-large scopes

Het voorbeeld met take phone of hook is ook erg verhelderend

[Voutloos]

Koenvh schreef op dinsdag 24 augustus 2021 @ 13:54:
@Voutloos Alleen zo lastig met typen (of zit de pi op een azerty-toetsenbord?

Code lezen is belangrijker dan schrijven.

Overigens wist ik niet dat pi in PHP 8 preciezer is geworden. Lijkt me enigszins onnodig.

Leuk leesvoer: https://www.jpl.nasa.gov/...-of-pi-do-we-really-need/
Dus PHP8 is precies de NASA definitie. PHP is dus goed genoeg voor ruimtemissies!!!!111

[Koenvh]

Voutloos schreef op dinsdag 24 augustus 2021 @ 14:05:
[...]
Code lezen is belangrijker dan schrijven.

[...]
Leuk leesvoer: https://www.jpl.nasa.gov/...-of-pi-do-we-really-need/
Dus PHP8 is precies de NASA definitie. PHP is dus goed genoeg voor ruimtemissies!!!!111

"Houston, we have a problem"
"error_reporting(0);"

[.oisyn]

Koenvh schreef op dinsdag 24 augustus 2021 @ 13:54:
Overigens wist ik niet dat pi in PHP 8 preciezer is geworden.

pi is niet preciezer geworden, in PHP8 worden blijkbaar meer digits afgebeeld.

.edit: Kijk maar

.edit2: Om precies te zijn, het is 7074237752028440 ∙ 2^-51

[ Voor 19% gewijzigd door .oisyn op 24-08-2021 14:46 ]

[Mschamp]

Koenvh schreef op dinsdag 24 augustus 2021 @ 13:54:
@Voutloos Alleen zo lastig met typen (of zit de pi op een azerty-toetsenbord? Ik kan 'm op m'n qwerty-toetsenbord niet vinden). Overigens wist ik niet dat pi in PHP 8 preciezer is geworden. Lijkt me enigszins onnodig.

De eenvoudigste manier die ik weet is via Alt+ 227 (echt een code om te onthouden )

[.oisyn]

Ctrl+\ p met mijn aangepaste keyboard layout. Zo doe ik ook ∞, ∙, √ enzovoorts

[armageddon_2k1]

Het is toch echt hilarisch. Weken is het topic een beetje rustig en 1x geklaag op PHP en we zijn weer een paar pagina's verder.



Anyway, iedereen alles al herschreven in Rust?

EDIT: Speaking of which....
Ik zei tegen iemand op Reddit dat Rust eigenlijk compile-time garbage collected was. Nou, dat was niet de bedoeling. Garbage collection is schijnbaar alleen maar voor heeeeeele trage unsafe talen!

[ Voor 50% gewijzigd door armageddon_2k1 op 24-08-2021 15:21 ]

[ElkeBxl]

armageddon_2k1 schreef op dinsdag 24 augustus 2021 @ 15:19:
Anyway, iedereen alles al herschreven in Rust?

Mijn The Rust Programming Language boek ligt hier stof te happen. Ik vind gewoon de tijd niet om ermee bezig te zijn

[Luc45]

Een rust boek kan toch geen stof happen, die gaat spontaan roesten bij weinig gebruik

[ElkeBxl]

Luc45 schreef op dinsdag 24 augustus 2021 @ 15:26:
Een rust boek kan toch geen stof happen, die gaat spontaan roesten bij weinig gebruik

[PrisonerOfPain]

armageddon_2k1 schreef op dinsdag 24 augustus 2021 @ 15:19:
Anyway, iedereen alles al herschreven in Rust?

Onze primaire codebase is 100% Rust (behalve wat native dependencies), no way dat ik nog naar C++ terug ga

EDIT: Speaking of which....
Ik zei tegen iemand op Reddit dat Rust eigenlijk compile-time garbage collected was. Nou, dat was niet de bedoeling. Garbage collection is schijnbaar alleen maar voor heeeeeele trage unsafe talen!

Die persoon mag zich wel ff in gaan lezen in de geschiedenis van Rust

[Hydra]

Oh noes! StackOverflow is down!

Ik ga maar naar huis.

[mcDavid]

Hydra schreef op dinsdag 24 augustus 2021 @ 16:05:
Oh noes! StackOverflow is down!

Ik ga maar naar huis.

Joke's on them! Ik was al thuis.

[RayNbow]

Mschamp schreef op dinsdag 24 augustus 2021 @ 14:54:
[...]


De eenvoudigste manier die ik weet is via Alt+ 227 (echt een code om te onthouden )

Ik schakel gewoon over naar Japans en typ pai<space>.

[Hydra]

mcDavid schreef op dinsdag 24 augustus 2021 @ 16:15:
Joke's on them! Ik was al thuis.

Ja hier was het ook een 'reis' van 30 seconden naar 2 verdiepingen lager

[Koenvh]

ElkeBxl schreef op dinsdag 24 augustus 2021 @ 15:25:
[...]

Mijn The Rust Programming Language boek ligt hier stof te happen. Ik vind gewoon de tijd niet om ermee bezig te zijn

Herkenbaar. Rust is een schitterende taal waarvan ik op dit moment geen idee heb wat ik ermee moet.

[Vihaio]

Veel meer dan Javascript heb je sowieso toch niet nodig?

[gekkie]

Urghh wat is toch die onweerstaanbare aantrekkingskracht van m'n buitenspiegels

[gekkie]

Koenvh schreef op dinsdag 24 augustus 2021 @ 17:32:
[...]

Herkenbaar. Rust is een schitterende taal waarvan ik op dit moment geen idee heb wat ik ermee moet.

Ik was er mee bezig, plan opgevat om er wat dingen met opencv in te klussen.
Maar goed dat is onofficiele autogenerated lib rond een bos unsafe c++ code en qua datastructures een dusdanige zoektocht dat dat is verzand. Maar misschien helpt het om iets minder ambitieus van start te gaan bij een herstart.

[ElkeBxl]

Ik was begonnen met paar AdventOfCode puzzels te proberen in Rust. En dan begonnen er andere dingen belangrijker te zijn in mijn leven en vond ik ook de goesting niet meer om er mee bezig te zijn

[Janoz]

.oisyn schreef op dinsdag 24 augustus 2021 @ 12:14:
[...]


Dat zijn geen variabelen

variables:
x, y, z, p

Constanten:
i, π

Sets (eigenlijk ook constanten):
N, Z, Q, R, C

Niet perse allemaal variabelen, maar zeker wel een paar

[OMX2000]

Probeer Rustlings : https://github.com/rust-lang/rustlings

Tip eerder gegeven herinner ik me. Maar doe ermee wat je wilt. Kun je op je gemak (nee niet rustig, want ha ha) Rust in rollen.

[Koenvh]

Janoz schreef op dinsdag 24 augustus 2021 @ 23:44:
[...]

variables:
x, y, z, p

Constanten:
i, π

Sets (eigenlijk ook constanten):
N, Z, Q, R, C

Niet perse allemaal variabelen, maar zeker wel een paar

Allemaal kunnen ze variabelen zijn, en allemaal kunnen ze constanten zijn. In de economie wereld staat π vaak voor de winst, en dan is het een variabele. Allemaal afhankelijk van de context

[RayNbow]

Haskell:

d = let  c = 4
         f = \x -> x * c
    in   f 1

Wat zijn c, d, f en x?

[Firesphere]

.oisyn schreef op dinsdag 24 augustus 2021 @ 15:18:
Ctrl+\ p met mijn aangepaste keyboard layout. Zo doe ik ook ∞, ∙, √ enzovoorts

Wut, allemaal onder Ctrl+\ p?

* Firesphere rent meh, te lui voor rennen

[Voutloos]

Die interpretatie kwam ook bij mij op. We blijven ontwikkelaars en dat is een onduidelijke specificatie.

Gelukkig wordt deze ernstige fout gecompenseerd door het feit dat .oisyn blijkbaar nooit print.

[ThomasG]

Voutloos schreef op woensdag 25 augustus 2021 @ 10:14:
Die interpretatie kwam ook bij mij op. We blijven ontwikkelaars en dat is een onduidelijke specificatie.

Gelukkig wordt deze ernstige fout gecompenseerd door het feit dat .oisyn blijkbaar nooit print.

Volgens mij zijn het Visual Studio-style shortcuts. Dus de combinatie CTRL-\, CTRL-P (na elkaar) voor π. Dus geen probleem bij het printen!

Op MacOS is het out-of-the-box gewoon Option-P

[.oisyn]

Nee, ctrl+\ is een dead key. Net zoals ctrl+" bij mij een dead key is om oa ë en ö te typen.

[mcDavid]

.oisyn schreef op woensdag 25 augustus 2021 @ 10:31:
Nee, ctrl+\ is een dead key. Net zoals ctrl+" bij mij een dead key is om oa ë en ö te typen.

Hoezo met ctrl ipv gewoon met altgr?

[.oisyn]

mcDavid schreef op woensdag 25 augustus 2021 @ 10:33:
[...]

Hoezo met ctrl ipv gewoon met altgr?

Sinds wanneer zijn dead keys "gewoon" met altgr?

[mcDavid]

Nouja altgr-deadkeys is gewoon een standaard toetsenbord indeling, die voor zover ik weet praktisch iedere coder gebruikt. Maar goed lekker doen wat je zelf gewend bent natuurlijk

[.oisyn]

mcDavid schreef op woensdag 25 augustus 2021 @ 10:37:
Nouja altgr-deadkeys is gewoon een standaard toetsenbord indeling, die voor zover ik weet praktisch iedere coder gebruikt.

Niet standaard op Windows, en https://github.com/thomasfaingnaert/win-us-intl-altgr bestond nog niet toen ik mijn eigen layout maakte, zo'n 15 jaar geleden

[ Voor 10% gewijzigd door .oisyn op 25-08-2021 10:44 ]

[mcDavid]

Dat zou kunnen, ik gebruik 'm pas 13 jaar (sinds ubuntu 8.10)

Edit: ohja bij windows moet je 'm nog steeds zelf installeren

[ Voor 34% gewijzigd door mcDavid op 25-08-2021 10:46 ]

[.oisyn]

Linux schminux

[Immutable]

armageddon_2k1 schreef op dinsdag 24 augustus 2021 @ 15:19:
EDIT: Speaking of which....
Ik zei tegen iemand op Reddit dat Rust eigenlijk compile-time garbage collected was. Nou, dat was niet de bedoeling. Garbage collection is schijnbaar alleen maar voor heeeeeele trage unsafe talen!

Dat is wel een hele vage manier van hoe men daar naar kijkt... Volgens mij klopt dat niet.

Ik zie Garbage Collection als een soort "programma". Add-On. Die in heel veel talen in een te diepe laag is gekomen.
Enige manier waar garbage collection gebruikt moet worden zijn voor bepaalde algoritmes die doormiddel van Garbage Collection sneller zijn dan zonder Garbage Collection.

Hiervoor heb je in Rust/C++/C de zogenaamde "arena's". Dus een stuk gealloceerd geheugen waarin deze algoritme zijn bewerkingen doet waar dus Garbage Collection actief is. Want sommige algoritmes zijn gewoon sneller met een GC.

Voor de rest als je een taal onderliggend al een GC bouwd, maak je een taal vanaf het begin al te specifiek en opinionated of iig teveel opinionated. Dat is ook de reden waarom Webassembly GEEN garbage collector heeft. En dat zal zo blijven ook. Daarom kun je GC talen ook niet zo makkelijk een output genereren naar Webassembly. Zie bijvoorbeeld C# Blazor waar je een complete C# runtime die weer draait op webassembly waarin weer je C# code draait. Superrrrr traag. (Geen wonder dat het flopt)

Ik zie persoonlijk een GC als een soort quickfix waar nog niet echt een goede oplossing voor is. En dat het nog een onopgelost probleem is. Daarnaast hebben veel GC talen moeite met fatsoenlijke multithreading i.v.m. met dat ze 1 GC hebben die 1 stuk geheugen moet beheren terwijl je meerdere CPU's hebben en dan moeten alle threads stoppen. (Sommige talen hebben dat al opgelost volgens mij, maar het beheren van geheugen met multithreading en GC's is gewoon een stuk lastiger als manueel.) En Rust zie ik daarin wel op dit moment de beste oplossing hebben. (Meest programmer friendly) Ook een GC taal zoals C# kan je hoofdpijn geven met unmanaged resources en wanneer je toch performance wil... Een GC taal betekend nog niet dat je minder met geheugen bezig bent als een manual memory taal. Sommige situaties krijg je alleen maar meer hoofdpijn.

[armageddon_2k1]

@Immutable
https://github.com/WebAss.../proposals/gc/Overview.md
https://bugs.chromium.org/p/v8/issues/detail?id=7748

GC voor WASM komt hoor ;-)

Maarreuh, in je uiteenzetting is het me niet duidelijk waarom Rust's memory management niet gezien kan worden als compile-time garbage collection.

[ Voor 30% gewijzigd door armageddon_2k1 op 25-08-2021 12:42 ]

[OMX2000]

armageddon_2k1 schreef op woensdag 25 augustus 2021 @ 12:41:
@Immutable
https://github.com/WebAss.../proposals/gc/Overview.md
https://bugs.chromium.org/p/v8/issues/detail?id=7748

GC voor WASM komt hoor ;-)

Maarreuh, in je uiteenzetting is het me niet duidelijk waarom Rust's memory management niet gezien kan worden als compile-time garbage collection.

Serieuze vraag. Want ik kan me er niks bij voorstellen. Maar wat is “compile-time” garbage collection?

[armageddon_2k1]

OMX2000 schreef op woensdag 25 augustus 2021 @ 13:25:
[...]


Serieuze vraag. Want ik kan me er niks bij voorstellen. Maar wat is “compile-time” garbage collection?

Nou, zoals ik het zie, en ik kan me voorstellen dat ik gecorrigeerd ga worden door misschien wat ervarener mensen, is als volgt.

In runtime garbage collection, zoals de algemeen bekende vorm is, is er een proces dat referenties bijhoudt naar objecten/memory allocaties. Op het moment dat een lading referenties naar een stuk memory 0 is wordt het memory vrijgegeven. Dit gebeurt alleen niet continue, maar in een garbage collection moment. De executie van het programma stopt en de garbage collector gaat opruimen en memory komt weer vrij. Dat werkt nogal goed en zorgt voor een fijne ontwikkelervaring als programmeur. Nadeel is dat de performance kan lijden omdat de GC runs niet echt deterministisch zijn en effectief je programma tegenhouden.

In Rust wordt memory ownership heel anders geregeld. De compiler dwingt een paar hele strakke regels af. Namelijk, er mag maar 1 owner zijn van een stuk memory die dat ook muteert maar dan mag er niemand zijn die het leest. Er mogen meerdere readers zijn van een stuk memory, maar dan mag er niemand het ownen om te schrijven. Daarnaast is er ook nog zoiets als 'move semantics' wat inhoudt dat de ownership van data/memory meegestuurt wordt. Data 'moved' dus echt naar een andere functie.

Iets als:

code:

fn foo(input: Box<u8>) {
    println!("{}", input);
}

fn main() {
    let x = Box::new(42u8); // moet hem boxen, want integers worden anders gekopieerd
    foo(x);
    
    // hier bestaat x niet meer
    println!("{}", x);
}

dat compiled dus niet, want 'x' is verplaatst naar foo. En nadat ie dus in foo gebruikt is kan ie weggepleurd worden, want niemand gebruikt het. Kijk maar:
https://play.rust-lang.or...6941719189f123e4cf3602ec0

Zodoende is de compiler dus aardig goed op de hoogte van welk memory op welk moment beschikbaar moet zijn. Daaruit volgt dat tijdens compile time dus al bepaald kan worden wanneer iets gedealloceerd kan worden. En dus hoeft dat niet tijdens runtime te gebeuren. En dat zou je dus kunnen zien als compile-time garbage collection.

Althans... zo zie ik het een beetje. Ik vermoed dat PrisonerOfPain er wel iets meer van weet dan ik.

Nu zijn er ook weer oplossingen in Rust die eigenlijk de ownership rules 'versimpelen' door reference counting aan te bieden. Maar dan kies je er echt voor. https://doc.rust-lang.org/std/rc/struct.Rc.html

Nou moet ik wel zeggen dat heel veel mensen op de Rust bandwagon springen en denken dat het zo veel bruter sneller is. Maar die vergeten wel even dat je prima razendsnelle apps kan maken in GC talen. Op het moment dat je 60fps moet halen in een zware game kan ik me voorstellen dat je optimaal gebruik wil maken van het memory gebruik. En die zullen ook al in C++ werken.

Maar voor 99% van de programmeurs die CRUD in een web-backend moet klussen..... mwoah.

[ Voor 15% gewijzigd door armageddon_2k1 op 25-08-2021 14:06 ]

[.oisyn]

Ik vind het persoonlijk een rare term. "Compile-time X" impliceert dat X tijdens het compileren gebeurt. Maar tijdens het compileren wordt geen garbage gecollect, dat gebeurt nog steeds tijdens runtime, alleen is het deterministisch. C# gebruikt de term "deterministic finalization" voor using-statements, en is vergelijkbaar met hoe C++ destructors en vziw ook Rust werkt met objecten die uit scope gaan.

[ThomasG]

.oisyn schreef op woensdag 25 augustus 2021 @ 14:24:
Ik vind het persoonlijk een rare term. "Compile-time X" impliceert dat X tijdens het compileren gebeurt. Maar tijdens het compileren wordt geen garbage gecollect, dat gebeurt nog steeds tijdens runtime, alleen is het deterministisch. C# gebruikt de term "deterministic finalization" voor using-statements, en is vergelijkbaar met hoe C++ destructors en vziw ook Rust werkt met objecten die uit scope gaan.

De manier van C++ is precies hoe Rust werkt. Wat voor veel misschien verwarrend is dat, wanneer je geen verwijzing doorgeeft, Rust standaard een C++ achtige std::move doet als het datatype de Copy-trait niet implementeert, en de variabele daarna dus niet meer "bestaat".

De feature waar armageddon_2k1 het denk ik over heeft is dat Rust compile-time de lifetime van verwijzingen controleert. In C++ kun je bijvoorbeeld (per ongeluk nog) een verwijzing hebben naar een stukje geheugen dat niet meer bestaat. Tenzij je flink knutselt met unsafe code, of dat er een bug in de compiler zit, kan dat niet in Rust.

[armageddon_2k1]

Nja, zoals ik al zei, zal ik wel gecorrigeerd worden

Deterministic garbage collection is een betere beschrijving ja.

[.oisyn]

ARGH #$%#^#@%@ schijt Visual Studio.

Ik heb een project, met een NuGet package als dependency, maar nu wil ik een stukje code in die package debuggen. Ik heb hier lokaal die sourcecode, maar ik krijg maar niet voor elkaar dat VS ook daadwerkelijk in die calls wil steppen

Nu heb ik dat project dan maar lokaal gebouwd en toegevoegd als dependencies, maar nog steeds wil hij er niet in steppen

[ Voor 18% gewijzigd door .oisyn op 25-08-2021 16:17 ]

[Gropah]

Immutable schreef op woensdag 25 augustus 2021 @ 12:35:
[...]
Daarnaast hebben veel GC talen moeite met fatsoenlijke multithreading i.v.m. met dat ze 1 GC hebben die 1 stuk geheugen moet beheren terwijl je meerdere CPU's hebben en dan moeten alle threads stoppen. (Sommige talen hebben dat al opgelost volgens mij, maar het beheren van geheugen met multithreading en GC's is gewoon een stuk lastiger als manueel.)

[...]

Er valt genoeg op Go te haten, maar de garbage collector is echt de moeite waard om in te duiken. Die heeft door de tijd geen best wel wat verbeteringen gehad (ookal heeft die ook zijn quirks). Deze talk geeft je een redelijk reis door de tijd heen

[thlst]

armageddon_2k1 schreef op woensdag 25 augustus 2021 @ 14:01:
In runtime garbage collection, zoals de algemeen bekende vorm is, is er een proces dat referenties bijhoudt naar objecten/memory allocaties. Op het moment dat een lading referenties naar een stuk memory 0 is wordt het memory vrijgegeven. Dit gebeurt alleen niet continue, maar in een garbage collection moment. De executie van het programma stopt en de garbage collector gaat opruimen en memory komt weer vrij. Dat werkt nogal goed en zorgt voor een fijne ontwikkelervaring als programmeur. Nadeel is dat de performance kan lijden omdat de GC runs niet echt deterministisch zijn en effectief je programma tegenhouden.

De grootste overhead komt van het collecten van circular refs. Maar die kun je uitzetten, zelfs in python met gc.disable() of in PHP met gc_disable()

[.oisyn]

.oisyn schreef op woensdag 25 augustus 2021 @ 16:11:
ARGH #$%#^#@%@ schijt Visual Studio.

Ik heb een project, met een NuGet package als dependency, maar nu wil ik een stukje code in die package debuggen. Ik heb hier lokaal die sourcecode, maar ik krijg maar niet voor elkaar dat VS ook daadwerkelijk in die calls wil steppen

Nu heb ik dat project dan maar lokaal gebouwd en toegevoegd als dependencies, maar nog steeds wil hij er niet in steppen

Blijkbaar was ie nog niet gerecompiled, dat fixte het step-in probleem. Maar nu kom ik in een oerwoud van missende assemblies tijdens runtime. Zucht

.edit: ok, een oplossing is niet om álles lokaal te bouwen (de assembly die ik wilde debuggen was een dependency van een dependency), maar alleen dat specifieke project dat je wil debuggen, en dan zorgen dat ie de juiste version number heeft. Dan kopiëer je de .dll en .pdb naar de betreffende installdir van nuget, en dan runt je solution uiteindelijk met de aangepaste assembly waar je gewoon doorheen kan steppen.

Ik zal wel een totale n00b zijn, maar dit werkt en ik kan weer verder

[ Voor 30% gewijzigd door .oisyn op 25-08-2021 17:26 ]

[ValHallASW]

.oisyn schreef op woensdag 25 augustus 2021 @ 16:49:
[...]
.edit: ok, een oplossing is niet om álles lokaal te bouwen (de assembly die ik wilde debuggen was een dependency van een dependency), maar alleen dat specifieke project dat je wil debuggen, en dan zorgen dat ie de juiste version number heeft. Dan kopiëer je de .dll en .pdb naar de betreffende installdir van nuget, en dan runt je solution uiteindelijk met de aangepaste assembly waar je gewoon doorheen kan steppen.

VS2019+ kan ook dependencies decompileren. Niet even goed als een echte source+pdb maar voor 99% van de use cases ook prima.

.oisyn schreef op dinsdag 24 augustus 2021 @ 15:18:
Ctrl+\ p met mijn aangepaste keyboard layout. Zo doe ik ook ∞, ∙, √ enzovoorts

Ha, grappig. Ik heb ooit met MS Keyboard Layout Creator een Griekse layout licht aangepast, en met wat tactisch ctrl-shift (switch layouts) kan ik dan schakelen tussen een normale layout en de Griekse.

[Koenvh]

Zo jongens, nog even snel een nieuwe versie uitrollen en dan hup het weekend in

[bwerg]

Immutable schreef op woensdag 25 augustus 2021 @ 12:35:
Ik zie Garbage Collection als een soort "programma". Add-On. Die in heel veel talen in een te diepe laag is gekomen.
Enige manier waar garbage collection gebruikt moet worden zijn voor bepaalde algoritmes die doormiddel van Garbage Collection sneller zijn dan zonder Garbage Collection.

En voor alles waarbij de performancewinst door handmatige memory management gewoon de moeite niet waard is ten opzichte van de moeite die het kost om het uit te programmeren. Afhankelijk van je programma toch al vaak 100% van je code. Anders moet je ook puristisch zijn en klagen dat een compiler je loop-unrolls niet perfect optimaliseert en gewoon handmatig assembly gaan schrijven, om het maar even tot in het extreme door te trekken.

Ik zou eerder stellen dat handmatige memory-management juist enkel gebruikt hoort te worden in gevallen waarin er essentiële performancewinst mee behaald kan worden. Dat kán natuurlijk een heel programma zijn, "Call of Duty 23: return of the jedi" zal niet zo lekker lopen met een garbage-collector erachter. Nooit minecraft gespeeld, maar dat schijn performance-technisch relatief niet heel lekker te lopen.

[ Voor 10% gewijzigd door bwerg op 27-08-2021 15:53 ]

[Hydra]

armageddon_2k1 schreef op woensdag 25 augustus 2021 @ 12:41:
Maarreuh, in je uiteenzetting is het me niet duidelijk waarom Rust's memory management niet gezien kan worden als compile-time garbage collection.

Tja. Er is al een term voor; RAII. Ik denk dat je met dat soort teksten eerder verwarring brengt dan iets duidelijker maakt.

"Garbage collection" is natuurlijk vooral iets 'anders' dat jouw shit opruimt. RAII betekent weinig anders dat jij beloofd dat wat je aanmaakt ook weer weggooit. Rust dwingt dat af op compile time. Maar dat vind ik ook gewoon niet hetzelfde als GC, tenzij je eigenlijk alle geheugendeallocatie op een grote "GC" hoop gooit.

[farlane]

bwerg schreef op vrijdag 27 augustus 2021 @ 15:39:
En voor alles waarbij de performancewinst door handmatige memory management gewoon de moeite niet waard is ten opzichte van de moeite die het kost om het uit te programmeren.

Misschien (het gaat overigens niet alleen maar om memory), maar wat nou als er een taal bestaat die zorgt dat je afval automatisch opgeruimd wordt *en* retegoed performed?

[Koenvh]

farlane schreef op zaterdag 28 augustus 2021 @ 20:01:
[...]


Misschien (het gaat overigens niet alleen maar om memory), maar wat nou als er een taal bestaat die zorgt dat je afval automatisch opgeruimd wordt *en* retegoed performed?

Zoek je een soort hulp in de huishouding voor programmeertalen?

[.oisyn]

ValHallASW schreef op woensdag 25 augustus 2021 @ 20:01:
[...]

VS2019+ kan ook dependencies decompileren. Niet even goed als een echte source+pdb maar voor 99% van de use cases ook prima.

Het punt is niet de sourcecode, want die heb ik. Het punt was dat VS er niet doorheen wil steppen, want ik heb geen .pdb zonder zelf te compilen .

Hydra schreef op vrijdag 27 augustus 2021 @ 16:01:
[...]


Tja. Er is al een term voor; RAII. Ik denk dat je met dat soort teksten eerder verwarring brengt dan iets duidelijker maakt.

Maar RAII is niet de term voor deterministich finalization. Het stelt slechts dat de binding met een resource een class invariant is; de resource wordt gehouden zolang een object bestaat. Het wordt typisch natuurlijk wel toegepast met scoped object lifetimes.

[ Voor 39% gewijzigd door .oisyn op 30-08-2021 13:28 ]

[ValHallASW]

.oisyn schreef op maandag 30 augustus 2021 @ 13:17:
[...]

Het punt is niet de sourcecode, want die heb ik. Het punt was dat VS er niet doorheen wil steppen, want ik heb geen .pdb zonder zelf te compilen .

Dat snap ik Dat neemt niet weg dat in het geval van eigen NuGet packages nog steeds meestal voor de decompilatie-optie ga, omdat 'decompileer het maar en zet in de decompiled source een breakpoint' een stuk sneller werkt dan 'git checkout, bouwen, hannesen met pdb-files'.

[.oisyn]

@ValHallASW ah dat werkt dus wel out of the box, een breakpoint plaatsen in gedecompileerde code?

[Mercatres]

.oisyn schreef op maandag 30 augustus 2021 @ 22:01:
@ValHallASW ah dat werkt dus wel out of the box, een breakpoint plaatsen in gedecompileerde code?

Voor zover ik weet wel, al durf ik niet 100% zeker te zeggen dat dat ook niet door ReSharper komt. Maar ik denk dat het een native VS2019 feature is.

[R4gnax]

.oisyn schreef op woensdag 25 augustus 2021 @ 16:49:
[...]


Blijkbaar was ie nog niet gerecompiled, dat fixte het step-in probleem. Maar nu kom ik in een oerwoud van missende assemblies tijdens runtime. Zucht

Welkom in package debugging hell.
Pas op je bloeddruk.

Even serieus nu:
Check of het package wat je wilt debuggen Source Link ondersteuning heeft.
Als het dat heeft, kun je de support in Visual Studio aanzetten en trek je de remote source gewoon on-demand binnen. Dit is echt stevig verbetert ten opzichte van het oude 'source server' gebeuren of NuGet symbol packages.

Als je de source van het package hebt, maar het niet voor Source Link ingesteld is:
zelf even compilen met die ondersteuning er in en je gewijzigde versie (met hetzelfde package ID maar een hoger patch versie nummer!) in gebruik nemen door deze als 'upgrade' in het project te installeren waar je wilt debuggen.

[ Voor 16% gewijzigd door R4gnax op 31-08-2021 09:00 ]

[.oisyn]

@R4gnax Blijkaar staat Source Link standaard aan, en 'Enable Just my code' stond uit. Aangezien ik er dus niet in kon steppen ga ik er vanuit dat de package geen source link info heeft

[PrisonerOfPain]

armageddon_2k1 schreef op woensdag 25 augustus 2021 @ 14:01:
Althans... zo zie ik het een beetje. Ik vermoed dat PrisonerOfPain er wel iets meer van weet dan ik.

Lang, lang geleden had Rust gewoon een runtime garbage collector (via `@` / `Gc<T>`). https://github.com/rust-l...d#version-0120-2014-10-09 / https://gist.github.com/Manishearth/70856e2f01e18935681c

Over tijd is 't er uit gehaald toen de focus meer op systems level development kwam te liggen.

Verder is 't wat mij betreft niet super boeiend hoe je "compile time GC" noemt, of 't nu echt een GC is of niet. Uiteindelijk kun je er flink over gaan ziften en er nog niet uit komen. Het is wmb gewoon shorthand om uit te leggen wat er aan de hand is.

bwerg schreef op vrijdag 27 augustus 2021 @ 15:39:
[...]
En voor alles waarbij de performancewinst door handmatige memory management gewoon de moeite niet waard is ten opzichte van de moeite die het kost om het uit te programmeren. Afhankelijk van je programma toch al vaak 100% van je code. Anders moet je ook puristisch zijn en klagen dat een compiler je loop-unrolls niet perfect optimaliseert en gewoon handmatig assembly gaan schrijven, om het maar even tot in het extreme door te trekken.

Ondanks dat klagen over het gebrek aan loop unrolls (of juist het tegenovergestelde ) en handmatig assembly inspecteren mijn baan is, ben ik het niet met je eens ;-). Omdat de rust borrow checker compiletime lifetimes afdwingt (waar mag iets mutable / niet mutable zijn) veranderd je code structuur enorm, maar wel voor het betere.

Er is enorm weinig spaghetti te vinden in Rust code naar mijn bevindingen (omdat 't allemaal redelijk duidelijk is wie welk object owned, en wat de flow van informatie is). De compiler verbied je om random pointers of references naar objecten te hebben en dus moet je eigenlijk wel redelijk eenduidige code schrijven. Je ziet ook weinig nutteloze architecture in Rust projecten (over het algemeen, *kuch* tokio *kuch*).

Het is allemaal even wennen hoor, letterlijk iedereen bij ons begint moet even een tijdje wennen aan de concepten van de borrow checker, traits etc maar tot nu toe is er niemand die echt meer terug wil.

[ Voor 48% gewijzigd door PrisonerOfPain op 31-08-2021 16:24 ]

[.oisyn]

Mercatres schreef op maandag 30 augustus 2021 @ 22:14:
[...]

Voor zover ik weet wel, al durf ik niet 100% zeker te zeggen dat dat ook niet door ReSharper komt. Maar ik denk dat het een native VS2019 feature is.

Hoe zou je dat precies activeren dan? Ik zie niet echt opties in VS2019 die daarop wijzen.

[Mercatres]

.oisyn schreef op dinsdag 31 augustus 2021 @ 16:24:
[...]


Hoe zou je dat precies activeren dan? Ik zie niet echt opties in VS2019 die daarop wijzen.

Helaas zit het niet in VS2019, maar zit het in ReSharper. Dus geen native support

[ValHallASW]

.oisyn schreef op dinsdag 31 augustus 2021 @ 16:24:
[...]


Hoe zou je dat precies activeren dan? Ik zie niet echt opties in VS2019 die daarop wijzen.

https://devblogs.microsof...-easy-with-visual-studio/


Je hebt wel een recente versie van VS2019 nodig (16.5 of later... of VS2022, die is ook een slag sneller ).

Andere opties zijn de versie die in R# zit ingebouwd, of dotPeek met symbol server.

[ Voor 12% gewijzigd door ValHallASW op 31-08-2021 17:52 ]

[Koenvh]

.oisyn schreef op dinsdag 31 augustus 2021 @ 16:24:
[...]


Hoe zou je dat precies activeren dan? Ik zie niet echt opties in VS2019 die daarop wijzen.

Hey, het is geen helpdesk hier! @.oisyn grijp 'ns in!

[.oisyn]

Ja jongens, ga weer eens offtopic. @.oisyn, jij mag je mail checken.

[Antrax]

.oisyn schreef op dinsdag 31 augustus 2021 @ 21:54:
Ja jongens, ga weer eens offtopic.

Ja, wat moet ik zeggen dan?

[Koenvh]

Antrax schreef op dinsdag 31 augustus 2021 @ 22:06:
[...]

Ja, wat moet ik zeggen dan?

Lekker weertje hè vandaag?

[Antrax]

Koenvh schreef op dinsdag 31 augustus 2021 @ 22:07:
[...]

Lekker weertje hè vandaag?

Temperatuur loopt wel iets op in de komende dagen

[PdeBie]

Krijg vanochtend een e-mail dat Docker desktop niet meer gratis is op de manier hoe wij hem gebruiken. Ow en de nieuwe voorwaarden gaan sinds gisteren in.



Krijgen nog wel heel lief tot 31 januari de ruimte om het juiste abonnementsmodel te kiezen.

F*ckers.....

[ Voor 3% gewijzigd door PdeBie op 01-09-2021 07:53 ]

[Woy]

PdeBie schreef op woensdag 1 september 2021 @ 07:48:
Krijg vanochtend een e-mail dat Docker desktop niet meer gratis is op de manier hoe wij hem gebruiken. Ow en de nieuwe voorwaarden gaan sinds gisteren in.



Krijgen nog wel heel lief tot 31 januari de ruimte om het juiste abonnementsmodel te kiezen.

F*ckers.....

Ja ik was ook nogal verbaasd door de datum. Nou haalt het voor mij niet zoveel uit, want ik val onder de small businesses, en anders kan ik ook wel zonder docker desktop. Maar wel vreemd dat je inderdaad pas een melding krijgt nadat de change ingegaan is.

[ValHallASW]

Woy schreef op woensdag 1 september 2021 @ 08:26:
Ja ik was ook nogal verbaasd door de datum. Nou haalt het voor mij niet zoveel uit, want ik val onder de small businesses, en anders kan ik ook wel zonder docker desktop. Maar wel vreemd dat je inderdaad pas een melding krijgt nadat de change ingegaan is.

Ze hadden de communicatie misschien wat handiger in kunnen zetten, maar op zich vind ik het niet zo vreemd dat de voorwaarden voor nieuwe gebruikers direct ingaan. Bestaande gebruikers krijgen nog vijf maanden om ofwel naar een betaald model over te stappen ofwel niet meer van Docker Desktop afhankelijk te zijn.

Also: https://www.npr.org/secti...ghnuts-70-years-of-regret

[ Voor 7% gewijzigd door ValHallASW op 01-09-2021 09:44 ]

[Woy]

ValHallASW schreef op woensdag 1 september 2021 @ 09:42:
[...]

Ze hadden de communicatie misschien wat handiger in kunnen zetten, maar op zich vind ik het niet zo vreemd dat de voorwaarden voor nieuwe gebruikers direct ingaan. Bestaande gebruikers krijgen nog vijf maanden om ofwel naar een betaald model over te stappen ofwel niet meer van Docker Desktop afhankelijk te zijn.

Also: https://www.npr.org/secti...ghnuts-70-years-of-regret

Ja het is vooral de communicatie. Als ze gewoon een "Docker Legacy" tier hadden geintroduceerd met een geldigheid van een jaar, en alle bestaande accounts daar naar toe gezet hadden was het anders geweest. Maar het vreemde is wel dat het niet alleen de tiers zijn, maar ook de voorwaarden. Als je dan 1 september meld dat die 31 augustus al ingegaan zijn lijkt mij dat juridisch ook niet helemaal te kloppen

[gekkie]

Meh het is er sowieso niet voor Linux, niks gemist dus

[whoami]

PdeBie schreef op woensdag 1 september 2021 @ 07:48:
Krijg vanochtend een e-mail dat Docker desktop niet meer gratis is op de manier hoe wij hem gebruiken. Ow en de nieuwe voorwaarden gaan sinds gisteren in.

Hoe gebruik je het dan ?

[PdeBie]

whoami schreef op woensdag 1 september 2021 @ 10:05:
[...]
Hoe gebruik je het dan ?

Wij zitten in een grotere organisatie dan 250 man personeel, dus wij mogen geen personal meer gebruiken.

[hackerhater]

Ze moeten ergens hun geld mee verdienen

[RobertMe]

gekkie schreef op woensdag 1 september 2021 @ 09:59:
Meh het is er sowieso niet voor Linux, niks gemist dus

Voor Docker Desktop niet, maar volgens mij veranderd de hele opzet? En de wijziging m.b.t. Docker Desktop is dan wellicht wel de grootste, waar je dan geen last van hebt, maar dat betekent niet dat de nieuwe voorwaarden geen invloed hebben op Linux gebruikers.

[Lethalis]

Tsja, misschien tijd om naar alternatieven om te kijken? Al heb ik niet zoveel zicht daar op.

Wij gebruiken ook Docker op de zaak en ook privé. Heb weleens gehoord van podman en je kan ook zelf LXC containers draaien. Maar heb nooit de moeite genomen om dat uit te zoeken, omdat we Docker hebben.

[.oisyn]

ValHallASW schreef op dinsdag 31 augustus 2021 @ 17:51:
[...]

https://devblogs.microsof...-easy-with-visual-studio/
[Afbeelding]

Je hebt wel een recente versie van VS2019 nodig (16.5 of later... of VS2022, die is ook een slag sneller ).

Nou dat werkt dus ook voor geen meter. Het lukt me wel om de gedecompilede source te zien met die optie aan, maar ik kan nog geen breakpoint zetten en step into werkt ook niet.

[RobertMe]

Lethalis schreef op woensdag 1 september 2021 @ 11:52:
Tsja, misschien tijd om naar alternatieven om te kijken? Al heb ik niet zoveel zicht daar op.

Wij gebruiken ook Docker op de zaak en ook privé. Heb weleens gehoord van podman en je kan ook zelf LXC containers draaien. Maar heb nooit de moeite genomen om dat uit te zoeken, omdat we Docker hebben.

LXC is een compleet ander iets. LXC is een container als zijnde VM. Binnen LXC draai je dus ook gewoon een init systeem (zoals systemd) een logging daemon, etc.

Podman is wel vergelijkbaar met Docker. Op een gegeven moment is het "Open Container Initiative" opgezet en zij zijn standaarden voor containers / ... gaan opzetten. De OCI image standaard is dan ook gewoon wat Docker deed. Dus een Docker image is compatible met de OCI image standaard. Podman voldoet vervolgens ook aan de OCI standaarden en kan dus ook Docker images draaien, want is gewoon een OCI image.

[Matis]

Ik gebruik docker op Windows in WSL. Werkt als een tiet

[Hydra]

Docker is als bedrijf aan het doodgaan. Ze maken al een hele tijd verlies. Dit is waarschijnlijk een laatste stuiptrekking die er alleen maar voor gaat zorgen dat alternatieven heel veel sneller opgepakt worden.

[Senaxx]

Hydra schreef op woensdag 1 september 2021 @ 12:44:
Docker is als bedrijf aan het doodgaan. Ze maken al een hele tijd verlies. Dit is waarschijnlijk een laatste stuiptrekking die er alleen maar voor gaat zorgen dat alternatieven heel veel sneller opgepakt worden.

Ik maak op mijn synology nas wel gebruik van docker en docker-compose maar niet van docker-desktop. Sowieso voor prive gebruik word het niet geraakt. Maar ben wel benieuwd welke alternativen zijn er zoal? Altijd leuk om eens uit te zoeken.

[RobertMe]

Senaxx schreef op woensdag 1 september 2021 @ 13:07:
[...]


Ik maak op mijn synology nas wel gebruik van docker en docker-compose maar niet van docker-desktop. Sowieso voor prive gebruik word het niet geraakt. Maar ben wel benieuwd welke alternativen zijn er zoal? Altijd leuk om eens uit te zoeken.

docker-ce zal lijkt mij gewoon door ontwikkeld worden. En qua echt losstaande alternatieven zou je dus bv Podman hebben. Waar ik me dan meer zorgen om zou maken is hun registry, oftewel hub.docker.com. Maar in ieder geval Microsoft & Google hebben ook publieke "docker" registies waar vanalles en nog wat in staat van open source projecten.

[OMX2000]

Hydra schreef op woensdag 1 september 2021 @ 12:44:
Docker is als bedrijf aan het doodgaan. Ze maken al een hele tijd verlies. Dit is waarschijnlijk een laatste stuiptrekking die er alleen maar voor gaat zorgen dat alternatieven heel veel sneller opgepakt worden.

Ik vrees dat dit waar is. Het bestaansrecht van het bedrijf Docker is een beetje onduidelijk. Misschien dat Google of Microsoft de boel koopt voor een habbekrats. En dan de repository "veiligstelt".

[.oisyn]

.oisyn schreef op woensdag 1 september 2021 @ 12:00:
[...]

Nou dat werkt dus ook voor geen meter. Het lukt me wel om de gedecompilede source te zien met die optie aan, maar ik kan nog geen breakpoint zetten en step into werkt ook niet.

Aaah ik moet de betreffende assembly eerst handmatig decompilen door in de modules window rechts te klikken en dan voor "decompile source to symbol file" te kiezen.

Wel jammer dat Goto Definition niet standaard de eerste keer werkt, je moet eerst die gedecompileerde file eens geopend hebben (wat wel automatisch gebeurt als je erin stept)

[ Voor 16% gewijzigd door .oisyn op 01-09-2021 14:05 ]

[gekkie]

RobertMe schreef op woensdag 1 september 2021 @ 11:43:
[...]

Voor Docker Desktop niet, maar volgens mij veranderd de hele opzet? En de wijziging m.b.t. Docker Desktop is dan wellicht wel de grootste, waar je dan geen last van hebt, maar dat betekent niet dat de nieuwe voorwaarden geen invloed hebben op Linux gebruikers.

Van wat ik eerder van volgens mij slashdot had begrepen zou er nu voor daemon en cli nog niets veranderen en zou het alleen die desktop applicatie betreffen.

[gekkie]

OMX2000 schreef op woensdag 1 september 2021 @ 13:33:
[...]
Ik vrees dat dit waar is. Het bestaansrecht van het bedrijf Docker is een beetje onduidelijk. Misschien dat Google of Microsoft de boel koopt voor een habbekrats. En dan de repository "veiligstelt".

Lijkt me bij microsoft wel bij de github aankoop passen.

[RobertMe]

gekkie schreef op woensdag 1 september 2021 @ 18:07:
[...]

Van wat ik eerder van volgens mij slashdot had begrepen zou er nu voor daemon en cli nog niets veranderen en zou het alleen die desktop applicatie betreffen.

Ook niks veranderd v.w.b. hun Docker registry dan? Hele tijd terug hebben ze volgens mij wel al aanpassingen gedaan v.w.b. rate limiting van unauthenticated users. Maar daar zouden ze natuurlijk ook nog aan de knoppen kunnen draaien om meer inkomsten te genereren met bv meer beperkingen op de gratis variant.

gekkie schreef op woensdag 1 september 2021 @ 18:09:
[...]

Lijkt me bij microsoft wel bij de github aankoop passen.

Tsja, van de andere kant heeft Azure ook al een publiekelijk toegankelijk registry en GitHub tegenwoordig misschien ook? Dan zou Microsoft het dus puur kopen zodat een ander er niet mee aan de haal kan en ze zelf eigenaar zijn van de "unprefixed" variantals je image name opgeeft.

[gekkie]

RobertMe schreef op woensdag 1 september 2021 @ 18:24:
[...]

Ook niks veranderd v.w.b. hun Docker registry dan? Hele tijd terug hebben ze volgens mij wel al aanpassingen gedaan v.w.b. rate limiting van unauthenticated users. Maar daar zouden ze natuurlijk ook nog aan de knoppen kunnen draaien om meer inkomsten te genereren met bv meer beperkingen op de gratis variant.

Niet dat ik weet. Lijkt er op dat ze vooral geld proberen te halen uit het gemakt van een GUI voor de windows en mac klikkers.

Tsja, van de andere kant heeft Azure ook al een publiekelijk toegankelijk registry en GitHub tegenwoordig misschien ook? Dan zou Microsoft het dus puur kopen zodat een ander er niet mee aan de haal kan en ze zelf eigenaar zijn van de "unprefixed" variantals je image name opgeeft.

Nouja de naam is misschien leuk, beetje het idee van goodwill en het matcht wel bij de hele github CI/CD lijkt me. Afsterven zal nog minder uitkomen, dus dan is niet al te duur overnemen denk ik een prima optie voor een microsoft. Bij microsoft lijkt er vooralsnog ook niet aan alles gelijk een gigantisch evident en direct verdienmodel te zijn. Maar goed het is allemaal een grote doos speculaasies, misschien zouden ze er totaal niet in geïnteresseerd zijn

[Sebazzz]

Hydra schreef op woensdag 1 september 2021 @ 12:44:
Docker is als bedrijf aan het doodgaan. Ze maken al een hele tijd verlies. Dit is waarschijnlijk een laatste stuiptrekking die er alleen maar voor gaat zorgen dat alternatieven heel veel sneller opgepakt worden.

De wijzigingen hingen al boven de markt toen ze updates van de Docker client verplicht gingen stellen

[wackmaniac]

gekkie schreef op woensdag 1 september 2021 @ 19:49:
[...]

Niet dat ik weet. Lijkt er op dat ze vooral geld proberen te halen uit het gemakt van een GUI voor de windows en mac klikkers.

[...]

Probleem is een beetje dat als je de standaard Docker-installatie voor MacOS of Windows wilt downloaden, dat die gebundeld is met Docker Desktop. Ik zou momenteel een hoop manieren om de Docker engine te draaien op die systemen zonder Docker Desktop, maar een VM draaien, met daarin een Docker engine en die dan gebruiken is wel zo omslachtig.

5 dollar per gebruiker per maand is geen geld en ik zal de laatste zijn die zegt dat bedrijven - of personen - geen geld mogen vragen voor hun software. Probleem is natuurlijk wel een beetje dat het per direct van toepassing is. Leuk zo'n grace period, maar het geeft wel een beetje aan hoe hoog de nood is bij Docker denk ik. Ik ben vooral benieuwd hoe open Docker staat voor een fixed price licentie voor een bedrijf. Ik zie vooral een hoop extra werk in het beheer van al die licenties.