Interessant om te zien dat een MS gecertificeerde opleiding voor iets wat niet direct of indirect aan Azure gekoppeld zit, dus gewoon verdwijnt. Heb je ook weer meteen opniew helder waar bij MS de focus ligt.Sebazzz schreef op dinsdag 30 juni 2020 @ 15:54:
Jullie weten het ongetwijfeld al:
MCSD, MCSE certifications retire; with continued investment to role-based certifications
Developers developers developers?R4gnax schreef op zaterdag 4 juli 2020 @ 22:33:
[...]
Interessant om te zien dat een MS gecertificeerde opleiding voor iets wat niet direct of indirect aan Azure gekoppeld zit, dus gewoon verdwijnt. Heb je ook weer meteen opniew helder waar bij MS de focus ligt.
🠕 This side up
"Je kan niet meer om de cloud heen."R4gnax schreef op zaterdag 4 juli 2020 @ 22:33:
[...]
Interessant om te zien dat een MS gecertificeerde opleiding voor iets wat niet direct of indirect aan Azure gekoppeld zit, dus gewoon verdwijnt. Heb je ook weer meteen opniew helder waar bij MS de focus ligt.
Persoonlijk vind ik de cloud economisch gezien een verkeerde ontwikkeling. Het is namelijk weer dat al het geld naar de grote bedrijven vloeit, zoals Amazon, Google, Oracle en Microsoft. Maar dat is een andere discussie.
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Ik vergeet iedere keer weer hoe zweterig hij daar is. Yuck.Wilf schreef op zondag 5 juli 2020 @ 07:15:
[...]
En bedankt, m’n prefrontale cortex is weer gevuld![]()
[YouTube: Steve Ballmer: Developers]
https://niels.nu
Achja hoef je het standbeeld van Balmer in iedergeval niet in de plomp te gooien, dat drijft ook op land.Hydra schreef op zondag 5 juli 2020 @ 11:15:
[...]
Ik vergeet iedere keer weer hoe zweterig hij daar is. Yuck.
Ik krijg dan weer een beetje een unheimisch gefuhl van het maniakale "volksmennen" en de zaal die gedwee applaudiseert, maar goed ik ben dan ook niet als Amerikaan ter wereld gekomen.
Met de cloud an sich heb ik dat niet; voor veel bedrijven is het een afweging tussen eigen ijzer en een VPS o.i.d. in de cloud, en dan is het gewoon een kwestie van kosten vergelijken. Colocatie is ook duur.Sebazzz schreef op zondag 5 juli 2020 @ 08:02:
[...]
"Je kan niet meer om de cloud heen."
Persoonlijk vind ik de cloud economisch gezien een verkeerde ontwikkeling. Het is namelijk weer dat al het geld naar de grote bedrijven vloeit, zoals Amazon, Google, Oracle en Microsoft. Maar dat is een andere discussie.
Wat me wel meer verbaast is dat sommige bedrijven hun hele infrastructuur richten op bijvoorbeeld AWS. Ik geloof best dat dat allemaal heel mooi kan werken, maar je creëert een enorme vendor lock-in voor jezelf op die manier. Eigenlijk geef je AWS vrij spel over je hele bedrijf, en dat vind ik nogal een riskante keuze (immers, snel ergens anders naartoe gaat niet). Een VPS kun je wel ergens anders naar verhuizen (of op eigen ijzer gaan draaien), maar je systeem waarin een AWS Lambda opdracht geeft aan AWS S3, die data pompt naar AWS Elastic Transcoder om vervolgens met AWS Hotrod alles aan AWS CloudFront te laten serveren, dat snap ik dan weer net niet.
🠕 This side up
Ditzelfde heb ik ook al zien gebeuren met Azure omgevingen. MS biedt ook daar allemaal coole handige dingen aan zoals Azure functions waarmee je jezelf enorm afhangkelijk maakt van hun platform. Ik snap ook niet waarom je dat zou willen gebruiken. Gewoon als hosting-platform werkt het imho wel prima.Koenvh schreef op zondag 5 juli 2020 @ 15:32:
[...]
Met de cloud an sich heb ik dat niet; voor veel bedrijven is het een afweging tussen eigen ijzer en een VPS o.i.d. in de cloud, en dan is het gewoon een kwestie van kosten vergelijken. Colocatie is ook duur.
Wat me wel meer verbaast is dat sommige bedrijven hun hele infrastructuur richten op bijvoorbeeld AWS. Ik geloof best dat dat allemaal heel mooi kan werken, maar je creëert een enorme vendor lock-in voor jezelf op die manier. Eigenlijk geef je AWS vrij spel over je hele bedrijf, en dat vind ik nogal een riskante keuze (immers, snel ergens anders naartoe gaat niet). Een VPS kun je wel ergens anders naar verhuizen (of op eigen ijzer gaan draaien), maar je systeem waarin een AWS Lambda opdracht geeft aan AWS S3, die data pompt naar AWS Elastic Transcoder om vervolgens met AWS Hotrod alles aan AWS CloudFront te laten serveren, dat snap ik dan weer net niet.
Roses are red, violets are blue, unexpected '{' on line 32.
Mja, ik zie ook bij veel klanten dat er enorme vendor lock-in is en dat dit echt een bewuste keuze is. Voor lambdas kun je nog wel gebruik maken van het serverless framework als je liever geen lock-in wilt.Koenvh schreef op zondag 5 juli 2020 @ 15:32:
[...]
Met de cloud an sich heb ik dat niet; voor veel bedrijven is het een afweging tussen eigen ijzer en een VPS o.i.d. in de cloud, en dan is het gewoon een kwestie van kosten vergelijken. Colocatie is ook duur.
Wat me wel meer verbaast is dat sommige bedrijven hun hele infrastructuur richten op bijvoorbeeld AWS. Ik geloof best dat dat allemaal heel mooi kan werken, maar je creëert een enorme vendor lock-in voor jezelf op die manier. Eigenlijk geef je AWS vrij spel over je hele bedrijf, en dat vind ik nogal een riskante keuze (immers, snel ergens anders naartoe gaat niet). Een VPS kun je wel ergens anders naar verhuizen (of op eigen ijzer gaan draaien), maar je systeem waarin een AWS Lambda opdracht geeft aan AWS S3, die data pompt naar AWS Elastic Transcoder om vervolgens met AWS Hotrod alles aan AWS CloudFront te laten serveren, dat snap ik dan weer net niet.
Toch vraag me ik me wel steeds meer af of het nou zo problematisch is. Iets als SQL is natuurlijk een gedeelde standaard, maar migraties van de ene SQL database naar de andere is eigenlijk ook altijd nog een hele klus als je er meer mee doet dan een CRUD datadump.
Lambda's zijn ook niet zo'n punt om te verkassen als je de interfaces maar een beetje weg abstraheert. Hetzelfde geldt voor S3. Abstraheer de toegang in je code een beetje fatsoenlijk weg en je kunt vrij makkelijk over naar een andere vorm van opslag.
En het maakt je leven wel zoveel makkelijker qua monitoring en alerting, met een SQS heb je veel minder gezeik dan wanneer je je eigen messaging clusters in de lucht moet houden en ga zo maar door.
Ja als je alles in containers hangt dan zul je uiteindelijk minder werk hebben als je besluit alles weer over te hevelen naar on premise, maar je bespaart jezelf wel heel veel werk en ellende tijdens het draaiende houden van de boel.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dat valt op zich best mee. Azure functions kun je ook vrij eenvoudig zelf hosten in een proces. Dus valt ook gewoon in een docker/k8s setup te draaien, zelfde geld ongetwijfeld voor AWS lambda. Dat geld voor de meeste features wel dat het redelijk te vervangen is. Maar het is ook de vraag hoeveel tijd/geld je wil besteden om onafhankelijk te zijn. Zolang Microsoft, Amazon en Google gewoon flink blijven concurreren krijg je meestal toch wel scherpe prijzen. Zorgen dat je makkelijk over kunt stappen kost ook geld, zonde als je dat toch niet doetWernerL schreef op zondag 5 juli 2020 @ 19:32:
[...]
Ditzelfde heb ik ook al zien gebeuren met Azure omgevingen. MS biedt ook daar allemaal coole handige dingen aan zoals Azure functions waarmee je jezelf enorm afhangkelijk maakt van hun platform. Ik snap ook niet waarom je dat zou willen gebruiken. Gewoon als hosting-platform werkt het imho wel prima.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Ik begrijp je punt wel, maar dit voorbeeld niet. Volgens mij zijn er talloze verhalen van bedrijven die graag van Oracle afwillen, maar niet kunnen om precies deze reden. Dat spreekt dan toch eerder tegen een vendor lock-in?Mugwump schreef op zondag 5 juli 2020 @ 19:49:
[...]
Toch vraag me ik me wel steeds meer af of het nou zo problematisch is. Iets als SQL is natuurlijk een gedeelde standaard, maar migraties van de ene SQL database naar de andere is eigenlijk ook altijd nog een hele klus als je er meer mee doet dan een CRUD datadump.
🠕 This side up
Mjah aan de andere kant zijn een abstractie laag / ORM of alleen maar basic SQL features gebruiken (en dan nog) ook niet echt geweldige alternatieven.Koenvh schreef op zondag 5 juli 2020 @ 21:09:
[...]
Ik begrijp je punt wel, maar dit voorbeeld niet. Volgens mij zijn er talloze verhalen van bedrijven die graag van Oracle afwillen, maar niet kunnen om precies deze reden. Dat spreekt dan toch eerder tegen een vendor lock-in?
Aan de andere kant vraag ik me wel af of het "schaalbaar" argument werkelijk voor zoveel toepassingen echt zo relevant is.
Oracle is nog wel even iets meer dan enkel een database natuurlijk. Volgens mij zijn er niet zo gek veel bedrijven die puur een Oracle database hebben en daar niet vanaf kunnen komen. Maar verder illustreert dit mijn punt prima. SQL is gewoon een standaard, dus je zou zeggen dat het makkelijk migreren geen punt is, maar in de praktijk maakt iedereen in een database al snel gebruik van dan alles wat buiten de standaard valt.Koenvh schreef op zondag 5 juli 2020 @ 21:09:
[...]
Ik begrijp je punt wel, maar dit voorbeeld niet. Volgens mij zijn er talloze verhalen van bedrijven die graag van Oracle afwillen, maar niet kunnen om precies deze reden. Dat spreekt dan toch eerder tegen een vendor lock-in?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dan begrijp ik je punt volgens mij niet @Mugwump , want ik zou juist denken: waarom voor Oracle kiezen als je daardoor de hele tijd naar de pijpen van Oracle moet dansen. Het gaat me ook niet om de cloud an sich, maar om de gevolgen qua keuzevrijheid. Da's in dit geval niet anders. En het is niet alsof je geen keuzes kunt maken, waarbij je wel vrijheid hebt (MySQL/MariaDB/PostgreSQL; een eigen VPS met je favoriete Linuxdistributie).
@Woy
Het is ook niet dat je direct en zonder wijzigingen om moet kunnen schakelen, maar wel: waar zijn we nu van afhankelijk, en wat zijn de gevolgen daarvan? In het geval van AWS of Google Cloud kun je helemaal van Amazon of Google afhankelijk zijn. Er zijn geluiden dat Google bijvoorbeeld wil uitstappen als ze niet de grootste worden [1]; wat voor gevolgen heeft dat voor je bedrijf? Betekent dat dat je alleen een aantal VPS'en moet verplaatsen, en de koppelingen met Google Cloud Storage moet omschrijven naar iets anders, of betekent dat dat je bijna je hele product vanaf 0 moet opbouwen, omdat alles afhankelijk is van de Google Cloud?
Ik wil niet zeggen dat je de keuze niet zou moeten maken, maar je moet het wel in ogenschouw nemen bij het maken van die beslissing. Hoe makkelijk dat is, is afhankelijk van wat je van AWS, Azure of de Google Cloud gebruikt.
[1] nieuws: 'Google wil in 2023 grootste cloudprovider worden of divisie stoppen'...
@Woy
Het is ook niet dat je direct en zonder wijzigingen om moet kunnen schakelen, maar wel: waar zijn we nu van afhankelijk, en wat zijn de gevolgen daarvan? In het geval van AWS of Google Cloud kun je helemaal van Amazon of Google afhankelijk zijn. Er zijn geluiden dat Google bijvoorbeeld wil uitstappen als ze niet de grootste worden [1]; wat voor gevolgen heeft dat voor je bedrijf? Betekent dat dat je alleen een aantal VPS'en moet verplaatsen, en de koppelingen met Google Cloud Storage moet omschrijven naar iets anders, of betekent dat dat je bijna je hele product vanaf 0 moet opbouwen, omdat alles afhankelijk is van de Google Cloud?
Ik wil niet zeggen dat je de keuze niet zou moeten maken, maar je moet het wel in ogenschouw nemen bij het maken van die beslissing. Hoe makkelijk dat is, is afhankelijk van wat je van AWS, Azure of de Google Cloud gebruikt.
[1] nieuws: 'Google wil in 2023 grootste cloudprovider worden of divisie stoppen'...
🠕 This side up
Ik denk dat een hoop clubs die wel weg willen van Oracle maar dat niet (of moeilijk) kunnen, het niet gisteren gekozen hebben, maar al een of meerdere decennia Oracle gebruiken. En er was wel een tijd dat opensource databases een stuk magerder waren qua features.Koenvh schreef op zondag 5 juli 2020 @ 21:43:
Dan begrijp ik je punt volgens mij niet @Mugwump , want ik zou juist denken: waarom voor Oracle kiezen als je daardoor de hele tijd naar de pijpen van Oracle moet dansen. Het gaat me ook niet om de cloud an sich, maar om de gevolgen qua keuzevrijheid. Da's in dit geval niet anders. En het is niet alsof je geen keuzes kunt maken, waarbij je wel vrijheid hebt (MySQL/MariaDB/PostgreSQL; een eigen VPS met je favoriete Linuxdistributie).
Nieuwe klanten voor Oracle zou ik denk ik ook niet zo goed snappen gezien de alternatieven op dit moment.
Het punt is dat SQL er juist is als standaard, die door vele partijen geïmplementeerd wordt. Als je kiest voor MySQL, zou je dus in theorie makkelijk over moeten kunnen naar postgres, Azure SQL of whatever. In de praktijk valt zo'n migratietraject echter nog wel tegen. Natuurlijk kan het, maar je moet er de nodige moeite in steken.Koenvh schreef op zondag 5 juli 2020 @ 21:43:
Dan begrijp ik je punt volgens mij niet @Mugwump , want ik zou juist denken: waarom voor Oracle kiezen als je daardoor de hele tijd naar de pijpen van Oracle moet dansen. Het gaat me ook niet om de cloud an sich, maar om de gevolgen qua keuzevrijheid. Da's in dit geval niet anders. En het is niet alsof je geen keuzes kunt maken, waarbij je wel vrijheid hebt (MySQL/MariaDB/PostgreSQL; een eigen VPS met je favoriete Linuxdistributie).
Mijn punt is meer dat "we kiezen voor generieke technologie, want dan kunnen we makkelijk switchen" vaak wel wat genuanceerder ligt. Je hebt er altijd werk aan. En dat geldt het zo goed wanneer je voor cloudspecifieke zaken als Lambda's of Azure Functions of DynamoDB of Cosmos DB gaat.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
@Mugwump Je vergeet alleen wel dat je met de cloud nog meer controle verliest. Natuurlijk, als MySQL de handdoek in de ring zou gooien, dan zou het wel wat werk worden om dingen te migreren. Daarentegen kun je wel MySQL blijven draaien, hetzij op een verouderde server. Dat gebeurt met genoeg software op dit moment. Met de Google Cloud kan Google besluiten de stekker eruit te trekken, en dan sta je met niks.
🠕 This side up
Nou zal het met hun cloud zo'n vaart niet lopen, maar je toko bouwen op allerhande API's van Google of Facebook zou ik inderdaad wel voorzichtig zijn. En als ze de stekker er uit trekken wil dat ook nog wel eens vrij rücksichtloss zijn, dus echt veel dev-time om het te vervangen heb je dan ook niet.
Dat gevaar heb je bij een opensource DB dan iets minder.
Dat gevaar heb je bij een opensource DB dan iets minder.
[ Voor 8% gewijzigd door gekkie op 06-07-2020 10:42 ]
Dat heeft vrijwel nooit iets te maken met het RDBMs deel. Oracle is veel meer dan alleen een database en er wordt dan veel gebruik gemaakt van Oracle Forms of Oracle AQ. En daar kom je niet snel vanaf.Koenvh schreef op zondag 5 juli 2020 @ 21:09:
Ik begrijp je punt wel, maar dit voorbeeld niet. Volgens mij zijn er talloze verhalen van bedrijven die graag van Oracle afwillen, maar niet kunnen om precies deze reden. Dat spreekt dan toch eerder tegen een vendor lock-in?
https://niels.nu
Ik denk dat mensen die hyperbool iets te letterlijk nemen.
https://niels.nu
Als je dat tot in den extreme doortrekt, kun je alles wel helemaal zelf gaan bouwen. Maar ondertussen is het runnen van een datacenter gewoon niet je core business. En de meeste bedrijven zijn daar ook gewoon echt enorm slecht in.Koenvh schreef op maandag 6 juli 2020 @ 02:13:
@Mugwump Je vergeet alleen wel dat je met de cloud nog meer controle verliest. Natuurlijk, als MySQL de handdoek in de ring zou gooien, dan zou het wel wat werk worden om dingen te migreren. Daarentegen kun je wel MySQL blijven draaien, hetzij op een verouderde server. Dat gebeurt met genoeg software op dit moment. Met de Google Cloud kan Google besluiten de stekker eruit te trekken, en dan sta je met niks.
Je kunt het niet hebben over het 'risico' dat Google de stekker eruit trekt, en dan alle risico's en kosten van 'het zelf doen' dan maar negeren.
https://niels.nu
Als Google er mee stopt een risico voor je is dan ga je toch naar AWS of Azure? Die gaan echt never nooit niet stoppen, al zie ik wel gebeuren dat AWS een apart bedrijf wordt als Amazon echt te groot gaat worden.
Je kan eventueel ook nog met een framework zoals Serverless werken, dan heb je in het geval van functions er een laag tussen zitten en kan je naar verschillende clouds deployen. Echter is dan de vraag of je wel alle features hebt die een dienst zo goed maakt
Je kan eventueel ook nog met een framework zoals Serverless werken, dan heb je in het geval van functions er een laag tussen zitten en kan je naar verschillende clouds deployen. Echter is dan de vraag of je wel alle features hebt die een dienst zo goed maakt
Google heeft wel vaker vrij abrupt hard-, soft- en serviceware afgestoten dus verbazen zal het niemand.Hydra schreef op maandag 6 juli 2020 @ 10:52:
[...]
Ik denk dat mensen die hyperbool iets te letterlijk nemen.
Dit is in mijn ogen vooral de centrale vraag. Wij hebben b.v. ook in het verleden zelf wel diensten geboden die gebaseerd waren op dedicated (Datawarehouse) hardware. Dat is ook end-of-life geraakt omdat de fabrikant ermee stopte en dan moet je dus op een gegeven moment ook over. Je kunt nog een tijdje teren op je bestaande hardware en nichepartijen die reparaties uitvoeren, maar daarna houdt het wel een keer op. Dus dan moet je gaan migreren en dat kost altijd tijd en moeite.Hydra schreef op maandag 6 juli 2020 @ 10:54:
[...]
Als je dat tot in den extreme doortrekt, kun je alles wel helemaal zelf gaan bouwen. Maar ondertussen is het runnen van een datacenter gewoon niet je core business. En de meeste bedrijven zijn daar ook gewoon echt enorm slecht in.
Je kunt het niet hebben over het 'risico' dat Google de stekker eruit trekt, en dan alle risico's en kosten van 'het zelf doen' dan maar negeren.
Dat geldt gewoon altijd. Partijen in complexe ketens leunen ook op elkaars dienstverlening. Gaat een partij in die keten plots failliet, dan is het ook vaak niet even een kwestie van een andere leverancier bellen en verder gaan.
Kijk je kunt in plaats van leunen op S3 ook gewoon een eigen SFTP server in een container hangen of een file system met een REST API ervoor, een eigen file monitoring / triggering systeem maken, zorgen dat je een interface biedt die de boel efficiënt doorzoekbaar maakt, eigen logging / alerting erbij maken, authenticatie / authorizatie met single sign-on, automatische back-ups en cleanup en ga zo maar door. Als je dat allemaal netjes in containers hangt en drie kilometer aan documentatie produceert dan kun je het inderdaad vrij makkelijk in theorie verplaatsen van één cloudprovider naar een andere of zelfs naar je eigen on-premise oplossing. Heel mooi natuurlijk. Ben je wel een paar maanden ontwerp en bouw verder, maar dan heb je ook wat. ; Een oplossing waarvoor je zelf je bed uit kunt als er netwerkhikjes zijn, de monitoring / alerting niet goed werkt of wat dan ook.
Kost je in AWS of Azure ongeveer een uur om een bucket of een storage account aan te maken. Kun je dan heel makkelijk naar een andere oplossing? Nee, dat kost wat meer tijd omdat je ook enig redesign moet doen. Maar als je het in je software redelijk weg abstraheert hoeft dat niet eens zo heel veel effort te kosten. Goed, alle monitoring / alerting e.d. omkatten is wat werk, maar een hele containerized oplossing migreren is ook vaak minder makkelijk dan het lijkt. Er komt wel iets meer bij kijken dan enkel je containertjes verplaatsen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Gebruikt er iemand hier Gitlab? Als ik een branch naam wil kopiëren krijg ik altijd iets in de trant van
code:
in mijn klembord. Hebben jullie daar ook last van? Echt waardeloos als je het mij vraagt
1
| {"text":"JIRA-231","gfm":"`jira-231`"} |
[ Voor 3% gewijzigd door alienfruit op 06-07-2020 13:21 ]
Google die met Google Cloud 'stopt' zal een hoop mensen 'verbazen'. Jemig zegWilf schreef op maandag 6 juli 2020 @ 12:21:
Google heeft wel vaker vrij abrupt hard-, soft- en serviceware afgestoten dus verbazen zal het niemand.

