Microsoft geeft beheerders meer opties voor updaten Microsoft 365 Apps

Microsoft heeft nieuwe opties toegevoegd aan Servicing Profiles waarmee beheerders meer controle krijgen over het updaten van Microsoft 365 Apps via Azure Active Directory. Zo is terugtrekken per groep mogelijk en kunnen apparaten worden uitgesloten.

Microsoft heeft in totaal vijf nieuwe beheeropties voor Servicing Profiles toegevoegd. Met Wave Customization kunnen beheerders het vrijgeven van de maandelijkse updates in maximaal drie golven spreiden naar groepen van apparaten. Rollback by Groups maakt het terugtrekken van updates mogelijk en dient zo als vangnet.

Ook is er een optie bijgekomen om apparaten uit te sluiten van geautomatiseerde updates en kunnen beheerders voortaan met een enkele eenvoudige configuratie alle apparaten tegelijk bedienen met updates. Ten slotte zijn de profielen uitgebreid met een beheertool om de schijfruimte voor updates aan te passen. Minimaal is 5GB vrije schijfruimte vereist, maar deze optie laat beheerders lagere limieten instellen.

Volgens Microsoft gaat het om functies die veel gevraagd werden door beheerders. Microsoft heeft Servicing Profiles toegevoegd aan het Apps Admin Center van Microsoft 365 om beheerders controle te geven over het updateprocedé. Als ze binnen organisaties Microsoft 365 Apps een update geven en er ontstaan problemen op apparaten van werknemers, kunnen ze de updates bijvoorbeeld pauzeren.

Beheerders konden al instellen dat updates alleen gaan naar apparaten die Microsoft 365 in bepaalde updatekanalen draaiden. Apps op apparaten die in het Monthly Enterprise Channel zitten, krijgen zo als eerste de updates. Als alternatief konden ze zich al met updates op specifieke apparaten binnen Azure AD-groepen richten.

Reacties (30)

[FateTrap]

We hadden op ons werk Excel via Microsoft 365 om CSV bestanden te bewerken. Maar wat ik gemerkt heb is dat Gnumeric veel sneller was om basisbewerkingen te doen op grote CSV bestanden, meer functies ondersteunt dan Excel, accuratere resultaten geeft bij berekeningen met grote getallen, en ook gratis is.

Onze systeembeheerder heeft enkele weken geleden alle workstations laten overschakelen naar Gnumeric en PostgreSQL en zo zijn we veel productiever geworden want SQL is in veel gevallen eveneens sneller, krachtiger en compacter dan Excel bestanden.

[Blokker_1999]

Dan heb je het vermoedelijk niet over Excel, de office applicatie, maar Excel de browser applicatie daar Gnumeric niet werkt op Windows en officieel ook niet meer ondersteund is sinds 2014. Dit geeft voor mij aan dat jullie ofwel een systeembeheerder hebben die avontuurlijk durft zijn, wat soms ten koste gaat van de productiviteit wanneer het misloopt, of dat jullie reeds Linux (of een andere *nix) draaien en dus helemaal niet het type gebruiker zijn dat van MS 365 gebruik maakt.

En dat bewerkingen in een browser op grote bestanden trager gaan dan in een native desktop client mag ook niet verbazen. Doe eens hetzelfde op een Windows machine met een echte Excel client, kans is groot dat je het verschil niet merkt. En een spreadsheet is geen database. Wat Postgres er mee te maken heeft snap ik dus al helemaal niet. Je gaat niet kiezen voor een complexe applicatie voor 1 eenvoudige taak lijkt mij.

[davekok]

Of ze zitten al op Windows 11 met WSLg

[FateTrap]

We gebruiken Oracle Linux. In onze ervaring heeft het uitstekende veiligheid, prestaties en stabiliteit. Het is nog geen enkele keer misgelopen en ik denk dat we het daarom ook gebruiken.

We hadden een computer met dual-boot Linux en windows. Op de Linux partitie stond Gnumeric en op de windows partitie stond Excel. Bij hetzelfde CSV bestand duurde het 4 seconden om +- 60 000 rijen te rangschikken. In Excel duurt dezelfde taak 13 seconden. Dat is iedere keer 9 seconden dat we verliezen bij het rangschikken van de rijen. Gnumeric start ook veel sneller op dan Excel, en het is ook merkbaar stabieler in onze ervaring.

Er zijn andere mensen die tot gelijkaardige conclusies gekomen zijn: https://www.larrygowdy.com/gnumericreview.html

Waarom we PostgreSQL gebruiken is omdat het gelijkaardige functies biedt als Excel, maar een hele reeks voordelen heeft zoals dat het volledig gratis is en veel krachtiger op gebied van features en efficiënter: https://www.codecademy.co.../excel-to-sql-why-switch/

[dieAndereGozer]

Grote datasets bewerken moet je ook niet doen met Excel, dat is echt een beginnersfout.

