Posts by rozenglass@anime.website
(DIR) Post #A8SEI4jyX27KbWFKoi by rozenglass@anime.website
2021-06-19T20:11:37.862185Z
1 likes, 0 repeats
@yes they have the computers, just give them your data, and give them your money. all the rest is yours.
(DIR) Post #A8SF1Fj6X6j3hwNgps by rozenglass@anime.website
2021-06-19T20:19:46.822073Z
1 likes, 0 repeats
@enigmatico STOP! Your data is ReQuIrEd!Accept or aCcEpT!What settings do you have?Ah! Those are acceptable settings.You may proceed.Have a good day,"master".
(DIR) Post #A8SImoo6Do4tyt5eaW by rozenglass@anime.website
2021-06-19T21:01:59.352700Z
1 likes, 0 repeats
@fluffy @yes yes! I mean, adding four or five million lines of code, written by 3000 different authors, and with 2000 open issues of which 300 are marked as bugs, is _bound_ to make your production environment a lot more reliable, and your data a lot more secure. Trust me, I tried, and now I must propagate this nonsense to justify the three years of my life that I wasted on this thing, and ensure that I will still find a job in the future... Maybe I should start a course about it too, and tell people how amazing and in-demand it is! /seh, excuse me, I feel dirty now, I must go wash my mouth with the gentoo on my server I guess.
(DIR) Post #A8SS7sLl8xkUdbwxrU by rozenglass@anime.website
2021-06-19T22:46:38.553948Z
2 likes, 2 repeats
@fluffy @yes I made, with one other dev, the backend / infrastructure stuffs for some mid-sized company, serving their mobile apps and internal services and what not. serves a few tens of thousands of users concurrently at any moment, and with some 20 million events daily. maintaining that for almost three years so far.k8s (and its ecosystem in general) is super complex, and has way way too many concepts, it was probably over-kill for our size. but tbh it wasn't that bad in practice, and some features are really comfy. but when things go wrong, you have to dig in deep, so many moving pieces all interacting in the weirdest ways. maybe I'm just too idealistic, wanting everything to be minimal and clean and simple and straight-to-the-point. I don't know. My current position is that you _probably_ don't need k8s, ever, because one good machine or two will serve you well in most cases, if your system is well built and written. k8s and its ilk are mostly redundant re-implementations of tools that we already had on the OS-level for a long time.But I also admit that there's no solution, on the OS-level, for abstracting and orchestrating large-scale clusters hosting critical applications. The closest we came to a "cluster-aware" operating system was probably Plan9. Linux is not cluster-aware, so we end up re-inventing everything in a cluster-aware system, at a higher level; service management, logging, monitoring, users and permissions, etc.It is obvious that we have a "hype" phase at our hands, with containers, and Docker, and Kubernetes, and "cloud-native technology". It's been going on for a few years now. Everyone thinks themselves the new Google, operating at Netflix-scale, or something, and wants the most complex system possible, thinking that it will make them the cool kids. I operated a Kubernetes cluster, and a Docker swarm, for a few years each, and so far I have very strong reservations against the mindless hype crowds, and their utopian dreams and claims. Most of it big-corp marketing and PR.Containers themselves, in their most fundamental sense, as kernel process namespaces with cgroups to define some limits, some virtual networks, etc. are pretty good imho. They are the simpler, minimalist, and more reasonable solution to most cases where virtual machines would have been traditionally used. I like containers. Docker and k8s are twisted corrupt overloaded corporate versions, far removed from their pure origins. If you are curious, try constructing containers by-hand, or using LXC, or something like that, and get a feel for the "containers as simpler better VMs" thing. Without all the trendy over-hyped nonsense.I just feel sad that many new kids these days are growing in a Kubernetes/Docker/Cloud world, thinking in their terms, and never learning about the simpler reliable good ol' stuff. The new kids be like "but how can I redirect traffic to my app pod on that node without a kubernetes ingress service?!?!!". and we have to sigh and respond: "you proxy-pass requests to your application hosted on that server by writing a goddamned config file for your NGINX reverse-proxy".On second thought, both sound stupid, everything sucks, and we're just a bunch of autistic nerds getting triggered all about it :PMay your machines clock true.
(DIR) Post #A8SSNj1XaMeoLZ3CK0 by rozenglass@anime.website
2021-06-19T22:49:30.514792Z
0 likes, 0 repeats
@yes @fluffy sometimes I wake up and have to wonder how come it's all still running, and how the heck our world isn't burning to the ground already...wait... :3:
(DIR) Post #A8SYchYjucq7sD6Tzc by rozenglass@anime.website
2021-06-19T23:59:25.949515Z
1 likes, 1 repeats
@fluffy @yes I liken K8s to an operating system, albeit a cluster-aware one, replacing Unix/Posix workflows. Many of the "cloud-native" tools surrounding it are re-implementing Unix/Posix tools that have been around for a long time.For example, when you use K8s you will probably want a logging system, and now you install fluent-bit and collect the logs to Loki, or some ElasticSearch database, why? We already had logging in Unix, and it worked! Log files were nice, and you could just grep over them and find anything you want. But the problem is that they are _not cluster-aware_ by default. You have 20 machines, now you have 20 log files, so you need something above, that unifies them all.Same for example for cronjobs. Kuberentes implements it's own cronjob mechanisms that should be used to schedule cronjobs that can run on any available node that meets your constraints, but we already had cronjobs in Unix. Problem is, again, they are not cluster-aware.Unix user accounts and permissions? Well, nope, now you have Kubernetes namespaces, roles, role-bindings, and access tokens. Unix mail-server sending you notification when errors occur? Nope, now there's a sentry node that collects events and statistics about errors from the swarm and sends you emails when failure rates reach some threshold. Unix `top` command to see resource usage? Nope, now there's a Prometheus time-series database that collects metrics, log-shipping daemons that send them, and a Grafana dashboards that display them. Using your Unix init-system to start services, and some daemontools to watch over them and restart them when they fail? Nope, now it is Kubernetes schedulers, reading YAML-defined API objects from a number of distributed etcd databases (after they vote and reach consensus).Want to make an LVM volume to give some disk space for your new application, no no no, now you have to make a Volume Claim, defining your requirements, and then nodes in the cluster will volunteer to serve your claim if they have attached disks that fit the request, by binding their volumes to your claim, otherwise a storage provider will provision new hardware for you according to your requested spec. Want to install an app from a maintained repo? .deb? .rpm? .pkg.xz??? no! Now you have a Tiller application chart server to which your Helm clients call to request new installations of applications described as Helm charts, that basically get fetched by Docker daemons, on the machine to which the workloads were scheduled, from a container image registry. etc. etc. you get the idea.The fundamental difference, in my view, between every Unix/Linux/Posix traditional tool that I mentioned, and the new "cloud-native" tools is that the Unix tools never considered the existence of other machines. The OS was about _this single computer_, never about other computers. The grand scales of operations we face today transcend the capabilities of any single computer, requiring this new "cluster-awareness", and requiring a remake of all fundamental Unix tools to deal with the fact that "You are not alone", but one lowly replaceable machine, among a fleet of tens of thousands.It seems that distributed systems, by their nature, have an extremely high-level of inherent complexity. This, along with huge funding, basically unlimited resources, a ton of scope-creep to fulfill crazy marketing promises, and hundreds of different teams of developers building their parts in relative isolation from each others, end up causing most large-scale distributed systems projects to become unwieldy ugly giant abominations. Few actually need such tools, few would benefit from such scale, but _all_ want in on the hype, and that is my main gripe.That, and my inherit personality trait of hating, hating!, complexity. I want my machines to serve me and mine, I want to be in control, not have them act out on their own by the rules of some google developer who thought that whatever he thought was a good idea.gotta go look at an alpine installation now for a few minutes to cleanse my soul :cirnoForReals:
(DIR) Post #A8SfWtDkLGP7yxSa3c by rozenglass@anime.website
2021-06-20T01:16:48.523670Z
1 likes, 0 repeats
@pomstan @fluffy @yes > a (((unix))) retard wannabe like you has no right to criticize themoh I'm not exactly criticizing them, I'm criticizing the misplaced obsession by smaller companies, in using them where their use is not warranted. Especially when the teams there are not exactly experts in the domain. Throwing docker and k8s and containers in just because "it's better" without actually realizing that they are trading simplicity for complexity without good benefits for them. I've seen enough teams completely paralyzed by their tools because they just brought in too many, and no one knows how to fix them when they break. It is literally my job, working with a number of client companies, to get them out of such ruts, as an SRE / DevOps consultant. Countless cases of unwarranted complexity brought in by inexperienced unrestrained hype-following devs paint my outlook on the matter.What is the solution for a bug in the system that causes it to go into an infinite loop, taking the whole service down? "Hello, can you setup containers for us on Amazon ECS? Containers can scale fast!" -- said the engineer that was my point of contact at my next to last gig.I already concede that large-scale systems have huge inherit complexity, and that Kubernetes, among other orchestration systems, are good attempts at fixing them. I would use Kubernetes again if I had to architect a large system with many teams working on it. I have nothing against its use in the right place.> a (((unix))) retard wannabeSorry. I guess you are projecting me onto some 4chan persona you have imprinted in your mind. I am not a Unix fan in the least, I'm even worse; a smug Lisp weenie :P Please do not lump me with a generic strawman persona and pass judgements on me like that. I don't _hate_ Unix, (I don't hate most things tbh), but I've read the Unix Haters Handbook :D> those rules are written in blood and sweat of hundreds of SREs trying to fix shitcode at scaleThanks for appreciating my work, and the work of my fellow SREs, we are rarely appreciated, even when we get a call at 2AM to remotely bring the system up again when the servers are _literally on fire_, and users of the system literally have to use it to plan their preparations for medial surgical operations in a few hours. I wrote my fair share of complex orchestration systems to deal with complex problems. It is by necessity. I just wish my fellow SREs would collectively focus on making a good distributed cluster-aware replacement for Unix, instead of wasting millions of collective man-hours trying to build new layers of abstractions on top of systems built on fundamentally incompatible paradigms, resulting in hybrid abominations that are, in many cases, more fragile than they could be.We are plumbers, and pardon my words, cleaning shit all the time. I respect my fellow plumbers, and their enormous efforts at cleaning shit. I just wish things weren't so shit in the first place.> of some google developer who thought that whatever he thought was a good ideaI have been bitten quite a few times by stupid decisions of Google (and Apple) developers. Sorry, not sorry. The majority of what they do is of acceptable, if not very high, quality, but like everyone else, they have their share of stupid nonsense. Stupid nonsense that has to be maintained forever for backward-compatibility. Everyone makes mistakes, the hundreds of bugs currently open against K8s are proof enough. But when I make mistakes, I have only myself to blame, and total control to fix it. When they make mistakes, I am left powerless, completely at their mercy, and I _will_ blame them.> That, and my inherit personality trait of hating, hating!, complexity.Note that I mentioned my personality here to point that it is a _personal preference_. I deal with complex systems all day everyday, I know complex systems are complex, I respect the work and collective experience of my fellow developers. BUT, their code is never touching _my_ personal non-production systems. Because when I go home I would like to admire something simple that works, and forget about all the pain I had to deal with because some developer doesn't understand that their query basically pulls in 200 GiB of data over the network to process them in memory, and that the machine doesn't have that much memory. I come home to simplicity to relax, until I get paged, and some client has their whole system down again.sorry if I get snarky sometimes, sometimes the frustration and stress gets to me.hope you have a nice day :cirnoSmile:
(DIR) Post #A8Sg8njvAWTBzGaSTA by rozenglass@anime.website
2021-06-20T01:23:40.829768Z
1 likes, 0 repeats
@pomstan @fluffy @yes Oh, it's not about me. It is about the developers who have to live with the possibility that I might not be available to help when things go wrong after my 3 months contract is up, or if I get hit by a bus, and they couldn't find a replacement for months. We are not the US, and finding SREs who know their stuff and don't cost more than the company's yearly budget, is hard.The more new concepts and tools I leave behind, for them to learn, the less likely they will be able to tweak and fix stuff safely on their own. Not because they are retarded, but because this is not their specialization, nor do they have the time to learn and understand it when something goes wrong.
(DIR) Post #A8YGLg9nEyJENHvbCS by rozenglass@anime.website
2021-06-22T18:02:56.028772Z
2 likes, 1 repeats
@fluffy @finlaydag33k in my experience, participating in some startup competitions, and looking for investors, and stuff, the VCs seem to care little about the looks, or even the technical concepts. My experience is that they seemed much more affected by two things: First, the founders' personality, charisma, ambition, enthusiasm, perceived intelligence & sharpness, etc. They are mostly not judging your project, they are judging _you_, because they know they are not betting on your project, but they are betting on your team. Second, they are very interested in market analysis stuff, and statistics; they want to know the potential market size for this product, the potential revenue, what the competitors are, what edge you plan on using to exceed your competitors, what are your monetization plans, etc.Also, a hugely effective factor is already existing results. Nothing catches the eyes of investors much as numbers of already existing customers, or already present revenue. You can talk to them for an hour about your great idea, and the problems it solves, and how good the UX and UI and technical side are, but nothing, to them, can trump the words "and we already have 5,000 users, and 200 paying customers". That there is near-instant victory.Of course, not saying that there are no investors that are interested in idea stuff and concepts, but they don't seem to be the majority (at least in my locale, Turkey, and in my experience, which is more on the side of financial & banking industries). You can probably find more idea-inclined VCs in some pockets of creativity, like Y-Combinator, and similar Silicon-Valley ventures, but the competition there is fierce; you'll be going against people trying to do the weirdest most cutting-edge things, and they still judge your person and personality first and foremost, before considering your ideas (at least afair reading some Paul Graham essay, one of the founders of Y-Combinator).Now, for the main question of how to make a frontend look good, my advice is: hire, or partner with, good UX and UI designers who know the web, and know their stuff, pay them good, and let them do their magic, with input from you, and from some good representitive users, for best results. Barring that, you have to do it yourself. Start with the UX, because UI, however beautiful, will not amount to anything if the UX is bad, and with a white board, or flow chart drawing tool, or a mind-map, or even some paper and a pen, draw and think thoroughly through the flow and user experience and use-cases of at least the main minimal-viable features of your application, and then implement them as the simplest possible prototype, using the least amount of libraries you can tolerate, and preferably no big frameworks. Go for the most neutral default look, with default text inputs and buttons and everything. You probably should have less than a hundred lines of CSS here at this stage. The prototype is there for you to test and get a feel of how good the UX is, and if it fast and efficient enough. Maybe even give it to a few friends and family members, or power-users and experts in the domain, to try it out and get some feedback as fast and early as possible.When you feel like you got the UX right _enough_, then it is time for the UI and style. Now, here, there are multiple ways to go about it; you can either pick up your Gimp or Inkscape, and go through your website, page by page, beautifying every page to make it look good, or, you can think about the whole site holistically, and try to build a general visual style guide and brand identity for the whole project. With this approach you first define fundamentals, like general "feelings" the design should invoke, and the primary color pallet, and such, and then you go through your pages, separating independent clear-cut components, and designing the visual and interaction style for every component in isolation, to make a reusable consistent style, and in the end, have a foundation that can be used to build any new page or feature, without having to specially think much about its stylistic design every time.Both approaches have their good and bad. The first approach might be considered "dated" by some, but only because we are heading into a more consumerist internet, where everything must be reusable and cost-effective. The first approach tailors the style of every page or feature to that feature specifically. This usually results in the UI enhancing the UX, and can be a very unique creative tool, with much freedom, in the hands of a good designer. The second approach is, like I said, cost-effective, and it is usually more coherent in the hands of less experienced designers, or a large team of designers, _but_ you have to test well, because sometimes the design-in-isolation approach results in weird unanticipated interactions in some places, especially the less-trodden paths.Anyways, my position is that any thinking about making things that _actually_ look good, in a professional manner, never starts with the frameworks or pre-made assets, but at the fundamental _design_ level, made specifically for your own application. My experiences with multiple projects adopting the generic "good looks" of an existing framework is that you get "generic" at best, and "completely broken" at worst (or more specifically, whenever you try to do something remotely unconventional with your web application).Oh, and all the talk about "saving time" by using frameworks is rubbish in my experience. With any complex application, especially with multiple team members, you spend more time fighting frameworks usually, than actually building stuff. I worked for years with Bootstrap (and like 3 or 5 other CSS frameworks), DevExtreme, Teleric, Ionic, that Material toolkit for Angular, and Wordpress themes, and nothing _ever_ beat writing things from scratch in terms of long-term time efficiancy. It is a trap. You usually get things up and running much quicker with the frameworks, because you have generic requirements at first, then as your requirements become more sophisticated, and you adopt to your domain, it becomes a never-ending maintenance and modification up-hill battle. Building things, methodically, from scratch, "the right way" is slower at first, mostly because of the reasearch overhead, but in exchange you usually gain long-term stability, easier to maintain and modify code, mainly because _you know how it actually works_, then, the better and more fitting UX and the expanded knowledge and experience of you personally, are the icing on the cake.The more ready-for-use libraries and frameworks you use, the more generic your frontend will look, and the harder it is to depart from their collective preconceived assumptions. You will suffer more fighting the frameworks to make them do what you want, and it will be harder to reason about bugs and weird interactions between them. Not to mention the maintenance hell it becomes where every week you have 30 libraries to upgrade, 10 of which are breaking changes, and 5 are important security issues... Every week, _forever_.aaaanyways, another rant, with a hint of negativity, because writing random stuff on fedi is better than me sitting here being depressed in this dark room :3: oh, and disclaimer, I know nothing, take what you will at your own risk :hatdance:here's a cute rabbit maid to make things better:
(DIR) Post #A8bIK9lGz1tkzjjxx2 by rozenglass@anime.website
2021-06-24T05:09:11.001636Z
0 likes, 0 repeats
Fruitcake and Cookies - Sweet Triphttps://www.youtube.com/watch?v=WjQRm-ihASo
(DIR) Post #A8c1JggzYbvomAt9Oa by rozenglass@anime.website
2021-06-24T13:33:22.404652Z
0 likes, 0 repeats
@hyphen not familiar with them. any recommendations?
(DIR) Post #A8c320NPph7iWOQb56 by rozenglass@anime.website
2021-06-24T13:52:35.240491Z
0 likes, 0 repeats
@hyphen guess I will try The Way Of One
(DIR) Post #A8eBU9fi3UYlPJq3FY by rozenglass@anime.website
2021-06-25T14:36:43.828087Z
1 likes, 0 repeats
@Stellar advanced high-tech campfire. I give it 10 panic out of oh god I forgot to tell my sister not to use her laptop before I get some thermal paste for it.
(DIR) Post #A8gi60hfEEJJSMpuZU by rozenglass@anime.website
2021-06-26T15:53:47.405643Z
0 likes, 0 repeats
@hyphen Not bad, but not favorites of mine really. I don't know if I can describe the difference between them and the Sweet Trip one. Well, first off, the album I picked, The Way of One, is mostly pretty far away in genre from whatever Fruitcake and Cookies and Cobalt are, so it is hard to compare them. I don't think anything there stood out to me as something interesting in particular.Now, as for Cobalt, it is pretty close in form and performance, but it is different in _meaning_ somehow. The Koan one is full of a strong sense of wonder, and hope, generally up-beat in a way, but the Sweet Trip one is not. Fruitcake and Cookies is a lot deeper to me. It sounds of of nostalgia, hopeless, a longing for moments that would never come back. The inconsistencies, the breaking tones, the loops, they are not mere musical tools to generate a good sound, but means to reflect the nature of distant memories, and how we perceive them in our minds; fading voices of people we miss, uttering words we still remember, fast changing ambiences jumping from one significant memory to another, random stuff that happened in the background, that we remember, and we don't know why we remember them exactly, old music-box melodies. Short fast-repeating loops punctuate the significant memories with repeated insignificant routine days that hardly have anything in them to remember, so we feel as if they passed in a blink of an eye, barely registering as a blib, but they are not _completely_ ignored, because we still mourn them.And then the way the track ends in the last minute, with it transitioning so suddenly from the rich and chaotic world of memories to the voice of a young man humming along with the voice from his past, humming _alone_, without the _person_ from their past, pulled by life, away from the comfort and wish of the dream realm, and back into the concrete moment, and even though he stops, probably occupied by some menial things of reality, the haunting echos stay, in the back of the mind, never really disappearing, until the end, when the tape is at its end, and everything stops.Maybe I just read too much into things lolMaybe it just so happens that this one reflects something in me, peculiar to me. I did not feel anything of that significance in the Cobalt one, I could not see a narrative or meaning, just generally good sounds. But I know that interpretation is individualistic, and someone else might see something else that I could not see. Heck the composers might not have intended any of this[1], but I guess the audience always has the right to fill in their own self into the blanks, and, generally speaking, the more they could do that with a piece of art, the more they find it significant, and the more they identify with it; they "like it". Well, at least people of the more intuitive types of personality I guess.Anyways, I'll stop now, and save you from any more unsolicited random blasts of emotions :PHave a good day :pat:---[1] although they call themselves "Sweet Trip", so I'm inclined to believe they _did_ in some capacity.
(DIR) Post #A8kgmAo6d7tDgCfN2m by rozenglass@anime.website
2021-06-26T16:31:02.747634Z
1 likes, 0 repeats
@hyphen > I didn't give all my focus to the lyricsme neither. I've been bitten so many times by lyrics ruining whatever images I conjured up in my mind after I look them up lol I prefer to pick up on a few words, fill in others, and build from their.One example of that is "where mermaids drown - One Week" (https://www.youtube.com/watch?v=8AHv6XavakE). I missed only a few words on my first listen, but I built an impression that was pretty different from what the lyrics with those missing words implied.
(DIR) Post #A9WYIFmesh2WBIqaUC by rozenglass@anime.website
2021-07-21T20:06:42.601704Z
0 likes, 0 repeats
@Firelion welcome back :]
(DIR) Post #APnxnQv3g0l9dwe5Zo by rozenglass@anime.website
2022-11-20T19:36:08.106945Z
1 likes, 0 repeats
@r @wowaname I'm okie :)
(DIR) Post #APo35ecvwxsL8kfxc8 by rozenglass@anime.website
2022-11-20T20:35:27.834069Z
3 likes, 1 repeats
hey @wowaname, before this place is gone,I just wanted to thank you for hosting us.a lot happened here those past few years,all the fun, the weirdness, the drama,and it's been tough on you sometimes,but I sure made some nice memories here,and for that I'm grateful.thank you :)and to all of you fellow lovely, lively,free-spirited weirdos: see you all again,sometime somewhere.I will miss this place.and a few final words for the record,of this eternal federated ether:let it be known, forever, thatanime.website was a cool place,and opal, a damn cool admin.
(DIR) Post #APo3erlF6sce0gLv8q by rozenglass@anime.website
2022-11-20T20:41:49.998337Z
0 likes, 0 repeats
@wowaname opal@ap.maladaptive.art oh, I get overly sentimental sometimes,and then I do stupid annoying text formatting :xD:sorry
(DIR) Post #APo3n8hQ19NYrNVbu4 by rozenglass@anime.website
2022-11-20T20:43:19.227300Z
0 likes, 0 repeats
@wowaname @opal and I mess up mentions