Yes. If you want to block this, you either have to edit the source code or, at the load balancer/reverse proxy, block /api/v3/comment/like
if the POST body’s JSON content contains like
with value -1
.
Giver of skulls
Yes. If you want to block this, you either have to edit the source code or, at the load balancer/reverse proxy, block /api/v3/comment/like
if the POST body’s JSON content contains like
with value -1
.
Lifetime issues? Just clone()
all your problems away. Everything is Clonable
if you try hard enough. Who needs performance anyway?
I can’t find that for JSON, only for JSON schema (which is a different spec), is that the one you mean?
It happens rarely, but I felt pretty weird after finding out I needed to reap zombie orphans after the parent has died.
SOAP requires reading a manual before you get started, but so do the frameworks that try to replace it. APIs are APIs, you rarely need to manually access any of the endpoints unless the backend doesn’t stick to the rules (and what good do any alternatives provide if that happens?) or your language of choice somehow still lacks code generators for WSDL files.
OpenAPI/Swagger is just SOAP reincarnate. The code generators seem to be a bit more modern, but that’s about it really.
Of course you can use XML that way, but it is unnecessarily verbose and complex because you have to make decisions, like, whether to store things as attributes or as nested elements.
That’s a rather annoying shortcoming of XML, I agree. Then again, the choice is pretty inconsequential and the XSD for your data exchange format will lift any ambiguity anyway.
The choice between XML and JSON are a matter of preference, nothing more. XML is much more powerful than JSON and it’s usually a better choice in my opinion, but if you’re writing your applications well, you may as well be sending your data as pixels in a PNG because your serialiser/deserialiser should be dealing with the file format anyway.
That’s not a comment, that’s a field. There’s a reason var comment = "Increments i by 1"
isn’t how you comment in any programs.
I don’t see comments in the spec?
XSD and XSLT files alone can replace half the JSON applications I’ve seen. I can see why it’s easier to take the barebones JSON notation and reinvent the wheel, but those tiny programs are the “Excel+VBA” of web applications.
Most web frameworks contain code to exchange JSON over XMLHttpRequest
for a reason. XML is and always has been a data transfer format as well as a file format. JSON is, too. The amount of config.json
s I’ve had to mess with…
but using XML to communicate between your app’s frontend and backend wouldn’t be either
I don’t see why not? The entrypoint of web frontends is sent as HTML already. I guess that’s based on SGML, XML’s weird and broken cousin. Outputting XML is just a matter of configuring whatever model serialiser from JSON to XML.
There are a few good arguments against XML, but those also work against JSON.
Don’t drink the JSON coolaid. XML is fine. Better, in many cases, because XML files actually support comments.
In the modern programming world, XML is just JSON before JSON was cool. There was a whole hype about XML for a few years, which is why old programming tools are full of XML.
It’s funny but sad to see the JSON ecosystem scramble to invent all of the features that XML already had. Even ActivityPub runs on “external entities but stored as general purpose strings”, and don’t get me started on the incompatible, incomplete standards for describing a JSON schema.
It’s not just XML either, now there’s cap’n proto and protobuf and bson which are all just ASN.1 but “cool”.
I think Microsoft saw how pointless their efforts were and dropped it. I think they may still lock your desktop background?
It’s so easy to set up vlmcsd that I don’t even leave temporary virtual machine unregistered, but last time I used a pirated copy on another person’s laptop I had no idea until I noticed the text in the bottom right. Even stuff like backgrounds are easy to change by just downloading third party background software, like back in the good ol’ Windows 7 days.
There’s a whole flock of 'em!
Neither does Windows these days. You get the annoying message in the bottom right, but that’s not hard to get rid of with a few tweaks.
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
Based on stories like these, I get the feeling there’s active hostility from the maintainers against Rust contributors. While the kernel in general has accepted Rust contributions, the maintainers of individual subsystems seem to disagree.
I don’t think the language matters. The problem is cultural, first and foremost. Had a new wave of programmers used C to expand the Linux kernel, they probably would’ve run into the same issues.
This isn’t the first time I’ve heard devs complain about the DRM API, and most of my kernel panics seem to involve DRM as well (mostly Nvidia, but the Intel driver crashes too). Maybe it’s because of performance reasons, but DRM seems very hard to get right, even for already merged in-tree drivers.
If the problem does turn out to be technical in nature, maybe Linux needs to ask Microsoft for help. They don’t seem to have that many issues rewriting system components into Rust, and they have the additional challenge of remaining binary compatible with the C(++) code that came before it.
The OEM also pays for the UEFI firmware and the licenses for the HDMI patents. When it comes to essential software, which Windows is for most customers, the price is included.
There are devices that optionally come with Windows Pro, and in those cases I can see the price difference making a practical difference.
It’s a real shame. I would’ve loved running the Windows 7 or Windows XP userland on the Windows 11 kernel.
The OEMs also pay for the license for video playback patents and for UEFI firmware to be developed. Windows is just part of the formula for the vast majority of Windows compatibles.
Huh, last time I checked that didn’t work. Guess they must’ve fixed it at some point! Good to know!