Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XML is the future

bitecode.dev

Post reply on HN
Print view View original

251–260 of 408 posts

Re: XML is the future

#251

Post by ilyt »

shocks wrote: post #187
ilyt wrote: post #178

Earlier quoted context omitted.

As an admin of PHP apps at that time I can sincerely say screw you, you're lying. PHP apps breaking because new version of PHP shat on compatibility was pretty common, and weirdly enough got more common in newer versions. You also had to keep unholy combo of php extensions (why that garbage is in app server and not app) and server config because the special little retard that designed the app decided he must do somet…

> forget about it for a few years No version upgrade required. :D

If you piss on security sure but then every language is "easy" if you just need to deploy once and forget about the server for forever

Re: XML is the future

#252

Post by [deleted] »

pyeri wrote: post #55
noduerme wrote: post #16

I really love this review of the past 20 years. It gets to the heart of the hype/FOMO cycle that's driven so many of these stacks to short-lived superstardom, and then quickly into irreversible technical debt. I have never really understood this. My favorite comment I ever got on a coding board when I was debating the pros and cons of building my next project in the trendy platform of the day was >> STFU, go out and…

I wouldn't call XML entirely a hype or FOMO, it has become part of what we call the modern web even today. 1. The very language that websites are written in today (HTML5/XHTML) are nothing but XML dialects. 2. React's JXS language which many sites use today is also an XML dialect. 3. RSS and ATOM standards used to publish your blog or website feeds are XML standards. 4. JSON replaced XML only as an efficient transpor…

[deleted]

Re: XML is the future

#253

Post by mrighele »

edejong wrote: post #179
shocks wrote: post #172

Earlier quoted context omitted.

Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

> In the meantime, your PHP app had 40 major security flaws

I just did a "npx create-react-app text" and I got

"74 vulnerabilities (69 moderate, 5 high)"

40 major security flaws in 10 years sounds almost like a bargain.

Re: XML is the future

#254

Post by xorcist »

Traubenfuchs wrote: post #142
devjab wrote: post #61

I worked a decade in public sector digitalisation in Denmark, where for some reason they still use a lot of SOAP and thus XML. I’m not so against XML in theory, but I hate it in practice. You’d have these completely over engineered solutions where you’d basically need to call a separate micro services for every “field” of anything. So if you wanted a name, a ssn, and, an address for a citizen you’d need to make sever…

This is not the fault of SOAP/XML at all though? There'd be several ways to offer a soap service that dynamically returns the set of requested fields.

It's the XML equivalent of having SQL tables with two columns, "key" and "value".

(I've seen variants of that far too many times for it to be a joke.)

Re: XML is the future

#255

Post by Quarrelsome »

DarkCrusader2 wrote: post #245
gnulinux wrote: post #7

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…

I was stuck maintaining a solution using an abandonware internal transport layer built on technology that died in 2004 and an abandoned ORM on an EAV schema database over SOAP backend in 2022 with much the same "no business value in it" argument. "We're trying to sell the company so profit is of the most importance" transitioned into "we bought you because you make money". So instead we increased our maintenance exposure by adding more necessary features to the wobbly pile (or 'fixing' broken ones) as opposed to resolving the mistakes made over twenty years ago.

Of course the dickhead architect would use articles like this OP as justification for why all of this wasn't a problem.

Re: XML is the future

#256

Post by mrighele »

mrweasel wrote: post #219
shocks wrote: post #189

Earlier quoted context omitted.

If you forget about a PHP container for a few years it will /also/ have 40 new vulnerabilities. Actually, containers are worse because OS updates of core shared libraries do nothing. You have to rebuild every damn container. Setting up monitoring for your docker containers is also a whole thing. :) I think you’re taking my example a little too literally. My point is not that docker/k8s/whatever is bad; just that the…

> You have to rebuild every damn container. I can say with great certainty: Almost no one rebuilds their damn container anywhere near as often as the the gray-beard in the basement updates the Debian packages on the the server that runs the container. I had the debate with a client, we did monthly security update, unless something horrible happened. The client was rather upset that we didn't patch more frequently, li…

> I can say with great certainty: Almost no one rebuilds their damn container anywhere near as often as the the gray-beard in the basement updates the Debian packages on the the server that runs the container.

Most probably the gray-beard simply enabled "unattended-upgrades".

You can do something similar with a container (track the security fixes for the packages used, force rebuild and deploy when needed), but it is a bit of work and I don't know of any ready solution.

Re: XML is the future

#257

Post by CoastalCoder »

xorcist wrote: post #244
edejong wrote: post #179

Earlier quoted context omitted.

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? They don't. In fact, as someone who works at the more modern end of these things, I'd suspect that "no meaningful monitoring" probably correlates quite well with cloud era microservices thingies. But we can't blame the tools, that space is just younger and by nat…

> But we can't blame the tools, that space is just younger and by nature contains more immature stuff.

I think the article's point was that the industry is perpetually young and immature because it keeps (unnecessarily) chasing fads.

Re: XML is the future

#258

Post by Quarrelsome »

xorcist wrote: post #244
edejong wrote: post #179

Earlier quoted context omitted.

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? They don't. In fact, as someone who works at the more modern end of these things, I'd suspect that "no meaningful monitoring" probably correlates quite well with cloud era microservices thingies. But we can't blame the tools, that space is just younger and by nat…

> How does Kubernetes, microservices and front end frameworks fix that?

Doesn't being in a container mean its much easier to rebuild it from zero and thus allowing security updates to be more regular?

Re: XML is the future

#259

Post by Quarrelsome »

mrighele wrote: post #253
edejong wrote: post #179

Earlier quoted context omitted.

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

> In the meantime, your PHP app had 40 major security flaws I just did a "npx create-react-app text" and I got "74 vulnerabilities (69 moderate, 5 high)" 40 major security flaws in 10 years sounds almost like a bargain.

now read those flaws, compare them to the worst in 2004 and tell me they're the same. They're not the same because the internet was insecure as fuck in 2004 and these days security researchers motivations to receive bounties result in considerably more situational (and significantly less severe) security issues.

Re: XML is the future

#260

Post by mathgeek »

DarkCrusader2 wrote: post #245
gnulinux wrote: post #7

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…

Today’s beloved tech with well maintained docs is tomorrow’s institutional knowledge tech that companies rely on.
Post reply on HN