>Learning styles aren't a thing*. It was an idea popularized many years ago - that some people learn by seeing, some by hearing, others by thinking about things , etc... - and has been so thorougly proven not to replicate that when teachers use it to promote their methodology I practice my breathing exercises to not let it get to me.
I agree, and actually I put that asterisk there all that time ago when I wrote that article intending to put a footnote at the end, and clearly forgot. I meant to say that yes certainly people don't learn in the same way, but the thing I'm averse to is someone saying "I learn by seeing", and leaving it at that. It's simplistic, and I've found that individuals can also be wrong about their own opinion if their learning style.
The way I read some of the literature is that these may more often map to preferences, so the individual may prefer to see things, when learning, but it might not actually lead to more learning happening.
In dance I would yield that some people can repeat a movement just by seeing it, and others can't, but again I would say that's a learning style, I'd say there's a capacity inside them that is less strong/developed, translating movement seen to movement done. And it can be improved.
Yeah talking about the (vendor-preferred) compute part here
Vulkan's SPIR-V dialect is substantially different from the OpenCL one, notably with the former having structured control flow. They're incompatible between each other.
I'm talking about holistic efforts like OpenCL, and standards that would be equivalent to Nvidia's "Compute Capability" versioning.
The basic underlying tech can be agreed on, but Apple/AMD/Intel all have different GPU priorities that limit their ability to agree on a CUDA-adjacent hardware platform.
Ultimately AMD missed the most important boat with their woeful support for GPU compute. 10 years ago they needed to go all in and offer something to compete with CUDA - whether that was internal or something standard from Khronos. They just couldn't commit to it as a business, didn't have the vision.
Intel missed for a different reason - they didn't invest in the product space at all for decades. In terms of units they had the most market share (millions of Intel Integrated Graphics chips), but it wasn't seen as important. Bare minimum to render Windows and Office UI, nothing more.
What do you mean by holistic? SYCL is an open versioned standard that allows for vendor specific extensions. The problem is not that there isn’t a proper standard, the problem is that many hardware vendors - or software developers simply don’t want to adopt it.
Intel (via Codeplay) was handing it out on a silver platter - Nvidia on SYCL, full top chain, and people still wouldn’t want it.
Isn't OneAPI a good example of the problem, alongside Mojo/ONNX/TensorRT? The industry doesn't need a fifteenth competing standard. They need hardware buy-in.
By holistic, I mean hardware architecture cooperation. Nvidia can hold onto their lead forever if GPU designers fight over what a GPGPU hardware baseline looks like. The current ecosystem fragmentation is not competitive, and future fragmentation probably wouldn't work either. I think the fastest way to kill Nvidia would be a hardware consortium.
The problem with OneAPI is naming. It leads people to believe that is another competing standard where in fact is is simply just an implementation of a standard compliant SYCL compiler. If it just had been named “Intel SYCL compiler”, similar to the existing and accepted Intel OpenCL compiler, it would have been easier.
What would you expect the hardware consortium to coordinate on? Unified ISA?
They were maintained by Codeplay - paid for my Intel. Nvidia can make contributions anytime they want, and here is the problem: Nvidia does not want to. Until each vendor starts pitching in with contributing their backend to an open standard, you will have to rely on others doing it for them.
Mostly CRUD-type data collection - or essentially what would be "Pages" in tools like SharePoint, a landing location with linked resources, text, etc.
"BA's" had been building them for years before we arrived.
We categorized them into complexity buckets:
Level 1 - simple CRUD, no "business logic" - we could convert those during a quick demo, 20m.
Level 2 - slightly complex, including "@Formulas" - each would take about an hour to convert/migrate with some minimal manual intervention.
Level 3 - even more complex - minor analysis/review.
Level 4 - complex, detailed requirements and review needed.
Initially the first rough estimate without our "conversion/migration framework" was about 10-years (1-person) to rebuild them all.
After our tooling came live, we were able to complete in about 6-months with a team of 4 people.
Of course - a few short years later - truly starting at about release of SharePoint 2010 - Microsoft was evangelizing it's own "low-code/no-code" capabilities for users to dig themselves into the same situation. (SharePoint Designer Workflows, InfoPath, "smart/connected" Documents, data-driven Visio diagrams, "easy" customization of Sites/Pages via JavaScript/CSS/HTML, etc.)
Is it actual demand or is it just a future IOU? I will buy ram in the future keep the door open for me (OpenAI)?
I think whatever happens it will be their last big payday because some of the companies that can do have the money and the capability are going to make plans to move away. From the Cartel.
Google has done this before. They want to know what you click. There were extensions to undo it in the past. Then they seemingly switched to javascript and stopped the link jacking for a bit. Today, you shouldn't be using google for search. It is one of the worst options. So this new link jacking really doesn't matter.
Tell people to use firefox with ublock origin and privacy badger. I am sure there are even better combinations. Use something to block junk.
I just had to install open source local alternatives for someone who was using snapchat as a private journal. She did not realize anything on private is still read by AI and law enforcement. I can't imagine the personal things she posted thinking it was private when it's not. I think her thrapist may have given her this insane non-private idea for journaling. She looked scared.
Degoogle, decloud, debloat. No google camera apps, photos, or local file apps. You are uploading your images to google if you don't stop using their apps.
I installed two open source apps and told her to try them both since I never used these. June and StoryPad.
Well now that they own it, they can do whatever they like. They don't necessarily have to be optimizing the models for their hardware, they could just setup preferential pipelines to funnel users to their ecosystem. That seems fairly prudent given the challenges coming their way.
reply