"Companies providing at least one of the ten core platform services enumerated in the DMA are presumed to be gatekeepers if they meet the criteria listed below. These core platform services are: online intermediation services such as app stores, online search engines, social networking services, certain messaging services, video sharing platform services, virtual assistants, web browsers, cloud computing services, operating systems, online marketplaces, and advertising services. One company can be designated as gatekeeper for several core platform services."
"There are three main quantitative criteria that create the presumption that a company is a gatekeeper as defined in the DMA: (i) when the company achieves a certain annual turnover in the European Economic Area and it provides a core platform service in at least three EU Member States;(ii) when the company provides a core platform service to more than 45 million monthly active end users established or located in the EU and to more than 10,000 yearly active business users established in the EU; and (iii) when the company met the second criterion during the last three years.
The DMA defines a series of specific obligations that gatekeepers will need to respect, including prohibiting them from engaging in certain behaviours in a list of do's and don'ts."
The arguments there match the Steam platform in my opinion, but it is likely Steam already fulfills the existing obligations of the act. Seems a fairly good approach to things, if you are a dominant player you get burdened with extra rules and scrutiny.
For docs yes, but spreadsheets power users are everywhere in every organization in the world. Sure they are not the majority of employees, but they are often very high up in the management chain and you will only pry them out of MS Excel from their cold dead hands.
I am not a power user of excel in any way and even I can see that google sheets doesn't match it in features and performance.
First SPA I built (without frameworks) I actually wrote my own router that stored most client-side state in the URL as a hash. I remember back then having some problems with IE6 4kb limit on URL length.
It actually worked really well, but obviously I had very little state. The only things I didn't store in the hash were form state and raw visualization data (like chart data).
> Can I transfer my Overwatch battlenet account to steam? I really want to jump ship too.
Seems like you can just keep using the Battle.net account on GNU/Linux. You just add the Battle.net installer as a "non-steam game" (bottom left of the games list). Then, you start it, add your account, install the game and it "just works". I used it on the steam deck to play D4 beta and D2R on my CachyOS desktop.
> How is Proton with nVidia drivers? I have a 3080.
My battle-hardened 1060GTX served me for years. I recently upgraded my whole rig from Debian + Intel + Nvidia to full AMD and the RX9070XT works very well, with the caveat that I had to switch to a newer kernel on CachyOS to support it. That was 4 months ago and the situation now should be resolved, so you can prob use any old normie distro.
It is funny that MVC as a concept started as a backend server-rendered pages where the V was what rendered the HTML, C was the business logic which pulled data from the M which was the database + adapters.
When bending it to apply to React + JSON-apis it kinda applies, but it is such a different approach that conceptually it is not relevant in the presence of a lot of client state.
"Trygve Reenskaug created MVC while working on Smalltalk-79 as a visiting scientist at the Xerox Palo Alto Research Center (PARC) in the late 1970s. He wanted a pattern that could be used to structure any program where users interact with a large, convoluted data set. His design initially had four parts: Model, view, thing, and editor. After discussing it with the other Smalltalk developers, he and the rest of the group settled on model, view, and controller instead."
A model is supposed to be a domain model, the business logic of the app, not simply a database access layer. Your logic should reside in the model layer, sort of like building a library of classes and functions that you can reuse. That's why in the server-side world people use the term "fat models" to describe this type of use.
> When bending it to apply to React + JSON-apis it kinda applies
There is no bending, the original MVC applied to separating the business logic from rendering views and capturing input events, because this separation promotes code reuse. You can write many different views and controllers in your UI that show and react to user's input but still talk to the same underlying logical model.
I like this github repo to understand how MVC applies to programs with graphical interfaces. It's JS and HTML, so it's easy to follow.
> It is funny that MVC as a concept started as a backend server-rendered pages where the V was what rendered the HTML, C was the business logic which pulled data from the M which was the database + adapters.
I've got a CD from 1995 for Watcom C/C++. I purchased this compiler and IDE for a large (for me) sum of money and used it to create many Win32 applications.
I recall that that the help pages (which were extensive) came along with some non-reference documentation, which gave a quick overview of MVC for writing Win3.1 and Win95 applications, so MVC was already well-known in GUI systems even back then.
It is UDP-based but adds handshakes and retransmissions. But I am guessing for your benchmark transmission overhead isn't a major concern.
Websockets are not that bad, only the initial connection is HTTP. As long as you don't create a ton of connections all the time it shouldn't be much slower than a TCP-based socket (purely theoretical assumption on my part, I never tested).
You can't really mix different types of cells together in the same pack. Even cells with the same manufacturer and chemistry can be problematic to mix if they are at different wear levels (or even from different batches from the same factory).
This is only practical if you reuse the whole pack, or at least the modules. And for that to work well you also need a lot of complex software to keep the packs working well with each other (like balancing power levels between the packs).
BMS software is no joke, it is already hard and complex enough when using brand new battery packs and cells of the same chemistry and manufacturer and wear level. Any kind of mixing massively increases the complexity and safety concerns.
Main problem, not just from Apple, is that as phone tech gets standardized and more long-lasting the software support cycles have not gotten longer.
It is abysmal that Android phone makers still need to customize the OS so much for their hardware. Apple has no incentive for longer support cycles if Android does even worse on it.
It has always been like that since CP/M and commercial UNIX days.
Vertical integrations like everyone sell a product, a brand, a whole ecosystem experience.
If all OEMs sold the same CP/M, UNIX, MSX, MS-DOS, Windows software stack, on the what is basically the same hardware with a different name glued on the case, they wouldn't get any brand recognition, aka product differentiation.
Thus OEMs specific customisations get added, back in the day bundled software packages are part of the deal, nowadays preinstalled on the OS image, and so on.
I don't get what you mean, electric scooters are already a thing? At least in most countries in Europe they are classified the same type of vehicle as pedal-assisted e-bicycles and are capped at 25km/h and can ride in the bike lanes. If they go faster they are classified as full motorcycle and have to ride on the road with the cars and requires a license and a license plate (regardless if electric or non-electric).
Pedal-assisted is very much not a vestigial category, plenty of people want to get exercise and not just ride a scooter. On top of that they massively increase the range of the bicycle and the bicycle is still usable when the battery runs out.
https://ec.europa.eu/commission/presscorner/detail/en/ip_23_...
"Companies providing at least one of the ten core platform services enumerated in the DMA are presumed to be gatekeepers if they meet the criteria listed below. These core platform services are: online intermediation services such as app stores, online search engines, social networking services, certain messaging services, video sharing platform services, virtual assistants, web browsers, cloud computing services, operating systems, online marketplaces, and advertising services. One company can be designated as gatekeeper for several core platform services."
"There are three main quantitative criteria that create the presumption that a company is a gatekeeper as defined in the DMA: (i) when the company achieves a certain annual turnover in the European Economic Area and it provides a core platform service in at least three EU Member States;(ii) when the company provides a core platform service to more than 45 million monthly active end users established or located in the EU and to more than 10,000 yearly active business users established in the EU; and (iii) when the company met the second criterion during the last three years.
The DMA defines a series of specific obligations that gatekeepers will need to respect, including prohibiting them from engaging in certain behaviours in a list of do's and don'ts."
The arguments there match the Steam platform in my opinion, but it is likely Steam already fulfills the existing obligations of the act. Seems a fairly good approach to things, if you are a dominant player you get burdened with extra rules and scrutiny.