Gewoon doen met andere tools. In het veld wordt veel gebruik gemaakt van MatLab, Python en LabVIEW. Maar Excel is gewoon niet meer te doen als je meer dan een paar duizend datapuntjes hebt.

[FateTrap]

Het waren het soort zaken waar je geen MatLab of Python zou nodig moeten hebben. Bij hetzelfde CSV bestand duurde het 4 seconden om +- 60 000 rijen te rangschikken. In Excel duurt dezelfde taak 13 seconden. Dat is iedere keer 9 seconden dat we verliezen bij het rangschikken van de rijen. Gnumeric start ook veel sneller op dan Excel, en het is ook merkbaar stabieler in onze ervaring. Er zijn andere mensen die tot gelijkaardige conclusies gekomen zijn: https://www.larrygowdy.com/gnumericreview.html De app heeft ook een uitgebreid aantal statistische mogelijkheiden die Excel niet biedt, waardoor we nu zo goed als alle analyses mbv Gnumeric kunnen maken.

[dieAndereGozer]

Excel is een microsoft product, dan verwacht je toch wel een beetje dikke overheid.

Verder is alles wat ik zei wel waar. En jij bent het met mij eens, want jij zegt net als ik dat je andere tools moet gebruiken dan Excel. In jouw geval is je tool gnumeric. Als dat werkt, helemaal toppie toch?

[FateTrap]

Ik ben het ook gedeeltelijk met je eens. Maar voor kleine datasets is Gnumeric even ideaal. Wat is dan de reden dat zo veel mensen Excel aankopen/betalen? Bij grote bedrijven kan ik het nog minder begrijpen, die geven erg veel geld uit aan Office en het geeft dus geen hogere productiviteit aan je werknemers. Dus dat zijn twee keer hoge kosten die vermeden kunnen worden.

Waar ik het niet mee eens ben is Python en MatLab. Beide zijn extreem populair bij veel mensen maar ze zijn ook één grote energie en tijdverspilling:
https://blogs.sas.com/con...ll-paradox-sas-vs-python/
https://computersciencehu...is-best-for-data-science/
Etc.

De filosofie van ons bedrijf is grotendeels: Tijd is je kostbaarste hulpbron.

[dieAndereGozer]

Wat is dan de reden dat zo veel mensen Excel aankopen/betalen?

Doen mensen dat dan? Privé download men het, geen idee waarom ze het nodig hebben.

Kleine bedrijven die kleine dingen moeten bijhouden? Kunnen beter libre office calc gebruiken.

Bij grote bedrijven snap ik het wel, door de jaren heen is het een industriestandaard geworden en het feit dat programmeren eng is, neemt men het. Verder, die 9 seconde winst die men maakt in jouw geval gaat wel op aan de koffie

Waar ik het niet mee eens ben is Python en MatLab. Beide zijn extreem populair bij veel mensen maar ze zijn ook één grote energie en tijdverspilling:

Python is gewoon marktleider, veel support, mega veel projecten / packages en makkelijk software bois voor te krijgen. En het is een oudere taal dus meer backlog. Dan kan je wel inderdaad naar SAS of Julia gaan(van beide nog nooit gehoord) maar de communities zijn daar ook kleiner.
Python wordt ook veel meer gebruikt in de onderzoekswereld[1] echt leuk spul.

Ik weet niet of de standaard betere output van SAS en iets minder code kloppen bij SAS een winst is over python. Je kan je ook afvragen of je niet meer tijd kwijt bent een andere taal leren / te gebruiken als je hele legacy al in bijvoorbeeld python staat. Dat is ook de reden waarom Rust zo lastig van de grond komt.

Dus er is zeker wat te zeggen over een taal, op het moment dat je nu pas begint. Als je al jaren en jaren aan zooi hebt staan welke je actief gebruikt, gaat het even lang duren om dat om te zetten en te testen.

[1] https://scikit-learn.org/stable/

[Reactie gewijzigd door dieAndereGozer op 23 juli 2024 06:58]

[FateTrap]

Voor zover ik weet is Python enkel populair geworden omdat Google het hard gepusht heeft en dan is het bandwagon effect begonnen. Dus niet omdat het een handige/intelligente/snelle programmeertaal is. Ze proberen het nu sneller te maken maar het hoorde lange tijd bij de allertraagste programmeertalen.

Het is hetzelfde met JS, dat is enkel bekend geworden omdat Google en Facebook het gepusht hebben. De taal is in vijf dagen geschreven, en al die tijd is er weinig aan veranderd. Je kunt al wel raden dat het een gedrocht van een programmeertaal is.

Nu ik weet dat wat ik beweer ingaat tegen de stroom, maar het is wel degelijk volledig correct wat ik zeg.

Python:
https://medium.com/nerd-f...ming-language-2ab73b0bda5
https://people.eecs.berkeley.edu/~bh/proglang.html
https://www.osnews.com/st...enchmarking-math-file-io/
https://www.theregister.com/2021/07/28/python_pypi_security/
https://medium.com/codex/...ng-languages-e738774b1957
https://www.quora.com/Why...r-crash-like-Java?share=1
https://www.theregister.com/2022/06/08/ai_climate_impact/

