• 0 Posts
  • 27 Comments
Joined 1 year ago
cake
Cake day: August 28th, 2023

help-circle








  • But Jaskier isn’t gay in the show, either. He’s bisexual.

    Oh yeah, that completely changes things, and does completely fit in with the character.

    I do have to admit that I did not watch the latest season, not because of Jaskier but because of what they did to Eskel in the previous season. So I took the other commenter’s word that the character was made gay. I guess that’s what I get for assuming honesty until proven differently on the Internet.


  • I believe they’re referring to the character of Jaskier/Dandelion, who in the lore is a womanizing, promiscuous bard. Pretty much the DnD bard player character archetype. It is also pivotal to a number of plot points, because the character’s womanizing habits frequently land him in trouble, making him a “damsel in distress” supporting character. Which in itself works better when the character is straight because it subverts the trope.

    The thing is also that there’s plenty of characters in the story who are or could be made gay without serious repercussions to the plot.





  • The CIS benchmarks for Linux are a good start. There are some off the shelf tools that let you run those, notably linux-bench. Another tool in a similar fashion is lynis. You can also use eBPF tools like callander to examine your workload behaviour and help tighten your seccomp policies.

    Once you’ve established a baseline for your system, you’ll next want to harden your environment. This means network scans, OWASP, etc. As far as off the shelf tools go, OpenVAS is quite popular even in Enterprise environments.

    Finally there’s the continuous security tasks. Continuous package updates, runtime security, log analysis, etc. There are some free tools that cover part of this like Security Onion, but if the price is right a SaaS tool can save you a lot of time.






  • My point is Kubernetes is a hack (a useful hack!) to synchronize multiple separate, different systems in certain ways. It cannot provide anything close to something like a single system image and it can’t bridge the discrete model of computation that Unix assumes.

    Kubernetes is not intended to provide anything like a single system image. It’s a workload orchestration system, not an operating system. Given a compatible interface (a runtime) Kubernetes can in theory distribute workloads to any OS.

    All these features require a lot of code and complexity to maintain (latest info I can find is almost 2 million as of 2018). Ideally, Kubernetes is capable of what you said, in the same way that ideally programs can’t violate Unix filesystem DAC or other user permissions but in practice every line of code is another opportunity for something to go wrong…

    Just because something has more security features doesn’t mean it’s actually secure. Or that it’s maintainable without a company with thousands of engineers and tons of money maintaining for you. Keeping you in a dependent relationship.

    I’m not going to argue that Kubernetes is not complex. But as I stated previously Kubernetes as a bespoke ecosystem is less complex than configuring the same features with decoupled systems. The requirements for an orchestrator and the challenges (technical, security, human, etc) to manage said orchestrator are higher. All else being equal, Kubernetes has implemented this in a very lean way, delegating networking, storage, and runtime to pluggable providers on the left, and delegating non-basic workload aspects to operators on the right. It’s this extensibility that makes it both popular with operators and makes it appear daunting to a layperson. And going back to security, is has provably shown to have a reduced attack surface when managed by a competent operator.

    So? I don’t expect many of these ideas will be adopted in the mainstream under the monopoly-capitalist market system. It’s way more profitable to keep selling support to manage sprawling and complex systems that require armies of software engineers to upkeep. I think if state investment or public research in general becomes relevant again maybe these ideas will be investigated and adopted for their technical merit.

    So you’re… what, dismissing HTTP because it has been adopted by capitalist market systems? Are you going to dismiss the Fediverse for using HTTP? What about widely adopted protocols? DNS, BGP, IPv4/6, etc?

    How about we bring this part of the discussion back to the roots? You said that HTTP and REST as communication protocols seemed strange to you because Unix has other primitives. I pointed out that those primitives do not address many modern client-server communication requirements. You did not refute that, but you said, and I paraphrase “9P did it better”. I refrain from commenting on that because there’s no comparative implementation of complex Internet-based systems in 9P. I did state though that even if 9P is superior, as you claim, it did not win out in the end. There’s plenty of precedents for this: Betamax-VHS, git-mercurial, etc.

    “Highly available” is carrying a lot of weight there lol. If we can move some of these qualities into a filesystem layer (which is a userspace application on some systems) and get these benefits for free for all data, why shouldn’t we? The filesystem layer and application layer are not 2 fundamentally separate unrelated parts of a whole.

    (My emphasis) It’s not free though. There’s an overhead for doing this, and you end up doing things in-filesystem that have no business being there.

    It’s not a flawed anecdote or a preconception. They had their own personal experience with a cloud tool and didn’t like it.

    *Ahem*:

    “Nobody really uses Kubernetes for day-to-day work, and it shows.”

    That is not an experience, it’s a provably wrong statement.

    The assumption among certain computer touchers is that you can’t use Kubernetes or “cloud” tools and not come away loving them. So if someone doesn’t like them they must not really understand them!

    That’s a very weird assumption, and it’s the first time I’ve heard it. Can you provide a source? Because in my experience the opposite is the case - there’s no community more critical of Kubernetes’ flaws than their developers/users themselves.

    They probably could’ve said it nicer. It’s still no excuse to dismiss criticism because you didn’t like the tone.

    I dismissed the criticism because it makes an appeal to pathos, not to logos. Like I said, there’s plenty of valid technical criticisms of Kubernetes, and even an argument on the basis of ethics (like you’re making) is more engaging.

    I think Kubernetes has its uses, for now. But it’s still a fundamentally limited and harmful (because of its monopolistic maintainers/creators) way to do a kind of distributed computing. I don’t think anyone is coming for you to take your Kubernetes though…

    No my Kubernetes. I use it because it’s academically interesting, and because it does the tasks it is meant to do better than most alternatives. But if CNCF were to implode today and Kubernetes became no longer practical to use then I would just pivot to another system.

    I’m not going to argue whether it’s a harmful way of doing distributed computing based on their maintainers/pedrigee. That’s a longer philosophical discussion than I suspect neither you or I have time for.


  • Probably need to keep in mind incidental versus essential complexity here.

    Go on…

    Because this is how much of what we use already is implemented. Significant effort goes in to portability, interoperability and balancing compromises. When I’m doing software development e.g. writing HTTP APIs (of which I apparently know nothing about ;) ) - I feel like I’ve got a responsibility to carefully balance what I expose as some user-configurable thing versus something managed internally by the application. Sometimes, thankfully, the application doesn’t even have to think about it al all - like what TCP flags to set when I dial some service.

    In the case of vmalert, the binary makes no assumptions as to default behaviour because it was not meant to be run standalone. It comes as part of a container with specific environment variables, which in turn is packaged as a Helm chart which has sane configurations. Taking the vmalert binary by itself is like taking a kerberos server binary without its libraries and config files in /etc files and complaining that it’s not working.

    You bring up containers which is a great example of some cool features provided by the Linux kernel to solve interesting problems. If you’re interested, have a look at FreeBSD’s Jails, Plan 9 and LXC. Compare the interface to all these systems, both at the library level and userspace, and compare the applications developed using those systems. How easy is it to get going? How much do I need to keep in my head when using these features? Docker, Kubernetes, and the rest all have made different tradeoffs and compromises.

    I am very well versed in jails, chroot, openvz, LXC, etc. OCI containers are in a different class - don’t think of them as an OS-like environment, think of them as a self-contained, packaged service. Docker is then one example of a runtime runtime on which those services run, and Kubernetes is an orchestrator that managed containers in runtimes. And yes, there are some tradeoffs and compromises, but those are well within the bounds of the Pareto principle - remove the 10% long tail of features on the host, reduce user-facing complexity by 90%.

    Another one I think about is SQLite. Some seriously clever smarts. Huge numbers of people don’t know anything about for-loops, C, or B-Trees but can read & write SQL. That’s technology at its best.

    Are you arguing that Kubernetes doesn’t do that for you? Because with Kubernetes I can say “run the service in this container with these settings and so many replicas”, attach some conditions like “stop sending traffic to any one container that takes longer than N seconds to respond” and “restart the container if a certain command returns an error”, and just let it run. I can do a rolling upgrade of the nodes and Kubernetes will reschedule the containers on any other available node, it can load balance traffic, I can update the spec of a deployment and Kubernetes will do a zero-downtime upgrade for me. Try implementing the same on a Unix system. You’d need a way to push configs (Ansible, Puppet, etc?). You need load balancing and leader election (Keepalived?). You need error detection. You need DNS. You need to run the services. You need to ensure there’s no library conflict. There’s a LOT of complexity that a Kubernetes user does not need to worry about any more. Tell me that’s not serious smarts and technology at its best.

    What I’m struggling with are thoughts of significant vested commercial interest in exposing this kind of detail, fuelling multi-billion dollar service industries. Feelings of being an outsider despite understanding how it all fits together.

    You seem to be conflating Kubernetes and cloud services. Being a cloud native technology does not mean it has to run on a managed cloud service. It just means that it has certain expectations as to how workloads run on it, and if those expectations are met then it makes certain promises about how it will behave.

    Have you ever written this kind of software before?

    I have contributed to several similar open source projects, yes. What about it?

    It sounds like you are comfortable with the status quo of this part of the software industry, and I’m truly jealous!

    I am comfortable with my knowledge of this part of the software industry. There is no status quo - there’s currently an equilibrium, yes, but it is a tenuous one. I know the tools I use today will likely not be the same tools I will be using a decade from now. But I also know that the concepts and architectures I learn from managing these tools will still be applicable then, and I can stay agile enough to adapt and become comfortable in a new ecosystem. I would urge you to consider the same approach for yourself.