• 0 Posts
  • 25 Comments
Joined 7 months ago
cake
Cake day: January 27th, 2025

help-circle
  • It’s actually not that hard. Most of these bots are using a predictable scheme of headless browsers with no js or minimal js rendering to scrape the web page. Fully deployed browser instances are demonstrably harder to scale and basically impossible to detect without behavioral pattern detection or sophisticated captchas that also cause friction to users.

    The problem with bots has never rested solely on detectability. It’s about:

    A. How much you inconvenience the user to detect them

    B. Impacting good or acceptable bots like archival, curl, custom search tools, and loads of other totally benign use cases.


  • It certainly is not negligble compared to static site delivery which can breezily be cached compared to on-the-fly tarpits. Even traditional static sites are getting their asses kicked sometimes by these bots. And yoy want to make that worse by having the server generate text with markov chains for each request? The point for most is reducing the sheer bandwidth and cpu cycles being eating up by these bots hitting every endpoint.

    Many of these bots are designed to stop hitting endpoints when they return codes that signal they’ve flattened it.

    Tarpits only make sense from the perspective of someone trying to cause monetary harm to an otherwise uncaring VC funded mob with nigh endless amounts of cache to burn. Chances are your middling attempt at causing them friction isn’t going to, alone, actually get them to leave you.

    Meanwhile you burn significant amounts of resources and traffic is still stalled for normal users. This is not the kind of method a server operator actually wanting a dependable service is deploying to try to get up and running gain. You want the bots to hit nothing even slightly expensive (read: preferably something minimal you can cache or mostly cache) and to never come back.

    A compromise between these two things is what Anubis is doing. It inflicts maximum pain (on those attempting to bypass it - otheriwse it just fails) for minimal cost by creating a small seed (more trivial than even a markov chain – it’s literally just an sha256) that a client then has to solve a challenge based on. It’s nice, but certainly not my preference: I like go-away because it leverages browser apis these headless agents dont use (and subsequnetly let’s js-less browsers work) in this kind of field of problems. Then, if you have a record of known misbehavers (their ip ranges, etc), or some other scheme to keeo track of failed challeneges, you hit them with fake server down errors.

    Markov chains and slow loading sites are costing you material just to cost them more material.



  • I dont think this is a reasomable counterpoint because the target audience in question would also vastly prefer shit as simple as an mspaint illustration or a dithered irl image.

    Also, it is quite feasible to find royalty free images, and I have no idea where you’re getting the impression it is not. There are a host of images that provide licensing metadata. Google image search and co. can find these. It’s simply a matter of verifying the license authenticity.

    It’s just fundementally stupid.



  • It is self-evident that free software with open licensing and no strings attached is a superior and more beneficial ownership model than closed source paid licensing. That part I don’t think anyone needs to be convinced of.

    As someone who has both technical and nontechnical people in their family, I call bs. Even if it is partially self-evident (in the fact that you dont need to sign into an account or pay for it), the details, and more importantly the weight, of FOSS is often lost on people.

    I’ve had to watch some of them walk into a rake and bruise their foreheads several times over before really absorbing it.

    It’s something people need to really read up on before true comprehension. That, or get burnt really really badly.

    Ideology? Politics? Tomato tomatoh in my eyes. At the very least, they’re nearly inseperable (think: DMCA, copyright law, etc.)


  • Go is a simpler-to-read language that does not involve lifetimes (as you know, it is GC’d). For a lot of smaller projects like this, the boringness of Go is preferred. Less mental bandwidth required.

    I’ll admit my definition of “industrial” here was vague, but I think you can get my point. I’m not trying to say that Rust isn’t good in a business setting - my job also has Rust in the code!

    However, for these purposes, most of the benefits of Rust in this situation are already provided by Go.


  • On the one hand, I love Rust, love seeing Rust winning, on the other hand: the cynical part of me observes this as a way for them to say it’s safer to use, somehow. In the sense that people fling Rust around in a kind of showey way.

    Already we’ve been seeing projects fuck up with isolation irt MCP servers, so this is the backdrop to observe this kind of change.

    I know this is blasphemy, but why not Go? Why Rust? I love writing Rust CLIs, but somehow I feel the personal arguments I make for such things don’t really hold up in industrial settings like this (in particular, a small open-source CLI project that interacts with networking).

    There’s nothing wrong with using Rust here (Rust is great for business logic!), but the choice here almost makes me suspicious of the motivations.

    Also there’s existing Rust solutions in this area! Namely: https://github.com/sigoden/aichat

    I don’t really enjoy using AI when coding, but aspirationally, I’d rather support other projects than OpenAI, who is only a nonprofit in concept and is actively attempting to become a for-profit, whilst behaving like a VC funded startup.

    (Not to mention the fact that mainline models are explicitly developed with the intention of destroying labor, in general)



  • I was merely pointing out that these opinions, whatever they really are, have more publicity from people criticizing the founder.

    Why yes, friend, I will just conveniently pretend that you bringing that up is completely outside the context of whether or not to seriously consider the criticism.

    And if you are trying to make a point of whether or not the ideology is seriously impacting the project, you need-only take a casual walk through the issue list, and find (among other evidence) that a suggestion to move to codeberg was criticized for… “DEI”. Wow. How technically-focused.

    The best from your point of view would be not to speak about it.

    You are getting more and more incoherent the more of these replies you churn out. What, precisely from my point of view (which I guess apparently you know very well? the irony…) here implies that “not talking about it” is the best choice? That’s absurd.

    I find it very important to understand the motivations, technical and ideological, behind a project.

    If it were true, all this hatred against the project would be pointless.

    I don’t spend any effort talking about in any other respect than telling people that they should likely disregard if for both technical reasons (it cuts out Xwayland, his commits frequently lead to very blatant regressions that are nontrivial, etc.) and ideological (his terrible, awful politics and motivations for making the project, to begin with!)

    The reason I replied to your comment is mostly out of idle curiosity and a deepseated longing for genuineness and critical thinking of other people that I have not yet managed to kill (despite its impracticality in the modern age).

    Free software is all about freedom, and diversity means freedom of choice. If you don’t agree with that, you miss the all point.

    This is all such a massive and disheartening reduction of what software freedom is. I hope that you eventually manage to think less shallowly about this.

    Tell me, do you have any particular, material distinction you are making by making a choice between desktop protocols? The desktop protocol is a purely technical thing, and I have not heard a single peep out of you in regards to specifics.

    To elaborate, in Xorg, it is a very monolithic beast. It is very convoluted in its purview and carries a lot of preset implementation of its various facets. It contains an entire networking stack for deciding how to communicate windows over a network.

    It is significantly less flexible and modular than Wayland, because in Wayland basically everything of significance is decided by the compositor.

    This, ironically to your point, actually gives you more choice and freedom in how things work (this is also why tiling window managers love wayland to death, it’s pretty easy to just build upon the basic wlroots implementation!). So I have to ask you, frankly, what in the fuck do you think you’re actually saying right now?

    The issue, in this way, is that you only seem to care about software freedom in the sense of the abstract concept rather than the reality. You seem to think of software freedom in the sense of “I either build and install this package, or I build and install this one”, with an all-consuming disregard for the technical aspects of freedom. Which is impractical, and arguably antithetical to the very process of trying to foster software freedom to begin with. As evident by literally everything to do with this situation. My lord.



  • solardirus@slrpnk.nettoLinux@lemmy.mlLinux and Foss Signal Group Chat
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    2 months ago

    I really have no idea why everyone is bashing Signal so much here. None of the concerns listed seem even slightly technical.

    The only problem I have with signal is that it is:

    A. Centralized (which isn’t explicitly a privacy concern, but a control concern in-line with linux and foss)

    B. Requires a phone number to register.

    It is quite private in spite of that, and goes to great lengths to achieve that privacy. It is what I see people in the security community consistently suggest.

    However, if this is a public group, are we to really be that concerned about many of the considerations Signal tries to tackle? Worst case scenario a bad actor simply enters the chat and backs everything up.

    It seems like our threat model is moreso in the way of general surveillance economy concerns (and perhaps to have a slightly less public entry).

    In this case, point A and B become even more glaring! Why not something like an E2E encrypted Matrix chat?



  • solardirus@slrpnk.nettoLinux@lemmy.mlXlibre 25.0 : summer solstice release
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    edit-2
    2 months ago

    This isn’t coherent, and even if it was, the burden of stance interpretability is context-dependent.

    He is the one with the politically charged README that reads plainly like the thoughtless garbage MAGA types in America put out. I mean cmon man, “[…] we’ll make X great again”?

    Also your shallow and brainless dismissal of all this criticism coming from his “detractors” (and who would not become a “detractor”, after actually investigating his terrible dribble?) is defeated easily by just reading the actual words he said.

    As in, for instance, the original source of his garbage antivax posturing that he posted in the linux kernel mailing list: https://lkml.iu.edu/hypermail/linux/kernel/2106.1/04542.html .

    These are not alleged opinions, he’s just full of shit.

    And this isn’t even mentioning the fact that Xorg is going to be dead, should be dead, and will continue to die. And good riddance, too! Terrible and borderline unmaintainable.

    The argument that choice diversity is good inherently is stupid, too. Wayland is a god damned protocol! There is no reason to have lots of diversity there! It has no tangible benefit.

    There are already many different compositors that implement the Wayland protocol, and there are also many 3rd party extensions! Can you think of a single, material benefit to simply having different basic desktop protocols?







  • Energy and water costs for developmenr and usage alone are completely incompatible with that. Come back in 20 years when it’s not batshit insane ecologically.

    Not to mention reducing power usage of programs isnt going to be very feasible based on simply an LLM’s output. LLMs are biased twoards common coding patterns and those are demonstrably inefficient (if the scourge of web apps based on electron is any tell). Thusly your code wouldn’t work well with lower grade hardware. Hard sell.

    Theoritically they could be an efficient method of helping build software in the future. As it is now that’s a pipe dream.

    More importantly, why is the crux of your focus on not understanding the code you’re making. It’s intrinsically contrived from the perspective of a solarpunk future where applications are designed to help people efficiently - without much power, heat, etc… weird man