90% van de energie voor datacenters wordt gebruikt om de datacenter te koelen, en door python worden deze datacenters heel veel warmer dan met andere programmeertalen. Ik vermoed dat de mens snel aan zijn eind gaat komen als ze Python zullen blijven onderwijzen aan de uniefs.

JS
https://www.quora.com/Why-is-JavaScript-so-hated?share=1
https://github.com/fukamachi/woo
https://www.quora.com/Wha...-least-buggy-code?share=1

C++
https://fossbytes.com/lin...s-c-programming-horrible/
https://www.techrepublic....ing-programming-language/

Java
https://redmonk.com/dberk...ranked-by-expressiveness/
https://stackoverflow.com...-consumes-too-much-memory

Common Lisp
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
http://gpbib.cs.ucl.ac.uk/gecco2006/docs/p957.pdf
https://www.reddit.com/r/..._java_rust_julia_dart_in/

Chez Scheme
https://www.quora.com/Is-...od-first-language?share=1
https://github.com/guenchi/Igropyr
https://github.com/ecrave.../blob/master/results.Chez

Het punt dat ik wil maken, Guido van Rossum haat Lisp, hij haat waarschijnlijk ook Scheme, hij haat Emacs. Maar sinds mensen Python zijn gaan gebruiken is veel code rampzalig crappy geworden, en kun je zeggen dat de meeste programmeurs niet meer kunnen programmeren. Misschien wordt hier de verklaring gegeven:

Those famous Emacs users
https://www.pixelstech.ne...-Those-famous-Emacs-users

Famous Emacs Users
http://xahlee.info/emacs/misc/famous_emacs_users.html

Who Needs Modern Emacs? https://batsov.com/articl...1/who-needs-modern-emacs/
The tools we use have a profound (and devious) influence on our thinking habits, and, therefore, on our thinking abilities.

[dieAndereGozer]

Ik ben het eens dat Python misschien niet ideaal is, maar python draait met Cython gewoon veel op laag niveau. Zoals numpy et cetera. Vandaar dat al die neural network spul van tensorflow en keras gewoon goed draaien.

Bij python heb je inderdaad het trage interpret deel, maar de grote dingen draai je gewoon low level, en dat compenseert best goed.

Maar iedereen heeft een mening over programmeer talen. Torvaldis wilt alleen C want dat is het beste, hele groepen willen Rust, want dat is het beste.
Het gaat er gewoon om dat je de juiste tool bij de juiste toepassing is. En Python heb ik lang ontzien want interpret, maar na het zien dat er heel veel gewoon low level gedaan wordt, vindt ik het niet zo heel erg.

Ik wil wel een bron zien dat data centra warmer worden door python.

Tevens moest ik wel lachen om die quora question. Dat is gewoon een gechargeerde troll. Java en Python krijgen beide evenveel haat. En ik heb met beide nog nooit last gehad dat ze willekeurig crashen. Java heeft weer als nadeel wat je eerder aanhaalde, om hello world te schrijven ben je al 60 lines of code verder.

[FateTrap]

Voor zover ik weet moet je static typing toepassen in Cython, anders ga je geen grote prestatiewinst halen. Maar je bent dus niet meer in Python aan het programmeren in dat geval want dat is dynamic typing. Dus best om Cython te zien als een andere programmeertaal dan Python.

Tensorflow is niet volledig in Python geprogrammeerd, maar het deel Python dat er in zit zorgt ervoor dat het veel trager is dan wat ideaal zou zijn:
https://www.reddit.com/r/...hy_is_tensorflow_so_slow/
TensorFlow is consistently the slowest ML framework for training various kinds of neural nets under all hardware configurations.
https://www.reddit.com/r/..._so_slow_compared_to_ffm/
As complex of a model as is it, that FFM model only takes 6 hours to train and converge after ~10 epochs on 500GB data on a single machine with ~ 8 cores. On the other hand, training an extremely simple tensorflow model on this dataset (embedding layer -> sigmoid output neuron) takes almost 2 days for a single epoch on this dataset.

Why is TensorFlow 2 much slower than TensorFlow 1? #33487
https://github.com/tensorflow/tensorflow/issues/33487
Below is code benchmarking performance, TF1 vs. TF2 - with TF1 running anywhere from 47% to 276% faster.

https://groups.google.com...aYbPSGylEo/m/IROI5aDSDAAJ
Though as others have mentioned, Theano is still faster in an apples-to-apples comparison. (Dus er zijn zelfs Python ML frameworks die sneller zijn dan Tensorflow)

https://towardsdatascienc...r-tensorflow-ed16403c5799
Another very important point where OpenCV can be a better choice for production deployments is performance. In fact, for some deep learning models, running them in OpenCV can be an order of magnitude faster then running them in Tensorflow (even when using Tensorflow’s C++ API).