https://niels.nu
Ik denk dat de crux hier vooral is in hoe specifiek die software is. Natuurlijk zijn Amazon S3 en Google Cloud storage 'anders', maar wat ze doen en vooral hoe is eigenlijk hetzelfde. Dus meet een redelijk abstractieniveau is dat best te switchen. Hetzelfde geldt voor databases, document stores or queues. Anders maar toch hetzelfde.Mugwump schreef op maandag 6 juli 2020 @ 12:40:
Dit is in mijn ogen vooral de centrale vraag. Wij hebben b.v. ook in het verleden zelf wel diensten geboden die gebaseerd waren op dedicated (Datawarehouse) hardware. Dat is ook end-of-life geraakt omdat de fabrikant ermee stopte en dan moet je dus op een gegeven moment ook over. Je kunt nog een tijdje teren op je bestaande hardware en nichepartijen die reparaties uitvoeren, maar daarna houdt het wel een keer op. Dus dan moet je gaan migreren en dat kost altijd tijd en moeite.
Dat geldt gewoon altijd. Partijen in complexe ketens leunen ook op elkaars dienstverlening. Gaat een partij in die keten plots failliet, dan is het ook vaak niet even een kwestie van een andere leverancier bellen en verder gaan.
Google Vision API's en de meer specifieke zaken daarentegen, daar is vaak gewoon geen alternatief voor.
Ok absoluut. Ik ben zelf als dev sowieso over het algemeen voor managed platformen. Ik heb de "we doen het zelf" aanpak vaak genoeg gezien, en het gaat zo ontzettend vaak mis.Kost je in AWS of Azure ongeveer een uur om een bucket of een storage account aan te maken. Kun je dan heel makkelijk naar een andere oplossing? Nee, dat kost wat meer tijd omdat je ook enig redesign moet doen. Maar als je het in je software redelijk weg abstraheert hoeft dat niet eens zo heel veel effort te kosten. Goed, alle monitoring / alerting e.d. omkatten is wat werk, maar een hele containerized oplossing migreren is ook vaak minder makkelijk dan het lijkt. Er komt wel iets meer bij kijken dan enkel je containertjes verplaatsen.
https://niels.nu
Serverless is vooral een deploymentabstractie. Niet een abstractie voor de function code zelf. Een AWS function kun je absoluut niet 'even' op Google deployen.GrooV schreef op maandag 6 juli 2020 @ 11:58:
Je kan eventueel ook nog met een framework zoals Serverless werken, dan heb je in het geval van functions er een laag tussen zitten en kan je naar verschillende clouds deployen. Echter is dan de vraag of je wel alle features hebt die een dienst zo goed maakt
https://niels.nu
Klopt, zaken als object storage / document stores / queues hebben wel redelijk wat overeenkomsten. Toch geldt wel vaak dat de duivel in de details zit. Bij queueing bijvoorbeeld de mate waarin zaken ondersteund worden als fifo, priority, transactionaliteit van operaties, bij document stores de implementatie van consistency, eventuele locking mogelijkheden, persist en publish mechanismen en ga zo maar door. Die nuances kunnen een migratie wel wat complexer maken dan op voorhand gedacht. Priority is bijvoorbeeld heel handig als je een generieke verwerking hebt, maar bepaalde berichten er sneller doorheen moeten lopen. Heb je die mogelijkheid niet, dan moet je iets anders verzinnen. Een aparte queue is niet helemaal hetzelfde, want dan kun je hebben dat beide queues vechten om gedeelde (schaarse) resources. En als je een systeem hebt gebouwd dat leunt op distributed transactions met messaging en data store (nooit doen.Hydra schreef op maandag 6 juli 2020 @ 13:30:
[...]
Ik denk dat de crux hier vooral is in hoe specifiek die software is. Natuurlijk zijn Amazon S3 en Google Cloud storage 'anders', maar wat ze doen en vooral hoe is eigenlijk hetzelfde. Dus meet een redelijk abstractieniveau is dat best te switchen. Hetzelfde geldt voor databases, document stores or queues. Anders maar toch hetzelfde.
En zeker bij alle hippe NoSQL data stores kan migratie nog wel wat problematisch worden als je gebruikt maakt van triggers of stored procedures, locking en meer van dat soort ongein die qua implementatie echt behoorlijk uit elkaar lopen.
Goed, het is allemaal te doen natuurlijk, alleen kost het wat tijd en soms wat redesign.
Ja klopt, maar dat gaat ook wel een paar stappen verder. Dat is meer een specialistische dienst die je afneemt in mijn ogen. Er zijn natuurlijk heel veel commerciële diensten die (ook) een API bieden van dit soort AI-achtige toepassingen of GIS toepassingen (aka Google Maps) tot simpelere zaken als adresvalidatie. Daar kan de stekker in theorie uitgaan. Als die dienst dan een centraal onderdeel is van je eigen product en de dienst ligt eruit of stopt dan heb je gewoon even een probleem. Soms zijn er nog wel zaken die ongeveer hetzelfde doen, (Azure Cognitive Services ipv de Google Vision API oid), maar het is een stuk minder makkelijk vervangbaar. Wat je ook nog wel eens ziet is dat er kleinschalig is begonnen en leuk gebruik gemaakt kon worden van de free tier van een of andere API, maar door volumegroei opeens betaald moet gaan worden en de kosten toch aardig tegenvallen.Google Vision API's en de meer specifieke zaken daarentegen, daar is vaak gewoon geen alternatief voor.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Het punt is wel dat bij diensten zoals Google Vision oid, je vaak ook voor data transfers betaald als het van buiten hun eigen cloud moet komen. Dus als je veel gebruik maakt van zo'n dienst word het heel snel voordelig om ook je data(base) bij hun te hebben staan. En dat zorgt er weer voor dat je sneller/makkelijker andere diensten gaat afnemen. En dan heb je vendor lock-in.
Nee die heb je niet, je vindt het alleen te duur/omslachtig om diensten te verspreiden over meerdere aanbieders.Gropah schreef op maandag 6 juli 2020 @ 16:04:
Het punt is wel dat bij diensten zoals Google Vision oid, je vaak ook voor data transfers betaald als het van buiten hun eigen cloud moet komen. Dus als je veel gebruik maakt van zo'n dienst word het heel snel voordelig om ook je data(base) bij hun te hebben staan. En dat zorgt er weer voor dat je sneller/makkelijker andere diensten gaat afnemen. En dan heb je vendor lock-in.
Any errors in spelling, tact, or fact are transmission errors.
Mjah dan heb je, als je het een beetje ver wilt zoeken, nooit een vendor lock-in.
Als je genoeg geld hebt dan kun je alles als nog zelf ontwikkelen of dan koop je de tent over, dus het is nooit een echt definitieve "lock".
Maar goed of dat geheel redelijk en billijk is om te veronderstellen ...
En inderdaad wat Gropah zegt, verkijk je niet op de (potentieel) bij komende kosten van alles in de cloud
(storage, data er heen, data weer terug etc. ook met bijvb AI trainen op een GPU/TPU, de rand zaken kosten bekant meer dan de compute als je niet op past).
Als je genoeg geld hebt dan kun je alles als nog zelf ontwikkelen of dan koop je de tent over, dus het is nooit een echt definitieve "lock".
Maar goed of dat geheel redelijk en billijk is om te veronderstellen ...
En inderdaad wat Gropah zegt, verkijk je niet op de (potentieel) bij komende kosten van alles in de cloud
(storage, data er heen, data weer terug etc. ook met bijvb AI trainen op een GPU/TPU, de rand zaken kosten bekant meer dan de compute als je niet op past).
[ Voor 30% gewijzigd door gekkie op 06-07-2020 18:04 ]
We doen tegenwoordig zo veel cloud gerelateerde dingen dat we zelf gewoon wat computers/servers neer hebben gezet, scheelde een hoopgekkie schreef op maandag 6 juli 2020 @ 18:02:
(storage, data er heen, data weer terug etc. ook met bijvb AI trainen op een GPU/TPU, de rand zaken kosten bekant meer dan de compute als je niet op past).
Mjah ik blijft het lastig vinden dat het proberen in te schatten van de kosten component (en op basis daar van wat te doen (data laten staan, kost geld, data weghalen en later weer nodig hebben misschien nog wel meer ... wanneer haal ik het weg ?!?). Het is bijna een vak op zich "cloud-calculator" met al die microtransacties.PrisonerOfPain schreef op maandag 6 juli 2020 @ 18:31:
[...]
We doen tegenwoordig zo veel cloud gerelateerde dingen dat we zelf gewoon wat computers/servers neer hebben gezet, scheelde een hoop
Gelukkig heb je het binnenkort ook in de otto, na Tesla hebben de vrienden van de Beamer ook het licht gezien: https://tech.slashdot.org...nlinkanon&utm_medium=feed
Mja, laten we het zo zeggen dat je voor 10-20k per maand aardig wat Ryzen's kunt kopengekkie schreef op maandag 6 juli 2020 @ 18:37:
[...]
Mjah ik blijft het lastig vinden dat het proberen in te schatten van de kosten component (en op basis daar van wat te doen (data laten staan, kost geld, data weghalen en later weer nodig hebben misschien nog wel meer ... wanneer haal ik het weg ?!?). Het is bijna een vak op zich "cloud-calculator" met al die microtransacties.
De hardware is in mijn ogen ook slechts een klein onderdeel van de TCO.PrisonerOfPain schreef op maandag 6 juli 2020 @ 18:39:
[...]
Mja, laten we het zo zeggen dat je voor 10-20k per maand aardig wat Ryzen's kunt kopen
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Wat is de rest dan? Het personeel dat er voor nodig is (dat we toch al hadden om de Google infra onder de duim te houden), en verder...?Mugwump schreef op maandag 6 juli 2020 @ 18:43:
[...]
De hardware is in mijn ogen ook slechts een klein onderdeel van de TCO.
(Ik ben niet de persoon die deze calls maakt overigens).
Achja ik kan best redenen vinden waarbij er wat voor de cloud te zeggen valt:
Relatief makkelijk in meerdere werelddelen lokaal zitten en daar tussen ook failovers te hebben;
Of hele hoge en incidentele load/requests die op een andere manier niet te ondervangen is;
Te hoge kosten voor initiele investering in hardware;
Aan de andere kant kan een of meerdere standaard rammelkasten voor een fixed price ook prima werken en de nodige "peace of mind" geven (zeker voor wat betreft het kosten plaatje). En tevens een vrij solide en goed bij te houden oplossing door de eenvoud, zeker als je geen 24/7/365.2421875 SLA hoeft te bieden.
Gelukkig mag iedereen zelf bepalen of en hoeveel "wolkje" hij of zij (of anders dan wel niet geletterden) de in de koffie believen
(waarom heeft tweakers geen tas koffie smiley eigenlijk ...)
Relatief makkelijk in meerdere werelddelen lokaal zitten en daar tussen ook failovers te hebben;
Of hele hoge en incidentele load/requests die op een andere manier niet te ondervangen is;
Te hoge kosten voor initiele investering in hardware;
Aan de andere kant kan een of meerdere standaard rammelkasten voor een fixed price ook prima werken en de nodige "peace of mind" geven (zeker voor wat betreft het kosten plaatje). En tevens een vrij solide en goed bij te houden oplossing door de eenvoud, zeker als je geen 24/7/365.2421875 SLA hoeft te bieden.
Gelukkig mag iedereen zelf bepalen of en hoeveel "wolkje" hij of zij (of anders dan wel niet geletterden) de in de koffie believen
(waarom heeft tweakers geen tas koffie smiley eigenlijk ...)
[ Voor 13% gewijzigd door gekkie op 06-07-2020 20:36 ]
Alles wat er bij komt kijken om de boel te bouwen en draaiende te houden inderdaad. Zoals ik in een eerdere post al aanhaalde krijg je bijvoorbeeld bij S3 niet alleen wat opslag, maar monitoring, auditing, security, triggers, integratie met allerhande diensten, automatische back-ups, georeplication en ga zo maar door. Dat bouwen en in de lucht houden kost ook heel wat. En dat geldt eigenlijk voor heel veel zaken. Zeker als je bijvoorbeeld databases of messaging een beetje tot de limieten rekt, dan ga je heel veel onverwachte zaken zien je niet direct ziet bij doorsnee belasting en dan heb je heel wat kennis, kunde en tijd nodig om dat onder controle te houden.PrisonerOfPain schreef op maandag 6 juli 2020 @ 18:50:
[...]
Wat is de rest dan? Het personeel dat er voor nodig is (dat we toch al hadden om de Google infra onder de duim te houden), en verder...?
(Ik ben niet de persoon die deze calls maakt overigens).
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik gebruik eigenlijk gewoon OpenFAAS als vervanger voor AWS Lambda's werkt prima
Ah op die manier. Het grootste gedeelte van onze workloads is deep learning, dus veel compute. We gebruiken wel storage maar meer om onze CI omhoog te houden (build artifacts en dingen te hosten) dus dat blijft gewoon daar draaien.Mugwump schreef op maandag 6 juli 2020 @ 21:56:
[...]
Alles wat er bij komt kijken om de boel te bouwen en draaiende te houden inderdaad. Zoals ik in een eerdere post al aanhaalde krijg je bijvoorbeeld bij S3 niet alleen wat opslag, maar monitoring, auditing, security, triggers, integratie met allerhande diensten, automatische back-ups, georeplication en ga zo maar door. Dat bouwen en in de lucht houden kost ook heel wat. En dat geldt eigenlijk voor heel veel zaken. Zeker als je bijvoorbeeld databases of messaging een beetje tot de limieten rekt, dan ga je heel veel onverwachte zaken zien je niet direct ziet bij doorsnee belasting en dan heb je heel wat kennis, kunde en tijd nodig om dat onder controle te houden.
Ja oké, als je echt puur compute nodig hebt en je hebt vrij continue belasting, dan kan het zelf aanschaffen van hardware inderdaad schelen.PrisonerOfPain schreef op dinsdag 7 juli 2020 @ 00:02:
[...]
Ah op die manier. Het grootste gedeelte van onze workloads is deep learning, dus veel compute. We gebruiken wel storage maar meer om onze CI omhoog te houden (build artifacts en dingen te hosten) dus dat blijft gewoon daar draaien.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ja daarom - het enige wat we doen is een hoop CUDA en CPU werk launchen. Voor storage is het een stuk lastiger denk ik, zeker als je daar gelobale replication en zo voor op wilt zetten.Mugwump schreef op dinsdag 7 juli 2020 @ 09:05:
[...]
Ja oké, als je echt puur compute nodig hebt en je hebt vrij continue belasting, dan kan het zelf aanschaffen van hardware inderdaad schelen.
Ik ga er dan van uit dat jullie dat werk volledig zelf inplannen en jullie (daarom) compleet in control zijn mbt de belasting van de hardware in de planning van de jobs. Daardoor kunnen jullie je hardware bijna maximaal benutten.
Dat wordt natuurlijk anders wanneer je load veel afhankelijker is van externe factoren. Bij de belastingdienst hebben/hadden ze (volgens mij) een enorm park staan dat het hele jaar uit z'n neus vreet en vervolgens eind april de load niet aan kan. Nu is dat een slecht voorbeeld aangezien je die processen niet in een externe cloud wil draaien, en al helemaal niet in patriot act trumpland. Maar een overheidscloud die in april druk de aangifte processen draait, en in augustus de prolongaties van de studiefinanciering van DUO doet etc etc is een stuk efficienter.
Dat wordt natuurlijk anders wanneer je load veel afhankelijker is van externe factoren. Bij de belastingdienst hebben/hadden ze (volgens mij) een enorm park staan dat het hele jaar uit z'n neus vreet en vervolgens eind april de load niet aan kan. Nu is dat een slecht voorbeeld aangezien je die processen niet in een externe cloud wil draaien, en al helemaal niet in patriot act trumpland. Maar een overheidscloud die in april druk de aangifte processen draait, en in augustus de prolongaties van de studiefinanciering van DUO doet etc etc is een stuk efficienter.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Gebruik maken van Cloudplatformen als die van Amazon, Microsoft en Google voor basale zaken als compute loont inderdaad vooral als je een flinke discrepantie hebt tussen je piekbelasting en je gemiddelde belasting. Als je elke dag tussen 7:00 en 7:15 een zwaar proces draait dat 100% van je capaciteit benut en de rest van de dag slechts op 10% van die capaciteit zit, dan is het waarschijnlijk voordeliger om gewoon lekker gebruik te maken van zo'n cloudplatform of een hybride situatie te kiezen waarbij je eigen hardware hebt voor die 10% en voor de piekload een cloudplatform inzet.Janoz schreef op dinsdag 7 juli 2020 @ 11:55:
Ik ga er dan van uit dat jullie dat werk volledig zelf inplannen en jullie (daarom) compleet in control zijn mbt de belasting van de hardware in de planning van de jobs. Daardoor kunnen jullie je hardware bijna maximaal benutten.
Dat wordt natuurlijk anders wanneer je load veel afhankelijker is van externe factoren. Bij de belastingdienst hebben/hadden ze (volgens mij) een enorm park staan dat het hele jaar uit z'n neus vreet en vervolgens eind april de load niet aan kan. Nu is dat een slecht voorbeeld aangezien je die processen niet in een externe cloud wil draaien, en al helemaal niet in patriot act trumpland. Maar een overheidscloud die in april druk de aangifte processen draait, en in augustus de prolongaties van de studiefinanciering van DUO doet etc etc is een stuk efficienter.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Live reverse engineering van een file op Twitter
https://twitter.com/oisyn/status/1280632104414523397
[ Voor 6% gewijzigd door .oisyn op 08-07-2020 01:32 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het grootste heikel punt waar ik mee zit met on-prem is de initiële kosten van een setup. Zeker met storage. Concreet meegemaakt dat we dus bijna geen storage meer hadden. Nja dan ga je niet 1 nieuwe disk kopen maar moet er een blade/semi-rack komen - a ~20.000++ euro. Alleen ben je er dan nog niet. Onderliggend moet je netwerk nog solide zijn, iemand moet het aanschaffen, inkopen, testen, stress-testen, plaatsen, implementeren en dan ben je er pas.
Natuurlijk zijn hier optimalisaties in te maken van "TTL" maar soms duurt dit domweg 1 maand, in wat grotere "corporate" meuk kan dit net zo goed 2-3-6 maanden duren. Dan heb je een dikke kosten post voor de totale storage gemaakt, waar je initieel dan nog maar 1% van gebruikt. Dat doet soms zeer.
Uiteindelijk is er geen magische oplossing met alleen maar voordelen. Dat is gewoon een gegeven. Zowel de cloud, onprem als hybrid hebben allemaal hun nadelen
Natuurlijk zijn hier optimalisaties in te maken van "TTL" maar soms duurt dit domweg 1 maand, in wat grotere "corporate" meuk kan dit net zo goed 2-3-6 maanden duren. Dan heb je een dikke kosten post voor de totale storage gemaakt, waar je initieel dan nog maar 1% van gebruikt. Dat doet soms zeer.
Uiteindelijk is er geen magische oplossing met alleen maar voordelen. Dat is gewoon een gegeven. Zowel de cloud, onprem als hybrid hebben allemaal hun nadelen
https://www.macrumors.com...-developer-tools-windows/
Apple Metal Developer Tools uitgegeven voor Windows 10, hopelijk helpt dit met meer spelletjes voor de Mac
Hebben mensen hier al gewerkt met Apple Metal en is het wat? Of loop je liever met een grote boog omheen? Ik begreep dat de OpenGL ondersteuning op de Mac achterloopt?
Apple Metal Developer Tools uitgegeven voor Windows 10, hopelijk helpt dit met meer spelletjes voor de Mac
@alienfruit Ik hoop met je mee, maar met de switch naar ARM en het verwijderen van 32-bit-ondersteuning heb ik eerder het gevoel dat er minder spellen voor macOS gaan komen dan meer.
[ Voor 3% gewijzigd door Koenvh op 13-07-2020 15:11 ]
🠕 This side up
Waarom zou dat uitmaken?Koenvh schreef op maandag 13 juli 2020 @ 15:11:
maar met de switch naar ARM en het verwijderen van 32-bit-ondersteuning heb ik eerder het gevoel dat er minder spellen voor macOS gaan komen dan meer.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Als iemand een spel maakt in Unity, en daar een plugin gebruikt die wel werkte on macOS, maar niet geüpdatet is voor ARM (of 64-bit), dan werkt 't niet. En vaak is de macOS-doelgroep niet groot genoeg om daar dan omheen te werken. Plus daarbij komen natuurlijk alle spellen voor macOS die 32-bit waren, maar waar de ontwikkelaar geen moeite meer wil steken in een update voor de nieuwe versie van macOS.
🠕 This side up
Ik zit niet zo in de Unity wereld, maar hoeveel spellen zijn afhankelijk van 3rd party *binaries*?
En het niet supporten van 32 bits, gaat dat niet alleen over native x86-64? Als je x86 toch al gaat emuleren, waarom zou je 32-bits code dan niet supporten?
En het niet supporten van 32 bits, gaat dat niet alleen over native x86-64? Als je x86 toch al gaat emuleren, waarom zou je 32-bits code dan niet supporten?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ask Apple. Zodra een applicatie 32-bits is krijg je op Catalina een foutmelding. Daarom zie je bij een aantal spelen in Steam dat het niet werkt onder MacOS 10.15 (Catalina)..oisyn schreef op maandag 13 juli 2020 @ 15:29:
Ik zit niet zo in de Unity wereld, maar hoeveel spellen zijn afhankelijk van 3rd party *binaries*?
En het niet supporten van 32 bits, gaat dat niet alleen over native x86-64? Als je x86 toch al gaat emuleren, waarom zou je 32-bits code dan niet supporten?
Hier ook niet bekend met Unity, maar ik heb net even snel wat lopen bladeren in de Asset Store en vond een paar betaalde plugins die gewoon met source-bestanden (*.cs) worden geleverd. Lijkt me dus geen issue..oisyn schreef op maandag 13 juli 2020 @ 15:29:
Ik zit niet zo in de Unity wereld, maar hoeveel spellen zijn afhankelijk van 3rd party *binaries*?
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Lees nu mijn reactie nog eens.Vincentio schreef op maandag 13 juli 2020 @ 16:08:
[...]
Ask Apple. Zodra een applicatie 32-bits is krijg je op Catalina een foutmelding. Daarom zie je bij een aantal spelen in Steam dat het niet werkt onder MacOS 10.15 (Catalina).
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Toevallig ken ik veel game devs en mensen in video/film & audio voor film en kan je zeggen dat alles vooral cheap & fast moet en de meeste mensen ook accordingly worden betaald. Dus ja, al zouden ze geweldig mooie nieuwe dingen willen maken, ze grijpen toch naar laaghangend fruit en engines en zo min mogelijk (extra) werk voor een zo groot mogelijke markt. Dus hoewel het ‘simpel’ is om sommige dingen te converteren zijn tijd en geld de factoren die dat meestal in de weg zitten.
In de wereld van indie unity based games wordt er veel aan window dressing gedaan; elke game is al jaren hetzelfde alleen wat andere graphics en audio samples.
In de wereld van indie unity based games wordt er veel aan window dressing gedaan; elke game is al jaren hetzelfde alleen wat andere graphics en audio samples.
Dat klinkt als de casual games markt. Games die voor een paar euro of minder in de app stores worden gezet om snel voor een IP licentie wat extra geld binnen te harken.Wilf schreef op maandag 13 juli 2020 @ 16:45:
In de wereld van indie unity based games wordt er veel aan window dressing gedaan; elke game is al jaren hetzelfde alleen wat andere graphics en audio samples.
Dat gebeurd al jaren, voor snes en gameboy had je al aardig wat van dat soort titels. Even wat andere gfx/sfx erin en hop weer een cartridge voor in de winkels. Alleen nu de distributie niet zo duur meer is moeten de games nog goedkoper worden geproduceerd. Uitknijpen aan de onderkant, bij dev studio's dus.
Driving a cadillac in a fool's parade.
@kwaakvaak_v2 Ook heb je tegenwoordig veel meer kleine ontwikkelaars. Als twee personen manusjes van alles zijn (geluid, grafisch, gameplay, logica, verhaal, etc. etc.), dan is de kans ook groter dat ze vooral programmeren "zodat het werkt", en gewoon bestaande raamwerken gebruiken. De meeste spellen zijn nu ook weer niet zo baanbrekend.
Tenminste, ik vraag me af of iets als Adventure Game Studio ook al kan compilen voor macOS Catalina.
Tenminste, ik vraag me af of iets als Adventure Game Studio ook al kan compilen voor macOS Catalina.
🠕 This side up
Je denkt toch niet dat er geen Unity versie gaat komen voor ARM macs he?Koenvh schreef op maandag 13 juli 2020 @ 15:24:
[...]
Als iemand een spel maakt in Unity, en daar een plugin gebruikt die wel werkte on macOS, maar niet geüpdatet is voor ARM (of 64-bit), dan werkt 't niet. En vaak is de macOS-doelgroep niet groot genoeg om daar dan omheen te werken. Plus daarbij komen natuurlijk alle spellen voor macOS die 32-bit waren, maar waar de ontwikkelaar geen moeite meer wil steken in een update voor de nieuwe versie van macOS.

100% garantie op arm compatible plugins en een vlekkeloze extra compile target lijkt me dan ook weer een grote aanname. 
Hint: we gaan t meemaken.
Hint: we gaan t meemaken.
{signature}
Ik vond het juist vaak wel bizar om te zien hoe vroeger één of een paar personen een hele game in korte tijd uit de grond stampten zonder engines en andere ongein. Volgens mij heeft Chris Sawyer bv transport Tycoon ook gewoon zo ongeveer in zijn eentje gebouwd.Koenvh schreef op maandag 13 juli 2020 @ 18:04:
@kwaakvaak_v2 Ook heb je tegenwoordig veel meer kleine ontwikkelaars. Als twee personen manusjes van alles zijn (geluid, grafisch, gameplay, logica, verhaal, etc. etc.), dan is de kans ook groter dat ze vooral programmeren "zodat het werkt", en gewoon bestaande raamwerken gebruiken. De meeste spellen zijn nu ook weer niet zo baanbrekend.
Tenminste, ik vraag me af of iets als Adventure Game Studio ook al kan compilen voor macOS Catalina.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Gebeurt nog steeds wel. Cave Story is bijv. door 1 persoon gemaakt.Mugwump schreef op maandag 13 juli 2020 @ 18:33:
[...]
Ik vond het juist vaak wel bizar om te zien hoe vroeger één of een paar personen een hele game in korte tijd uit de grond stampten zonder engines en andere ongein.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
IMO waren dat wel ook de top mensen in hun vak, en de tijden zijn veranderd. Tegenwoordig zijn de "eisen en vereisten" van een game totaal anders geworden.Mugwump schreef op maandag 13 juli 2020 @ 18:33:
[...]
Ik vond het juist vaak wel bizar om te zien hoe vroeger één of een paar personen een hele game in korte tijd uit de grond stampten zonder engines en andere ongein. Volgens mij heeft Chris Sawyer bv transport Tycoon ook gewoon zo ongeveer in zijn eentje gebouwd.
Er zijn nog genoeg van dat soort games die door 1 persoon zijn gemaakt. Of dit nu met of zonder een engine/framework is.
Ik had een jaar terug ook iemand 'gebacked' (heet dat zo? kickstarter
Gebackt
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Natuurlijk, je kunt hedendaagse games met open werelden met bizar veel details en verhaallijnen ook niet vergelijken met dat soort games.Douweegbertje schreef op maandag 13 juli 2020 @ 19:59:
[...]
IMO waren dat wel ook de top mensen in hun vak, en de tijden zijn veranderd. Tegenwoordig zijn de "eisen en vereisten" van een game totaal anders geworden.
Er zijn nog genoeg van dat soort games die door 1 persoon zijn gemaakt. Of dit nu met of zonder een engine/framework is.
Ik had een jaar terug ook iemand 'gebacked' (heet dat zo? kickstarter) voor een game. De beste meneer had gespaard en ging vervolgens reizen. Eigenlijk naar landen waar het allemaal niet zo duur is. In de hostels e.d. werkte hij aan de game. Zo kon hij het 3-4 jaar uithouden zonder noemenswaardige investeringen.
En ja vandaag de dag zijn er ook eenmansprojecten,
Maar toch is het van een ander niveau. Sawyer heeft bijvoorbeeld Rollercoaster Tycoon ook zo ongeveer in zijn eentje in elkaar geklopt, vrijwel volledig in Assembly.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Lees nog 'nsPrisonerOfPain schreef op maandag 13 juli 2020 @ 18:19:
[...]
Je denkt toch niet dat er geen Unity versie gaat komen voor ARM macs he?
Oh ja, het kan zeker, maar het is wel een minderheid geloof ik.Mugwump schreef op maandag 13 juli 2020 @ 18:33:
[...]
Ik vond het juist vaak wel bizar om te zien hoe vroeger één of een paar personen een hele game in korte tijd uit de grond stampten zonder engines en andere ongein. Volgens mij heeft Chris Sawyer bv transport Tycoon ook gewoon zo ongeveer in zijn eentje gebouwd.
🠕 This side up
Gebak lijkt vandaag beter op zijn plaats
Proficiat!
If money talks then I'm a mime
If time is money then I'm out of time
Dat gebeurt nog steeds wel. En grafisch en kwa gameplay zijn die games dan ongeveer te vergelijken met een game als TT. En natuurlijk is er ook OpenTTD. Maar je gaat het echt niet zien gebeuren dat mensen een open source versie van triple-A games gaan maken; die zijn gewoon te 'groot'.Mugwump schreef op maandag 13 juli 2020 @ 18:33:
Ik vond het juist vaak wel bizar om te zien hoe vroeger één of een paar personen een hele game in korte tijd uit de grond stampten zonder engines en andere ongein. Volgens mij heeft Chris Sawyer bv transport Tycoon ook gewoon zo ongeveer in zijn eentje gebouwd.
https://niels.nu
Klopt, ik volg al geruime tijd de devlog van YouTube: Lumbermill Devlog - YouTubeHydra schreef op dinsdag 14 juli 2020 @ 08:18:
Dat gebeurt nog steeds wel. En grafisch en kwa gameplay zijn die games dan ongeveer te vergelijken met een game als TT. En natuurlijk is er ook OpenTTD. Maar je gaat het echt niet zien gebeuren dat mensen een open source versie van triple-A games gaan maken; die zijn gewoon te 'groot'.
Daarin kun je perfect zien hoeveel werk het is een daarbij baseert hij zich ook nog eens op Unity framework.
Wel mooi om te zien, maar inderdaad niet realistisch om een one-man game te verwachten. Daarnaast krijg ik het gevoel dat grote uitgevers al snel de potentie proeven en dan de rechten overnemen voor een som geld dat voor een eenling behoorlijk is, maar als investeringsbudget minimaal voor een bedrijf.
If money talks then I'm a mime
If time is money then I'm out of time
Mooi, want dan kan ik gewoon blijven gamen op mijn laptop met intel HD graphics uit 2013.Hydra schreef op dinsdag 14 juli 2020 @ 08:18:
[...]
Dat gebeurt nog steeds wel. En grafisch en kwa gameplay zijn die games dan ongeveer te vergelijken met een game als TT. En natuurlijk is er ook OpenTTD.
Spelunky en stardew valley zijn ook mooie voorbeelden van spellen gemaakt door een enkel persoon. Qua kwaliteit gaan ook dat soort games vooruit ten opzichte van RCT - gameplay, maar de hoeveelheid content valt ook niet bepaald tegen.
Heeft geen speciale krachten en is daar erg boos over.
Heb je hand made hero ook wel eens gekeken? Ik meen me te herinneren dat hij zelfs in het begin zijn eigen software renderer schreef... YouTube: Handmade Hero Day 618 - Analyzing the Diffuse BlurMatis schreef op dinsdag 14 juli 2020 @ 09:44:
[...]
Klopt, ik volg al geruime tijd de devlog van YouTube: Lumbermill Devlog - YouTube
Daarin kun je perfect zien hoeveel werk het is een daarbij baseert hij zich ook nog eens op Unity framework.
Nee, nog niet. Bedankt voor de tip. Ondanks dat het helemaal niet mijn gebied is qua software ontwikkeling vind ik het altijd fascinerend hoe ze te werk gaan.ruuds schreef op woensdag 15 juli 2020 @ 12:02:
Heb je hand made hero ook wel eens gekeken? Ik meen me te herinneren dat hij zelfs in het begin zijn eigen software renderer schreef... YouTube: Handmade Hero Day 618 - Analyzing the Diffuse Blur
If money talks then I'm a mime
If time is money then I'm out of time
Requirements aan het doornemen voor een potentiele klant van ons product:
Even een stukje eruit (niet letterlijk):
Even een stukje eruit (niet letterlijk):
Ok. I don't even...- Eis: Role-based rechtenstructuur om risico op ongeautoriseerde wijzigingen te beperken
- Eis: Mogelijkheid om middels een header, cookie of een 'speciaal' wachtwoord de rechtenstructuur te omzeilen.
Engineering is like Tetris. Succes disappears and errors accumulate.
Ik lees:armageddon_2k1 schreef op woensdag 15 juli 2020 @ 13:07:
Requirements aan het doornemen voor een potentiele klant van ons product:
Even een stukje eruit (niet letterlijk):
[...]
Ok. I don't even...
- Eis: Rechtenstructuur gebaseerd op rollen, waarbij autorisaties op rol nieau niet te omzeilen zijn
- Eis: Mogelijkheid tot 'volledige toegang' (m.a.w. een rol die alles mag en waarvoor je een gebruiker aan kan maken).
Resultaat is immers hetzelfde:
- Een rol met bepaalde basisrechten kan ook alleen die beperkte set aan wijzigingen doen
- Een rol met alle rechten kan alles doen, er moet alleen een account voor gemaakt worden.
Voordeel is:
- Het is geen achterdeurtje die misbruikt kan worden
- Klant zijn verwachtingen zijn waargemaakt
- Gaat er iets mis (is 'inrichting van rollen/ autorisaties en accounts), dan heeft niet iemand het achterdeurtje gevonden, maar is dat op basis van een account gebeurt en krijgt de software niet de schuld.
(de precieze tekst weet ik niet, maar ik ken dergelijke teksten wel. Eigenlijk stellen ze dat het veilig moet zijn, maar het eigenlijk schijnveiligheid is omdat ze een backdoor willen. Ben zelf altijd weggekomen met deze uitwerking;
Klinkt inderdaad gewoon als een administrator account die simpelweg alle rollen heeft.
Ja dat snap ik ook wel :-) Gewoon een rol die van alles kan.
Maar ik vind het verbazend dat een klant letterlijk een backdoor eis voor een public facing applicatie.
Maar een admin account is wel iets anders dan een cookie instellen zodat je eromheen kan.
Maar ik vind het verbazend dat een klant letterlijk een backdoor eis voor een public facing applicatie.
Maar een admin account is wel iets anders dan een cookie instellen zodat je eromheen kan.
Engineering is like Tetris. Succes disappears and errors accumulate.
Jup, maar ze geven ook de optie van "speciaal wachtwoord", wat je dan simpelweg kan ombuigen naar een specifiek account met dat "speciale wachtwoord"
Al zou ik dan wel ook de mogelijkheid voor 2factor-auth suggereren zodat het wachtwoord alleen niet genoeg is.
Al zou ik dan wel ook de mogelijkheid voor 2factor-auth suggereren zodat het wachtwoord alleen niet genoeg is.
[ Voor 27% gewijzigd door hackerhater op 15-07-2020 13:17 ]
Idd, is bij onze software verplicht voor admin-accounts, organisatie kan iedereen middels 2FA in laten loggen, of alleen admins, maar admins te allen tijde.hackerhater schreef op woensdag 15 juli 2020 @ 13:16:
Jup, maar ze geven ook de optie van "speciaal wachtwoord", wat je dan simpelweg kan ombuigen naar een specifiek account met dat "speciale wachtwoord"
Al zou ik dan wel ook de mogelijkheid voor 2factor-auth suggereren zodat het wachtwoord alleen niet genoeg is.
Daar huren ze je/het bedrijf voor in. Om een technisch haalbare oplossing te bieden voor de vraag die ze hebben. Zie niet zoveel mis met de eisen.
Oplossing: met een cookie "haha" krijg je helemaal geen toegang meer. Rechtenstructuur omzeildarmageddon_2k1 schreef op woensdag 15 juli 2020 @ 13:07:
Requirements aan het doornemen voor een potentiele klant van ons product:
Even een stukje eruit (niet letterlijk):
[...]
Ok. I don't even...
🠕 This side up
Stelletje nerds. Die tweede eis is duidelijk als backdoor verwoord, inclusief het woord ‘omzeilen’. Dat iedereen hier een admin account/role kan bedenken is geen verrassing, maar ik zou toch benieuwd zijn of klant het in 1x snapt. Met zo’n woordkeuze is er natuurlijk wel iets mis.
{signature}
Ach als er dan ooit een security issue is, kun je in iedergeval laten zien dat het geheel volgens spec is
Omdat je weet dat het misgaat, kan je het speciale wachtwoord ook ‘CVE-2021-0001’ maken. Cynisch, recursief en zelfdocumenterend, wat wil je nog meer.
{signature}
Zou het CVE nummer dan al wel gelijk even laten reserveren 
Zouden ze bij twitter dezelfde ACL toepassen (gezien de geruchten van gehackte accounts) ?
Zouden ze bij twitter dezelfde ACL toepassen (gezien de geruchten van gehackte accounts) ?
[ Voor 43% gewijzigd door gekkie op 15-07-2020 23:19 ]
Omdat dat stukje niet letterlijk overgenomen was: is het zeker dat ze dat omzeilen niet willen op een testomgeving? Dan ga ik er wel even van uit dat ze een testomgeving willen. In dat geval kan ik mij voorstellen dat ze de security willen omzeilen om het testen gemakkelijker te maken voor ofwel hun mensen (geen gedoe met testaccounts/rechten voor elke basale test), ofwel hun tooling (geen fatsoenlijke ondersteuning voor authenticatie/geen zin of budget om uit te zoeken hoe hun testtooling daarmee om kan).
Daar staat feitelijk toch gewoon het volgende?armageddon_2k1 schreef op woensdag 15 juli 2020 @ 13:07:
Requirements aan het doornemen voor een potentiele klant van ons product:
Even een stukje eruit (niet letterlijk):
[...]
Ok. I don't even...
- Maak een admin role die alle rechten heeft
- Gebruik oauth om een access token te genereren
- Geef token mee in een header
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
You're not wrong.
Maar ik triggerde meer op het woord 'omzeilen' ;-)
Maar ik triggerde meer op het woord 'omzeilen' ;-)
Engineering is like Tetris. Succes disappears and errors accumulate.
Buiten productie een trucje toestaan.. tja kan. Je maakt wel een hoop aannames en ik ben wat pessimistisch over de waarde van zo’n functionaliteit: Als je actierechten negeert, kan je niet beoordelen of links die anders niet getoond worden er al dan foutief altijd staan. Als je objectrechten negeert, vertrouw je er misschien op dat het teveel aan data wel goed komt, maar merk je niet als een controle mist en zit je met een datalek etc etc.Giesber schreef op donderdag 16 juli 2020 @ 09:46:
In dat geval kan ik mij voorstellen dat ze de security willen omzeilen om het testen gemakkelijker te maken voor ofwel hun mensen (geen gedoe met testaccounts/rechten voor elke basale test), ofwel hun tooling (geen fatsoenlijke ondersteuning voor authenticatie/geen zin of budget om uit te zoeken hoe hun testtooling daarmee om kan).
Ik ben niet happig op uitzonderingen, zeker als ze het makkelijk maken om in de security sfeer iets over het hoofd te zien. En tooling die niet om kan gaan met sessies zie ik al snel als beperkte waarde. Ik werk liever van tevoren iets langzamer maar vervolgens secuur.
Dit allemaal zeer hypothetisch, maar van shortcuts in deze sfeer heb ik te vaak spijt gekregen.
{signature}
Hebben jullie nog last gehad van de Cloudflare downtime?
https://blog.cloudflare.c...e-outage-on-july-17-2020/
https://blog.cloudflare.c...e-outage-on-july-17-2020/
🠕 This side up
Ja
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Wat denken jullie over de toekomst van programmeren?
Ik denk dat er in de toekomst alleen systeem programmeurs over blijven.
Front-end + business logica gaat verdwijnen. Custom klantoplossingen worden gedaan door de klant zelf door systemen die geprogrammeerd zijn door systeem programmeurs.
Hoe? Ik denk omdat AI een deel van de programmeurs gaat vervangen als je dingen zoals dit ziet:
De nieuwste AI model van OpenAI genaamd GPT-3 kan echt ziek veel, en met een gigantische hoge correctheid. GPT-3 is voornamelijk gemaakt om tekst te genereren, en om tekst te begrijpen e.d.
En ja ook tekst als een programmeertaal.
Hij kan o.a. python programmeren op basis van requirements in menselijke taal:
Of HTML met CSS programmeren op basis van requirements in menselijke taal:
https://twitter.com/sharifshameem/status/1282676454690451457
Gaat nog leuk worden met AI.
Wie is er al bang om zijn baan te verliezen?
Ik denk dat er in de toekomst alleen systeem programmeurs over blijven.
Front-end + business logica gaat verdwijnen. Custom klantoplossingen worden gedaan door de klant zelf door systemen die geprogrammeerd zijn door systeem programmeurs.
Hoe? Ik denk omdat AI een deel van de programmeurs gaat vervangen als je dingen zoals dit ziet:
De nieuwste AI model van OpenAI genaamd GPT-3 kan echt ziek veel, en met een gigantische hoge correctheid. GPT-3 is voornamelijk gemaakt om tekst te genereren, en om tekst te begrijpen e.d.
En ja ook tekst als een programmeertaal.
Hij kan o.a. python programmeren op basis van requirements in menselijke taal:
Of HTML met CSS programmeren op basis van requirements in menselijke taal:
https://twitter.com/sharifshameem/status/1282676454690451457
Gaat nog leuk worden met AI.
[ Voor 9% gewijzigd door Immutable op 20-07-2020 11:41 ]
Immutable schreef op maandag 20 juli 2020 @ 11:37:
Wat denken jullie over de toekomst van programmeren?
Ik denk dat er in de toekomst alleen systeem programmeurs over blijven.
Front-end + business logica gaat verdwijnen. Custom klantoplossingen worden gedaan door de klant zelf door systemen die geprogrammeerd zijn door systeem programmeurs.
Hoe? Ik denk omdat AI een deel van de programmeurs gaat vervangen als je dingen zoals dit ziet:
De nieuwste AI model van OpenAI genaamd GPT-3 kan echt ziek veel, en met een gigantische hoge correctie.
Hij kan o.a. python programmeren op basis van requirements in menselijke taal:
[YouTube: OpenAI Model Generates Python Code]
Of HTML met CSS programmeren op basis van requirements in menselijke taal:
https://twitter.com/sharifshameem/status/1282676454690451457
Gaat nog leuk worden met AI.
Ik heb in de twintig jaar dat ik programmeer al zoveel beloftes gehoord waardoor er geen developers meer nodig zouden zijn...
Grappig dat een "AI" het woord "palindrome" kan herkennen en uit een of andere databank daar de template-code voor kan uitpoepen, maar dat betekent volgens mij niet dat we binnen afzienbare tijd programmeurs vaarwel kunnen zeggen.
Bij de eerste klant die typt "Ik wil een blauwe homepage... Nee, nog iets blauwer" hangt de AI zichzelf op.
En sowieso zijn er natuurlijk tien miljoen miljard andere interessanter zaken om aan te programmeren dan de UI van een webapp, en ik voorzie niet hoe een AI dat zou kunnen oplossen. Maar misschien ben ik daar gewoon niet intelligent genoeg voor.
En taal interpreteren is een bijzonder moeilijke opgave. Dus stel die AI zou echt zo slim zijn, dan moet je dus gestudeerd hebben op de taal die die AI slikt. Dus in plaats van debuggen, ga je de zinnen die je dat appraat voert zorgvuldig finetunen tot het juiste resultaat eruit komt... Dan zit ik liever in m'n IDE met unittests en een debugger.
[ Voor 16% gewijzigd door CodeCaster op 20-07-2020 11:47 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Ik begon een kleine 20 jaar geleden met mijn studie Technische Informatica. Ik herinner me nog dat er destijds een open dag was voor de ouders waarbij haast verontschuldigend werd gezegd dat er inderdaad ook programmeervakken werden gegeven, maar dat dit puur was omdat studenten dit zouden moeten snappen. Dat programmeren zelf ging natuurlijk gewoon verdwijnen als baan in Nederland. Nou, dat hebben we gezien.CodeCaster schreef op maandag 20 juli 2020 @ 11:42:
[...]
Ik heb in de twintig jaar dat ik programmeer al zoveel beloftes gehoord waardoor er geen developers meer nodig zouden zijn...
Grappig dat een "AI" het woord "palindrome" kan herkennen en uit een of andere databank daar de template-code voor kan uitpoepen, maar dat betekent volgens mij niet dat we binnen afzienbare tijd programmeurs vaarwel kunnen zeggen.
Bij de eerste klant die typt "Ik wil een blauwe homepage... Nee, nog iets blauwer" hangt de AI zichzelf op.
En sowieso zijn er natuurlijk tien miljoen miljard andere interessanter zaken om aan te programmeren dan de UI van een webapp, en ik voorzie niet hoe een AI dat zou kunnen oplossen. Maar misschien ben ik daar gewoon niet intelligent genoeg voor.
Ik denk ook dat de capaciteiten van AI schromelijk worden overschat. Dokters, advocaten, software developers, iedereen is binnenkort overbodig als onze AI overlords aan de macht komen als je de doemdenkers mag geloven. Als je echter kijkt naar de realiteit, dan valt het allemaal nog wel tegen. De veelgehypte technologie voor analyse van rontgenfoto's om bijvoorbeeld tumoren te detecteren deed het prachtig in een geïdealiseerde laboratoriumopzet, maar toen deze in de praktijk werd ingezet viel het nog wel aardig tegen. En dan is het herkennen van een tumor op een foto nog maar een heel klein subtaakje van wat een medisch specialist doet. Hetzelfde geldt voor software development. En vergeet niet, er zijn natuurlijk al decennia allerlei 'low-code' platformen. Met een paar clickjes zou een relatieve leek al een applicatie in elkaar moeten kunnen knutselen, maar in de praktijk valt dat kennelijk toch tegen, want het tekort en de vraag lijkt alleen maar toe te nemen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Met het kleine beetje kennis dat ik van AI en machine learning heb, durf ik wel te zeggen dat het een prima tool is in bepaalde gevallen. Patronen herkennen die mensen niet waren opgevallen, informatie inter- of extrapoleren en dingen voorspellen met een bepaalde waarschijnlijkheid.Mugwump schreef op maandag 20 juli 2020 @ 11:59:
[...]
Ik begon een kleine 20 jaar geleden met mijn studie Technische Informatica. Ik herinner me nog dat er destijds een open dag was voor de ouders waarbij haast verontschuldigend werd gezegd dat er inderdaad ook programmeervakken werden gegeven, maar dat dit puur was omdat studenten dit zouden moeten snappen. Dat programmeren zelf ging natuurlijk gewoon verdwijnen als baan in Nederland. Nou, dat hebben we gezien.
Ik denk ook dat de capaciteiten van AI schromelijk worden overschat. Dokters, advocaten, software developers, iedereen is binnenkort overbodig als onze AI overlords aan de macht komen als je de doemdenkers mag geloven. Als je echter kijkt naar de realiteit, dan valt het allemaal nog wel tegen. De veelgehypte technologie voor analyse van rontgenfoto's om bijvoorbeeld tumoren te detecteren deed het prachtig in een geïdealiseerde laboratoriumopzet, maar toen deze in de praktijk werd ingezet viel het nog wel aardig tegen. En dan is het herkennen van een tumor op een foto nog maar een heel klein subtaakje van wat een medisch specialist doet. Hetzelfde geldt voor software development. En vergeet niet, er zijn natuurlijk al decennia allerlei 'low-code' platformen. Met een paar clickjes zou een relatieve leek al een applicatie in elkaar moeten kunnen knutselen, maar in de praktijk valt dat kennelijk toch tegen, want het tekort en de vraag lijkt alleen maar toe te nemen.
Maar als ik dan over die GPT-3 lees dat 'ie één woord vooruit voorspelt, dus dat bijvoorbeeld als het onderwerp van een gesprek "ogen" is, dat de kans zo'n 95% is dat het volgende woord na "twee" daadwerkelijk "ogen" is, dan vraag ik me echt af waar die onderzoekers hun tijd aan aan het besteden zijn. Maar dat zal ook wel weer een versimpeling van de werkelijkheid zijn.
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Oh zeker, patroonherkenning is absoluut een interessante toepassing. Net als bijvoorbeeld evolutionaire algoritmen hele interessante nieuwe ontwerpen kunnen opleveren. Sterker nog, het is alweer 14 jaar geleden dat NASA bijvoorbeeld dat soort algoritmen ontwerpen lieten doen (bron). Zitten alle werktuigbouwkundigen inmiddels werkloos thuis? Volgens mij niet.CodeCaster schreef op maandag 20 juli 2020 @ 12:03:
[...]
Met het kleine beetje kennis dat ik van AI en machine learning heb, durf ik wel te zeggen dat het een prima tool is in bepaalde gevallen. Patronen herkennen die mensen niet waren opgevallen, informatie inter- of extrapoleren en dingen voorspellen met een bepaalde waarschijnlijkheid.
Maar als ik dan over die GPT-3 lees dat 'ie één woord vooruit voorspelt, dus dat bijvoorbeeld als het onderwerp van een gesprek "ogen" is, dat de kans zo'n 95% is dat het volgende woord na "twee" daadwerkelijk "ogen" is, dan vraag ik me echt af waar die onderzoekers hun tijd aan aan het besteden zijn.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Generative Engineering word al heel veel gebruikt hoor in de mechanica. Hierbij wordt inderdaad evolutionaire algoritmen gebruikt om snel heel veel iteretaties te doen om sneller naar een redelijk optimaal punt te komen in plaats van brute force wat veel te lang duurt. Dit wordt ook gedaan bij trading algoritmen af te regelen van de parameters.Mugwump schreef op maandag 20 juli 2020 @ 12:07:
[...]
Oh zeker, patroonherkenning is absoluut een interessante toepassing. Net als bijvoorbeeld evolutionaire algoritmen hele interessante nieuwe ontwerpen kunnen opleveren. Sterker nog, het is alweer 14 jaar geleden dat NASA bijvoorbeeld dat soort algoritmen ontwerpen lieten doen (bron). Zitten alle werktuigbouwkundigen inmiddels werkloos thuis? Volgens mij niet.
AutoDesk is hier al heel erg hard mee aan de weg aan het timmeren. Het is springlevend.
Daarnaast was mijn vorige post wel erg provocerend (met opzet) om reactie uit te lokken.
Het moet eigenlijk een soort interface worden tussen mens en machine, waarbij de machine ons kan begrijpen door onze gewone menselijke taal te gebruiken. Google nu zoekt een antwoord op, GTP-3 genereerd een antwoord. https://twitter.com/paraschopra/status/1284801028676653060
Er zijn zelfs al ideeen om GTP-3 in visual studio code te implementeren om jou als programmeur te helpen programmeren.
Maar hebben jullie dan wel eens een AI gezien die dit soort "menselijke" tekst kan begrijpen en om kan zetten tot GUI + Logica ?? Is hier dan niemand die hier van onder de indruk is???
https://twitter.com/sharifshameem/status/1284815412949991425
Of gewoon je applicatie beschrijven, bijvoorbeeld een Todo app, en hij genereert gewoon de gehele code:
https://twitter.com/sharifshameem/status/1284421499915403264
[ Voor 14% gewijzigd door Immutable op 20-07-2020 12:23 ]
Mjah dat is een nogal belangrijk deel statistiek voor het hele language processing gebeuren.CodeCaster schreef op maandag 20 juli 2020 @ 12:03:
Maar als ik dan over die GPT-3 lees dat 'ie één woord vooruit voorspelt, dus dat bijvoorbeeld als het onderwerp van een gesprek "ogen" is, dat de kans zo'n 95% is dat het volgende woord na "twee" daadwerkelijk "ogen" is, dan vraag ik me echt af waar die onderzoekers hun tijd aan aan het besteden zijn. Maar dat zal ook wel weer een versimpeling van de werkelijkheid zijn.
Het language model wat inderdaad de automagisch gegenereerde statistiek is van if this dan waarschijnlijk dat,
zorgt er voor dat bijvb nogal wat speech to text neural networks, nog enigzins acceptabele resultaten halen.
Zonder dat language model presteren de meeste toch nog wel matig. (nadeel is dat dingen buiten de woordenschat dan ook al snel een probleem zijn, wat in het Nederlands en Duits met het combineren van woorden tot de meest spannende combinaties wel een probleem vormen.
Overigens ook in de gebruikte metrics zoals de "word error rate", waarbij een spatie tussen een samengesteld woord gelijk een absurd hoge word-error-rate op weet te leveren).
Ik vind het vooral fascinerend dat je met de pattern-matching en een berg statistiek je toch al een eind kunt komen in de wereld. Op zich misschien ook weer niet zo vreemd, een fruitvlieg komt ook best een eind (en soms iets te ver ..).
Dit topic is gesloten.
Let op:
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.