Fair deal for the employees but hard to compete against smart, well resourced people who are working 996. Everything with AI is moving so fast that moving slower makes you irrelevant.
I don't think it's a superset. You can represent any structs-and-arrays data in XML, but you have to make non-trivial mappings to make it work.
The obvious way is to use elements for everything, but then you're mapping both structs and their fields (very different concepts in e.g. C) to elements. Attributes map nicely to struct fields, but they only admit string values.
You can map anything to it but that flexibility means you then need to define schemas et al to ensure compliance
The schema thing isn’t actually unique to XML either. you can do the same thing with JSON and YAML too. But in my opinion, if you get into the realm of needing schemas in JSON then you’re at the point where you shouldn’t be using JSON any longer since you’re now violating the “simplicity” argument which is JSONs only real advantage over other formats.
Eh, XML is as much of a superset of JSON as the Turing machine is a superset of context-free grammars. The former has all the _power_ of the latter and more, but the mapping between them is non-trivial, far from an embedding.
I think it's fine to say C#'s data model is a superset of Java's or Rust's a superset of C's, but XML and JSON is too far for me, personally.
Watch how dict2xml or xml2dict handle JSON to XML automatic mapping. Both format carry 99% of the same structural infos in their respective serialization.
Visual Basic (and other 90s visual GUI builders) were great simple options for making GUI apps, but those GUIs were rather static and limited by today's standards. People have now gotten used to responsive GUIs that resize to any window size, easy dynamic hiding of controls, and dynamic lists in any part of the GUI; you won't get them to come back to a platform where their best bet at dynamic layout is `OnResize()` and `SubmitButton.Enabled = False`.
> Visual Basic (and other 90s visual GUI builders) were great simple options for making GUI apps
Yes, they were comfortable and easy to set up (and use), particularly when compared to web development.
> a platform where their best bet at dynamic layout is `OnResize()` and `SubmitButton.Enabled = False`
This is a great description of what web coding looked like for a very long time, _especially_ when it started replacing RAD tools like VB and Delphi. In fact, it still looks like this in many ways, except now you have a JSX property and React state for disabling the button, and a mess of complex tooling, setup and node modules just to get to that base level.
The web won not because of programmer convenience, but because it offered ease of distribution. Turns out everything else was secondary.
> This is a great description of what web coding looked like for a very long time
React is over a decade old, and as far as I remember, desktop apps using embedded browsers (Electron) started becoming dominant after it came out.
The ease-of-distribution advantage is huge, but web technologies are big outside the Web too, where it doesn't apply.
(Besides my main point, idiomatic web UIs don't implement resize handlers for positioning each element manually, but instead use CSS to declaratively create layouts. Modern GUI libraries with visual builders can also do this, but it was decidedly not the norm in the 90s.
Also, modern dynamic GUIs generally don't use a static layout with disabled parts, but hide or add parts outright. That kind of dynamicity is hard to even conceptualise with a GUI builder.)
Microsoft invented AJAX when building Outlook for the web back in 2000. GMail was released in 2003 and Google Docs in 2006. Around this time, even enterprise giants like SAP started offering web UIs. This is the shift from RAD to web I'm talking about.
The current idiomatic way of doing web layouts was, back then, almost entirely theoretical. The reality was a cross-browser hell filled with onResize listeners, in turn calling code filled with browser-specific if statements. Entire JavaScript libraries were devoted to correctly identifying browsers in order for developers to take appropriate measures when writing UI code. Separate machines specifically devoted to running old versions of Internet Explorer had to be used during testing and development, in order to ensure end user compatibility.
In short: The web was not in any way, shape or form more convenient for developers than the RAD tools it replaced. But it was instant access multi-platform distribution which readily allowed for Cloud/SaaS subscription models.
Electron happened more as an afterthought, when the ease of distribution had already made web UIs, and hence web UI developers, hegemonic. Heck, even MS Office for the web predates React, Electron, and something as arcane as Internet Explorer 9.
Things have gotten much better, but we're still having to reinvent things that just existed natively in VB6 (DataGrid, anyone?) - and at the cost of increasingly complex toolchains and dependencies.
Filtering for GP's requirements on GSMArena.com, I only see a handful of recent phones. Some of them do have an unlockable bootloader, but all of those are made by GPL violators, so you won't get the source code necessary to really make use of that unlocked status.
EDIT: I forgot to check the "removable battery" checkbox; with it you get zero matching phones. Maybe you should've checked that before assuming GP just can't search.
Not to end on such a negative note, foregoing a maimum height and the removable battery, Sony's Xperia 5 and 10 fit the rest of the requirements and are very good phones. Hard to find for sale in the last few years, though.
That seems compatible with OP's suggestion, just with X being a large value like 100 years, so sensitive information is only published about dead people.
At some point, personal information becomes history, and we stop caring about protecting the owner's privacy. The only thing we can disagree on is how long that takes.
Right, except there are some cases where that information should be disclosed prior to their death. Sensitive positions, dealing with child care, etc. but those are specific circumstances that can go through a specific channel. Like we did with background checks. Now, AI is in charge and ANY record in ANY system is flagged. Whether it’s for a rental application, or a job, or a credit card.
In the EU, lights have to be sold with a mandatory energy efficiency label. A lesser-known component of this is that this label includes a link to a standardised datasheet, which includes things like flicker metrics, CRI, chromaticity, and a measurement of the spectrum.
It doesn't fully quantify the light, but it's good enough to distinguish trash or even passable lights from actually good ones.
There's software where the continued existence of a diligent community around that project is necessary (web browsers, OS drivers, security-critical software...), but there's also software where I don't need any of that and I'm grateful for the chance to ignore any community around it and keep using the software anyway. Sometimes ideas just aren't compatible, and that's fine, forking allows us to part amicably.
I wish I could "just fork" most social problems. As FLOSS developers, we have the great luxury of being able to fork, and all we lose is the community, other people's considerations for our preferences. But for social problems, the people are the point, so "forking" alone wouldn't accomplish anything, not to mention physical limitations that make forking e.g. a country impossible.
It matters in that it opens up competition and allows fully-open designs, which should keep prices low and products available, but you're right that having fully-open state-of-the-art chips is unlikely to happen any time soon.
reply