https://lisp-journey.gitlab.io/pythonvslisp/
pgloader was re-written from Python to Common Lisp for a 30x speed gain.

How to make Lisp go faster than C
http://www.iaeng.org/IJCS.../issue_4/IJCS_32_4_19.pdf

Why Lisp? Why Common Lisp?
http://norvig.com/paip-preface.html

SBCL quicker than C?
https://lbolla.wordpress.com/2010/12/05/sbcl-quicker-than-c/

Timing data comparing CClasp to C++, SBCL and Python
https://drmeister.wordpre...asp-to-c-sbcl-and-python/
SBCL 0.63 seconds
Python 77.69 seconds

Dat is een verschil van een factor 123.32 in snelheid. Python is één van de populairste talen voor data science/data analyse, DevOps, web development(Django/Flask) , voor Selenium, automation, audio/video apps, console apps, en voor ML/deep learning.

Het kan simpelweg niet anders dan dat Python een heel grote impact heeft op het stroomverbruik van een data center.

[dieAndereGozer]

Fair, je hebt gelijk, weer wat geleerd.

Maar we zitten wel met een groot probleem dan. Want iedereen en zijn moeder zit in Python, het is te groot om te falen lijkt wel. Dus een omslag maken wordt gewoon lastig. Zoals ik al eerder aanhaalde, alle bedrijven die python gebruiken gaan niet eventjes overstappen.

[FateTrap]

Ze hebben Python onlangs 40% sneller gemaakt: https://www.phoronix.com/...thon-311-benchmarks&num=4

Dat is nog altijd heel traag in vergelijking met Chez Scheme of Common Lisp. Maar het is wel positief dat ze intenties hebben om het sneller te maken.

Wat ik het meest bizar aan heel het Python verhaal vind: Stel je gebruikt Python 3.10 op een razend krachtige Ryzen 5950X om Ansible (een Python app) te draaien en je gebruikt het zo hard dat heel je Ryzen 5950X CPU 100% benut is.

Dat is ongeveer, op gebied van CPU, dezelfde prestaties die je zou krijgen als je 20 jaar geleden Ansible in Common Lisp geprogrameerd zou hebben en het zou gebruiken op een Intel Pentium 4 2.4B GHz.

Dus je kunt zeggen dat apps die vandaag grotendeels in Python geprogrammeerd zijn, zoals het razendpopulaire Ansible en veel andere apps, dezelfde CPU prestaties geven als apps die 20 jaar geleden in CL geprogrammeerd werden. Waardoor je kunt zeggen dat de prestaties die we in sommige apps in 2022 zien niet echt sneller geworden zijn tov 2002. Dus dat is op dit gebied a blast from the past .

[dieAndereGozer]

Ik heb gister eventjes online gezocht, je hebt dus een benchmarking game gevonden, gestart door een oud OS programmeur. Ze doen iets van 100 talen dezelfde berekening doen en benchmarken dit.

https://github.com/PlummersSoftwareLLC/Primes

Waarbij je de resultaten kan zien hier:

https://plummerssoftwarel...View/?rc=30&sc=dt&sd=True

Hier zie je dat van de 392 verschillende methodes(81 talen) python als eerst verschijnt rond de 171, dus ongeveer midden moot.

Lisp staat helemaal boven aan, daarna C++.
Een andere taal die veel dezelfde projecten heeft als Python zoals Java(je haalde selenium aan dacht ik, dat kan ook via Java) staat op 89. Als je filtert op alleen max result per taal, dan is python # 31 op de 81.

