Earlier quoted context omitted.
> But it feels like I'm stuck in a Franz Kafka novel. Director of O(o)ps: Funny that you should mention that...
https://kafka.apache.org/
Franz Kafka meets the Wild West.
XML is the future
191–200 of 408 posts
Re: XML is the future
#192Earlier quoted context omitted.
> I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. Definitely -- I'd say that these questions force the understanding of the fundamentals, because that's what you get down to ("fundamental"/irreconcilable differences). The problem is that fundamentals can be similar, and sometimes the differ…
A better comparison would perhaps be “ansible” vs “puppet” vs “chef”. I wrote everything in shell, then puppet, then chef, then ansible. Doing literally the same thing. Because fads.
Taking this comment in good faith, because HN...
Do you really not see any difference between Ansible and a shell script?
Even just the move between shell and bash/csh/tcsh/zsh whatever else can make a marked difference in productivity and ergonomics.
Re: XML is the future
#193Any interaction I've had with XML has been a negative experience.
Can someone explain to me how JSON is not superior in every way?
Re: XML is the future
#194Earlier quoted context omitted.
> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that…
I believe there's a spiraling pattern, where the same ideas reappear every N years but with slight internal or ecosystem changes. I'm not sure if we're running or circle of if there's a real slow progress.
I think it's real slow progress, and sometimes even, quite fast.
It's the same ideas, but I will assure you that most of the large things that people get crotchety about are legitimate moves forward.
People were complaining about "docker" (i.e. cgroups + namespaces + some CLI UX) not too long ago and now you'd be dumb to try and deploy most applications without at least having that there.
How many people are wrangling their own cgroups and namespaces (not counting systemd, which is another thing people fought, tooth and nail)?
Should we all be doing 1 user per workload like the good 'ol days?
Or maybe 1 machine/VM per workload like the 'ol 'ol days?
Re: XML is the future
#195Earlier quoted context omitted.
To give another perspective, at my first job deploying meant sshing into production and execute a make script. It worked 98% of the time, and you'd be having fun the 2% else. It sure wasn't the state of the art, but wasn't something people would yell at you for. We needed windows machine because of corporate policy and remoted into a Solaris box to dev, as a vague replica of production. Fast forward to today, and we…
> Fast forward to today, and we can run a production replica on our local machines at home, the CPU architectures aren't even the same, and code will be deployed through the CI automatically after the tests all pass. And someone we squandered most of the CPU performance increases in the process, and the super-duper architecture/CI/delivery pipeline fails almost the same percentage of the time, but needs 10x the peopl…
CI and delivery failing 2% of the time just means you haven't deployed and you just retry. At least you're not poking things in prod.
I'm with you on the CPU gains going down the drain and 10x more people working on it, but it's also a sign that we're talking IT operations more seriously and there's enough money to cover these kind of inefficiencies.
Re: XML is the future
#196> XML is the future That kinda happened, just not in the way everyone thought. In 2023, JavaScript XML is the most popular way to develop web applications, and a common choice for mobile and desktop applications. --- EDIT: JSX/React/React Native, in case that wasn't clear.
XML underpins of a lot of standards that are ubiquitous in their areas, eg, RSS, XMPP, GPX/TCX. Tons of government APIs still use XML. In the EU, in the financial sector at least, pretty much all regulatory reporting uses XML. And when the regulators decide to make some of that data available to the public, it typically uses XML as well. Companies in many countries are required to tag their financial statements using XBRL, based on XML.
XML has not failed. It has just achieved the status, coveted amongst serious technologies, of being boring.
Re: XML is the future
#197Earlier 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.
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…
The biggest thing with containers is, these 40 vulnerabilities won't matter as much if they're about erasing your directories or killing your machine. It will get rebooted in a pristine state and an attacker would need to stick there killing it at every reboot to have lasting effect.
Which is also the point of monitoring a container, which is fairly reliable nowadays, compared to managing your own health check service to ping your box to check if it's alive.
All in all, I think k8s is way too complicated for what it does for most people, but administrating servers was also a complex task to begin with, and the things sys admins were dealing with looked nightmarish to me. Heck, there was a time companies would have their own SMTP in house...
Re: XML is the future
#198Earlier quoted context omitted.
> XML is somewhat unique as a concept. There was nothing like it and still isn’t. That's just incorrect. XML is a proper SGML subset, nothing more. Why do intelligent people like you come here to lecture about markup languages but don't even bother to read the XML specification which clearly states (as in chapter 1, sentence 1): > The Extensible Markup Language (XML) is a subset of SGML that is completely described i…
Indeed it is. But being simplified and separated from SGML it somehow revealed a clearer idea of what a notation is. SGML is a markup language and as far as I remember it (not too well), it never was disassociated from the text; maybe it was possible, but not widespread. XML without text content is perfectly usable and is even more convenient.
What you're saying is that you were first introduced to these concepts when XML came up. Totally understandable given the hype, but I can only suggest to look deeper, where things become interesting. For example, have you ever wondered about the reason for XML's obvious, excessive redundancy requiring matching end-element tags to be specified in full, when "" (as is possible with SGML) is sufficient given that XML doesn't have overlapping markup (as in SGML CONCUR)?
As to use of markup for non-text, I have to disagree. Markup is precisely for rich text. For representing discrete data there are much simpler and more compact alternatives not involving attributes-vs-elements decisions and hierarchical addressing of nodes which don't make sense where there isn't a concept of "rendering" a document to a user.
Re: XML is the future
#199Earlier quoted context omitted.
I believe there's a spiraling pattern, where the same ideas reappear every N years but with slight internal or ecosystem changes. I'm not sure if we're running or circle of if there's a real slow progress.
I think it is mostly just adopting. To new hardware, new demands, new plattforms. There is maybe some progress on a academic level, but I don't think we progress fast on the fundamental level, on how to write better code. There are slight improvements here and there, but it is mostly just different. And more complex. Or rather new tools are needed because everything gets more complicated (some say bloated). That bein…
Yes, that is indeed part of it. Everything changes, the ideas have to swim on top of that moving soil. And at times some integration occurs where a lot of ideas suddenly merge into a new cleaner brick.
Re: XML is the future
#200I’m surprised with the lack of mention of Android development.