Maar inderdaad, python op 171 (31) heeft een getal van 1719,4605872358738 waar nummer 1 Lisp 84349325,11754693 heeft(een beetje in de war hier, want het is een Engelse site, waarom gebruiken ze komma's als decimaal scheidingsteken? Is dat mijn lokale instelling die ze overnemen?).
Maar Lisp is dus 49056 keer sneller dan Python. Dat is pas bizar.
Maar heel eerlijk weten we niet het verbruik hierbij, want misschien trekt python de CPU wel helemaal niet vol, ik zit er over te denken dit eens met een simpele verbruiksmeter te bekijken.

Maar ik ben het helemaal eens met je. Het wordt tijd dat python de deur wordt gewezen. Ik moet dat wel even gaan kijken of er vergelijkbare projecten zijn in andere talen voor dingen die ik nu in python gebruik.
De belangrijkste zijn dan wel selenium, praw, tensorflow / keras. De rest programmeer ik zelf wel aan elkaar.

[FateTrap]

Ik heb je link bekeken, en ik zou persoonlijk niet weten hoe ik deze cijfers moet interpreteren, ik denk niet dat ze te interpreteren zijn hoe ik ze om mijn computer zie.

Hier zie je enkele duidelijke tests die aangeven hoe snel Python is:

1. https://benchmarksgame-te.../fastest/python3-gcc.html

2. https://julialang.org/benchmarks/

Met betrekking tot Common Lisp en Chez Scheme, die zijn meestal iets trager dan C en Rust, maar in sommige situaties (rond 10% van de situaties) gaan ze sneller zijn. Eén van de voordelen van Common Lisp en Chez Scheme tov C en Rust is dat ze veel krachtiger/productiever zijn om ideeën direct om te zetten in code, en ook krachtiger om problemen op te lossen. Ze zijn ook perfect om apps mee te te maken. Je weet waarschijnlijk dat de meeste Android apps in Java/Kotlin geprogrammerd zijn. Wel ze zouden sneller in CL geprogrammeerd geweest zijn, en ook hogere prestaties halen en iets minder geheugen gebruiken dan wat we zien bij Java.

Bijvoorbeeld het onderliggende framework van Racket is in Chez Scheme geprogrammeerd, en ze beweren dat de prestaties on par zijn met C. Dat is extreem impressionant als je weet dat Chez Scheme één van de meest consistente en krachtige talen is, en bovendien ook de makkelijkste taal om aan te leren.

[dieAndereGozer]

Ik denk dat de data van mijn link erg lijkt op die bij julia, alleen geen grafiek. Het is ook op een logaritmische schaal, wat wel nodig is bij dingen als 50k x verschil.

Maar de vraag blijft, waarom zou men niet alles in CL maken als dat het snelste is? Een reden om niet meer over te stappen heb ik al gegeven:backlog.

Maar zeker zeer interessant. Ik ga dit weekend denk ik teveel vervanging zoeken xD

[FateTrap]

Maar de vraag blijft, waarom zou men niet alles in CL maken als dat het snelste is?

Mijn gok zou zijn, omdat bepaalde bedrijven de touwtjes voor dit soort realiteit bijna volledig in handen hebben. Meer bepaald specifieke mensen in deze bedrijven. Denk bvb aan Brendan Eich die JS wou baseren op Lisp. Zijn bazen wouden het niet, en verkozen Java. Daarom noemt het nu JavaScript. Al heeft JS op zich niet erg veel gemeen met Java of Lisp, maar dat wisten zijn bazen waarschijnlijk niet

Een tweede mogelijke verklaring wordt hier gegeven: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

Now in contrast, the C/C++ approach is quite different. It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere.

And all that, from the point of view of an employer, is attractive. Ten people who communicate, document things properly and work together are preferable to one BBM hacking Lisp who can only be replaced by another BBM (if you can find one) in the not unlikely event that he will, at some time, go down without being rebootable.

Employers much prefer that workers be fungible, rather than maximally productive. Too true. With great difficulty does anyone plumb the venality of the managerial class.

Nogmaals, ik denk dat de grootste reden de macht van Google, Microsoft en Facebook is: https://www.theperspectiv...he-perspective-on-google/

In een kapitalistisch systeem zie je dat, hoe langer het systeem zich in stand houdt, hoe meer een beperkt aantal bedrijven extreem veel macht bezitten. Dus dat de macht zich met de tijd steeds meer concentreert. Erg vaak zijn ze zo machtig geworden hoofdzakelijk door te misbruiken. Je moet niet verwachten dat ze de beste technologiën populair gaan maken, daar heeft hun bestaan nooit mee te maken gehad..

[dieAndereGozer]

Ik snap macht en alles. Maar wat heeft een Google of een Facebook eraan dat ik python gebruik ipv C++? Dat stukje over samenwerken kan ik inkomen, maar je wilt juist niet afhankelijkheid van personeel onderling want stel je voor dat er eentje wegvalt.

Maar ik geloof graag dat onkunde leidt tot slechte keuzes.

Ik moest wel lachen om Go laatst op Reddit, ze hebben een of andere functie niet(ik kan het even niet meer terughalen) omdat het een "lastig concept" is. Terwijl je dus eigenlijk slecht programmeren(of programmeurs) steunt.

[FateTrap]

Ik weet niet per se of Google wilt dat jij specifiek Python gebruikt ipv een andere taal, maar Google heeft Python populair gemaakt:

https://softwareengineeri...hons-popularity-so-sudden
Google started using Python heavily and reinvesting in development of the language. Google is the corporate backing. It became a top-tier implementation language at Google earlier in the decade, and this had an impact in how seriously it was taken.

https://www.thepythonquiz...e-we-can-c-where-we-must/
Early on at Google, there was an engineering decision to use “Python where we can, C++ where we must.” Python was used for parts that required rapid delivery and maintenance. Then, they used C++ for the parts of the software stack where it was important to have very low latency and/or tight control of memory.

https://www.reddit.com/r/...tm_medium=web2x&context=3
It was one of the four official languages at Google. So it was bound to grow.

https://www.upgrad.com/bl...-popular-with-developers/
Python Programming language is heavily backed by Facebook, Amazon Web Services, and especially Google. Google adopted python language way back in 2006 and have used it for many applications and platforms since then. Lots of Institutional effort and money have been devoted to the training and success of the python language by Google. They have even created a dedicated portal only for python.

In het algemeen kun je zeggen dat grote bedrijven bepalen welke programmeertalen populair worden:
- Java was originally developed by James Gosling at Sun Microsystems and released in May 1995 as a core component of Sun Microsystems' Java platform.
- Visual Basic is a name for a family of programming languages from Microsoft
- The C# programming language was designed by Anders Hejlsberg from Microsoft in 2000.
- Swift is a general-purpose, multi-paradigm, compiled programming language developed by Apple Inc. and the open-source community.
- Objective-C was the standard programming language supported by Apple for developing macOS (which descended from NeXTSTEP[3]) and iOS applications until the introduction of Swift in 2014.
- Go is a statically typed, compiled programming language designed at Google[10] by Robert Griesemer, Rob Pike, and Ken Thompson.
- On the JavaScript front, Microsoft reverse-engineered the Navigator interpreter to create its own, called JScript. By the early 2000s, Internet Explorer's market share reached 95%. This meant that JScript became the de facto standard for client-side scripting on the Web.

Je kunt zeggen dat 80% van de populariteit van programmeertalen verklaart wordt door de strategie/keuzes die in de machtigste IT bedrijven gemaakt worden. Er zijn sowieso honderden programmeertalen die beter zijn dan de bovenstaande lijst, maar ze zijn niet gesteund geweest door grote bedrijven en uitgestorven.

Dit is wat mij betreft een erg droevige situatie, want zoals ik al gezegd heb, deze populaire programmeertalen zijn meestal kwalitatief gezien het minste dat ooit bedacht geweest is. Go is allesbehalve een ingenieuze nieuwe programmeertaal, en heeft, buiten voor microservices, weinig waarde.

Je kunt zeggen dat Common Lisp beter is dan Haskell als algemene programmeertaal, maar Haskell is nog steeds beter dan GO: https://www.quora.com/Bet...ge-should-I-learn?share=1
Haskell is for the people who simply wants to express the result they expect. No memory locations, no steps, just description of the expected result and its type. Concurrent for free, no need for egocentrically called “goroutines”. Also Haskell users like to be specific about what is happening, if there is user interaction, the function type indicates it. Learn both, use Haskell for your own good.

Dus de programmeertalen die de grote bedrijven bekend gemaakt hebben waren de talen die het meest 'bottom of the barrel' waren. Als je kijkt naar McDonalds, dat is ook de meest populaire fast food keten, en uit onderzoek blijkt dat ze de laagste kwaliteit van alle fast food ketens hebben. De technologiesector is exact hetzelfde fenomeen in dit opzicht.

[dieAndereGozer]

Ahhh ja op die manier.

Dat is allemaal wel heel interessant. Bedankt voor je diepgaande reactie, het voelt een beetje rottig om zelf dan een hele korte te schrijven. Maar het is niet anders.

Zelf was ik al begonnen selenium te verplaatsen naar Java (C# is gewoon rottig want dan moet ik dotnet installeren op mijn debian install).
Andere projectjes moeten nu wachten. Ik ga nog zoeken naar een vervangen / equivalent voor tensorflow / keras.

[FateTrap]

Jax gaat Tensorflow / Keras vervangen:
Google lost the battle for machine learning to Meta, insiders say. Now it's betting the future of its own products on a new internal AI project.
https://archive.ph/Zngbx#selection-717.0-717.144

Het maakt het mogelijk om je machine learning taken op meerdere verschillende chips tegelijkertijd te doen op een eenvoudige manier. Het heeft grofweg dezelfde performance als TensorFlow: https://cloud.google.com/...st-training-supercomputer

Als je iets wilt dat snel is voor deep learning: https://github.com/pjreddie/darknet
Het is meer gespecialiseerd dan TensorFlow, maar ze zijn top in snelheid en nauwkeurigheid.

Nog enkele andere projecten die hoge efficiëntie hebben:
https://github.com/mlpack/mlpack
https://github.com/catboost/catboost
https://spark.apache.org/mllib/

In mijn mening is FreeBSD beter dan Debian momenteel: https://unixsheikh.com/articles/the-delusions-of-debian.html Je kunt ook Selenium gebruiken op FreeBSD: https://www.freshports.org/www/selenium/

[dieAndereGozer]

Ik schrijf Jax gelijk op. Ik ben niet heel erg vlug met heel die AI(in gebrek voor een beter woord) maar ik zal er eens naar kijken.

Verder moet ik eens kijken naar dat rond Debian. Echter zijn er wel wat applicaties die waarschijnlijk niet werken op BSD, waaronder steam / GOG. Dan kan ik beter voor een andere distro kiezen dan voor een ander besturingssysteem.

[FateTrap]

Steam en GOG games werken 'soms' maar niet altijd op FreeBSD. Bijvoorbeeld CS:GO en Dota 2 werkten voor beter op FreeBSD dan op Linux en windows. (hogere FPS en betere latency) FreeBSD heeft momenteel meer dan 50 000 (standaard) paketten en je hebt ook Wine, Nix en linux binary compatibility bovenop deze standaard paketten. Je kunt open source apps ook makkelijk naar FreeBSD porten via Poudriere. Je hebt ook veel goede Linux alternatieven voor Debian momenteel. Fedora 36 is erg goed algemeen gezien indien je Gnome fan bent. Als je eerder een KDE persoon bent dan zou ik Manjaro ofwel KDE Neon aanraden. Als je herproduceerbare builds en/of extreme betrouwbaarheid na updates zou willen dan is NixOS perfect. Als je extreem efficient RAM gebruik belangrijk vindt dan is Alpine Linux het beste. En Clear Linux en AlmaLinux geven momenteel de hoogste (CPU) prestaties. Dus je hebt meerdere goede en populaire opties. Als je niet goed weet wat te kiezen dan zou ik eerder Fedora aanraden omdat het een 'universeel' besturingssysteem is dat erg goede software compatibiliteit heeft.

Mbt je TensorFlow equivalent. Ze hebben geprobeerd om Darknet te porten naar TensorFlow, maar de prestaties op 'darkflow' zijn vele malen lager: https://github.com/thtrieu/darkflow/issues/904

Ik denk dat je ook Haskell kunt gebruiken ipv Java voor Selenium: https://github.com/kallisti-dev/hs-webdriver Haskell is in mijn mening een veel betere programmeertaal dan Java.

De programmeertalen die ik je zou aaraden om optimaal productief te worden zijn Nim, Common Lisp, Chez Scheme, Haskell en Rebol. Dit zijn wellicht de vijf meest intelligente talen die ooit ontwikkeld geweest zijn.

[Reactie gewijzigd door FateTrap op 23 juli 2024 06:58]

[dieAndereGozer]

Was het probleem met Debian niet dat er teveel pakketten zaten in het project? Hoe is het dan een positief punt voor FreeBSD?
En ik heb een tijdje Fedora gebraait (10 jaar geleden al) maar uitendelijk gesettled op Debian omdat dat ook op de servers draaide.

De programmeertalen die ik je zou aaraden om optimaal productief te worden zijn Nim, Common Lisp, Chez Scheme, Haskell en Rebol. Dit zijn wellicht de vijf meest intelligente talen die ooit ontwikkeld geweest zijn.

Dat is zeker nadat ik eerst bezig ben alle ins en outs van die talen te leren, dus duurt het wel weer even tot ik optimaal productief ben.

[FateTrap]

Was het probleem met Debian niet dat er teveel pakketten zaten in het project? Hoe is het dan een positief punt voor FreeBSD?

Bij Debian ga je zo goed als nooit op de hoogte gebracht worden over de geïnstalleerde paketten die geen maintainer hebben. Bij FreeBSD wordt je telkens op de hoogte gebracht. Na het updaten van het pakket geeft FreeBSD een melding dat het specifiek pakket geen maintainer heeft momenteel, en dat je voorzichtig hiermee moet zijn. FreeBSD was, sinds zijn oprichting, altijd meer gefocust op veiligheid dan de meeste Linux systemen. Er wordt ook (veel) minder malware voor BSD systemen ontwikkeld, simpelweg omdat hackers hier minder voordeel uit kunnen halen, en ze meer impact kunnen hebben als ze extra tijd investeren in Linux (zoals bvb Android), macOS en windows. Los van deze zaken heb ik ook het gevoel dat FreeBSD ontwikkelaars meer tijd steken in de kwaliteit van het besturingssysteem dan Debian ontwikkelaars. De huidige Debian is een stuk minder stabiel dan als je FreeBSD + ZFS + XFCE gaat gebruiken en stabiliteit was één van de zaken waarom Debian vroeger zo populair was.

Fedora is in de laatste tien jaar sterk geëvolueerd. Ik zou zeggen dat rond het jaar 2010 Ubuntu één van de beste Linux systemen was. Maar sinds dat moment is Fedora technologisch steeds beter geworden tov Ubuntu. En momenteel is Ubuntu technisch gezien niet meer competitief met Fedora, Fedora is bovendien ook erg gebruiksvriendelijk, dus ik zie daarom Fedora meer als de standaard distro die ik zou aanraden, ook aan nieuwkomers.

Dat is zeker nadat ik eerst bezig ben alle ins en outs van die talen te leren, dus duurt het wel weer even tot ik optimaal productief ben.

Rebol is iets dat je extreem snel kunt aanleren: http://redprogramming.com...siness%20Programming.html

As you can see, with Rebol, coding barriers are lowered to a *critically low* point of simplicity. That critically low point of simplicity is far below any other software development tool, and is in fact easy enough for anyone willing to learn.

Ik heb gelezen dat ze Rebol aan kinderen van 10 jaar onderwezen hebben, en dat die in een paar dagen al de belangrijkste concepten aangeleerd hadden. Je kunt zeggen dat je kinderen van 10 jaar in enkele weken deze programmeertaal zou kunnen aanleren.

Het kenmerk van Rebol is dat het niet enkel expressiever is dan Python, het is ook makkelijker leesbaar dan Python. Rebol ("Relative Expression Based Object Language") wil de meest productieve, leesbare en beknopte programmeertaal zijn die beschikbaar is. Voor zover ik weet is ze dat ook volgens alle mensen die deze taal aangeleerd hebben.

https://news.ycombinator.com/item?id=9585519
Maintaining old projects in Rebol is always simpler than with any other development tool/language I've used in 30+ years.

Het enige nadeel aan Rebol dat ik kan bedenken is dat het niet echt sneller was dan Python: http://blog.hostilefork.com/rebol-vs-python-performance/

Maar je ziet ook dat de startup times van Python een stuk trager zijn wat betekent dat Rebol een veel betere taal voor scripts te schrijven dan de populairste scripting taal (momenteel).

Er is een project om Rebol dichtbij de snelheid van C te krijgen: https://www.red-lang.org/
@hiiamboris rewrote that as a Red/System routine, tweaked it, and got a massive speedup. No external compiler needed, no need to use C, and the code is inlined so it's all in context.
Vastly increased performance is the main driver for this new lexer.

Als ze erin zouden slagen om Red language iets sneller of gelijkaardig te laten presteren dan Java dan hebben ze de perfecte programmeertaal gemaakt.

[dieAndereGozer]

As you can see, with Rebol, coding barriers are lowered to a *critically low* point of simplicity. That critically low point of simplicity is far below any other software development tool, and is in fact easy enough for anyone willing to learn.

Als je ooit met LV hebt gewerkt, weet je dat je niet wilt dat iedereen kan programmeren.

Ik heb gelezen dat ze Rebol aan kinderen van 10 jaar onderwezen hebben, en dat die in een paar dagen al de belangrijkste concepten aangeleerd hadden. Je kunt zeggen dat je kinderen van 10 jaar in enkele weken deze programmeertaal zou kunnen aanleren.

Dit voelt meer als een biased iets dan echt een goed argument. Mijn Neefje van 10 kan ook simpele JS dingen lezen omdat ze dat op school krijgen tegenwoordig.

Maar je hebt het erover dat het onpar is met python, wat je ook als slecht bestempelde.

Verder zeg je snelheid van C en daarna java. Het laatste gedeelte voelt een beetje heen en weer te gaan.

[FateTrap]

Als je ooit met LV hebt gewerkt, weet je dat je niet wilt dat iedereen kan programmeren.

Dat is één van de vele redenen waarom talen als Rebol en Haskell veel beter zijn dan Python: https://www.reddit.com/r/...tm_medium=web2x&context=3

Dit voelt meer als een biased iets dan echt een goed argument. Mijn Neefje van 10 kan ook simpele JS dingen lezen omdat ze dat op school krijgen tegenwoordig.

Je moet deze grafiek eens bekijken: http://dberkholz-media.re...ressiveness_weighted2.png
Een app die je in Rebol in één of twee dagen maakt, daar ga je in JS twee weken aan mogen werken. Zelfs de slimste mensen hebben mentaal gezien sterke beperkingen. Wat betekent dat slimme mensen over bepaalde zaken een jaar of langer gaan nadenken, en geen antwoord gaan vinden voor het probleem in JS. Mbv Rebol gaan ze in één of twee dagen het antwoord vinden. Het tijdverlies kan dus gigantisch zijn, en heeft vaak niks met vaardigheden van de persoon te maken.

Verder zeg je snelheid van C en daarna java. Het laatste gedeelte voelt een beetje heen en weer te gaan.

De vergelijking met C gaat over één specifiek onderdeel en zegt niet hoe snel het exact is in vergelijking met C. Het zegt enkel dat je geen C meer nodig zult hebben omdat de Red language voor die taak erg snel is. We weten niet hoe snel de taal exact gaat zijn in het algemeen, want de Red language is momenteel nog in ontwikkeling. Maar we kunnen wel vermoeden dat het ongeveer zo snel als Java kan zijn, in het algemeen.

[Reactie gewijzigd door FateTrap op 23 juli 2024 06:58]

[_Dune_]

Nu nog iets aan de store apps doen, in combinatie met VDI (oa VMware Horizon). Zodat deze ook fatsoenlijk in een master image uitgerold kunnen worden en niet steeds 'verdwijnen'. Is overigens in hun eigen VDI ook een probleem. Zonder standaard vooraf draaien van een Power Shell script, blijven standaard applicaties gewoon weg, zoals zoiets basaals als de rekenmachine.

[Reactie gewijzigd door _Dune_ op 23 juli 2024 06:58]

[HansvDr]

We hebben met MS Access al regelmatig gezien dat er na een update opeens een rare bug optrad.

Automatische updates hebben we nu naar 1 x per 6 maanden gezet. Scheelt een hoop ellende.