• 1 Post
  • 72 Comments
Joined 2 years ago
cake
Cake day: July 4th, 2023

help-circle
  • Uneducated 2 cents. afaik the publishers have some kind of “part ownership”, where they can pull it out from the store whenever. The “anti-piracy” feature you get with DRMs is why many publishers actually like them tho. The part ownership thing is just icing on the cake. So no, a good chunk of publishers won’t be furious at all. DRM gives what publishers want and more, at the expense of the consumers in a way that most wouldn’t realize.

    And if anything, I think it makes more sense to think that these publishers are also just granting Amazon some kind of “license” to sell their e-books.

    Amazon would absolutely be destroying their relationship with a publisher though, if they decide to block the selling or access of a book to large group of people who are would-be buyers. But, at the end of the day, publishers want to know how much they’re making from putting their e-books on Amazon, and as long as that revenue is enough to satisfy their needs, they don’t need to care too much about the odd customer who had their book revoked, and they would generally be pretty shielded from any sort of disputes as long as Amazon is making those revoking calls.





  • You come from a healthy background is what I’m hearing. And that’s good, and I don’t mean that in a derogatory way. What you have there is absolutely the right mindset to have. These tools are made by humans, who have their own set of problems they want to solve with their tools. It may not be the best tool, but it can work pretty damn well.

    However, it’s also not uncommon to see communities rage and fight over the superiority of their tools, if not just to shun those that they think are inferior. It’s a blatantly childish or tribalistic behaviour, depending on how you look at humanity. And you’ll see this outside of programming too; in the office, in town, on the streets. People engage in this behaviour so that they can show that “I am on your side”, for the side where they think is the right or superior side, based on factors like a perception of group size, a perception of power, a perception of closeness. It appeals to a common human desire to belong to a strong group. It appeals to the human desire to feel safe. And when you start looking at it that way, that’s not too different from how animals behave. It’s important to note that not all humans have the same amount of desire for this sort of tribe, or would give into that desire to engage in such behaviours, but it’s not surprising to see.

    In any case, this article is essentially a callout to the sort of toxic behaviour done for the sake of feeling superior, that exists within the programming community, to a point where some may even say is a major subculture.


  • This. Any time someone’s tries to tell me that AGI will come in the next 5 years given what we’ve seen, I roll my eyes. I don’t see a pathway where LLMs become what’s needed for AGI. It may be a part of it, but it would be non-critical at best. If you can’t reduce hallucinations down to being virtually indistinguishable from misunderstanding a sentence due to vagueness, it’s useless for AGI.

    Our distance from true AGI (not some goalpost moved by corporate interests) has not significantly moved from before LLMs became a thing, in my very harsh opinion, bar the knowledge and research being done by those who are actually working towards AGI. Just like how we’ve always thought AI would come one day, maybe soon, before 2020, it’s no different now. LLMs alone barely closes that gap. It gives us that illusion at best.







  • You’re speaking prophetically there and I simply do not agree with that prophecy.

    If you and your team think you need to extend that bash script to do more, stop and consider writing it in some other languages. You’ve move the goalpost, so don’t expect that you can just build on your previous strategy and that it’ll work.

    If your “problem” stems from “well your colleagues will not likely be able to read or write bash well enough”, well then just don’t write it in bash.


  • I’m going to downvote your comment based on that first quote reply, because I think that’s an extreme take that’s unwarranted. You’ve essentially dissed people who use it for CI/CD and suggested that their pipeline is not robust because of their choice of using Bash at all.

    And judging by your second comment, I can see that you have very strong opinions against bash for reasons that I don’t find convincing, other than what seems to me like irrational hatred from being rather uninformed. It’s fine being uninformed, but I suggest you tame your opinions and expectations with that.

    About shared libraries, many popular languages, Python being a pretty good example, do rely on these to get performance that would be really hard to get from their own interpreters / compilers, or if re-implementing it in the language would be pretty pointless given the existence of a shared library, which would be much better scrutinized, is audited, and is battle-tested. libcrypto is one example. Pandas depends on NumPy, which depends on, I believe, libblas and liblapack, both written in C, and I think one if not both of these offer a cli to get answers as well. libssh is depended upon by many programming languages with an ssh library (though there are also people who choose to implement their own libssh in their language of choice). Any vulnerabilities found in these shared libraries would affect all libraries that depend on them, regardless of the programming language you use.

    If production only implies systems in a user’s path and not anything else about production data, then sure, my example is not production. That said though, I wouldn’t use bash for anything that’s in a user’s path. Those need to stay around, possible change frequently, and not go down. Bash is not your language for that and that’s fine. You’re attacking a strawman that you’ve constructed here though.

    If your temporary small script morphs into a monster and you’re still using bash, bash isn’t at fault. You and your team are. You’ve all failed to anticipate that change and misunderstood the “temporary” nature of your script, and allowed your “temporary thing” to become permanent. That’s a management issue, not a language choice. You’ve moved that goalpost and failed to change your strategy to hit that goal.

    You could use Deno, but then my point stands. You have to write a function to handle the case where an env var isn’t provided, that’s boilerplate. You have to get a library for, say, accessing contents in Azure or AWS, set that up, figure out how that api works, etc, while you could already do that with the awscli and probably already did it to check if you could get what you want. What’s the syntax for mkdir? What’s it for mkdir -p? What about other options? If you already use the terminal frequently, some of these are your basic bread and butter and you know them probably by heart. Unless you start doing that with Deno, you won’t reach the level of familiarity you can get with the shell (whichever shell you use ofc).

    And many argue against bash with regards to error handling. You don’t always need something that proper language has. You don’t always need to handle every possible error state differently, assuming you have multiple. Did it fail? Can you tolerate that failure? Yup? Good. No? Can you do something else to get what you want or make it tolerable? Yes? Good. No? Maybe you don’t want to use bash then.


  • But not everything needs to scale, at least, if you don’t buy into the doctrine that everything has to be designed and written to live forever. If robust, scalable solutions is the nature of your work and there’s nothing else that can exist, then yeah, Bash likely have no place in that world. If you need any kind of handling more complicated than just getting an error and doing something else, then Bash is not it.

    Just because Bash isn’t designed for something you want to do, doesn’t mean it sucks. It’s just not the right tool. Just because you don’t practice law, doesn’t mean you suck; you just don’t do law. You can say that you suck at law though.


  • People have really been singing praises of Powershell huh. I should give that a try some time.

    But yeah, we wield tools that each come with their own risks and caveats, and none of them are perfect for everything, but some are easier (including writing it and addressing fallovers for it) to use in certain situations than others.

    It’s just hard to tell if people’s fear/disdain/disgust/insert-negative-reaction towards bash is rational or more… tribal, and why I decided to ask. It’s hard to shake away the feeling of “this shouldn’t just be me, right?”


  • Seems like something that can happen in any languages, though yeah, bash doesn’t make it easier, and it’ll depend on what the cli tool would return given the error (eg does it return some code in stdout or stderr, or some non-zero exit code). Depending on the library (in the language of choice), you may still have to handle such errors manually, eg adding the necessary logic to retry.

    And in such a case, I guess it would be prudent to either make sure that the data can be retrieved again, or push it somewhere a bit more permanent (shared fs, or object storage), sort of in a dead-letter-esque style. Seems like the lesson here is to have a fall over plan. The failure mode is not something a proper language and library would necessarily help discover more easily though.



  • There are times when doing so does make sense, eg if you need the script to be portable. Of course, it’s the least of your worries in that scenario. Not all systems have bash being accessible at /bin like you said, and some would much prefer that you use the first bash that appears in their PATH, e.g. in nix.

    But yeah, it’s generally pretty safe to assume /bin/sh will give you a shell. But there are, apparently, distributions that symlink that to bash, and I’ve even heard of it being symlinked to dash.



  • I honestly don’t care about being right or wrong. Our trade focuses on what works and what doesn’t and what can make things work reliably as we maintain them, if we even need to maintain them. I’m not proposing for bash to replace our web servers. And I certainly am not proposing that we can abandon robustness. What I am suggesting that we think about here, is that when you do not really need that robustness, for something that may perhaps live in your production system outside of user paths, perhaps something that you, your team, and the stakeholders of the particular project understand that the solution is temporary in nature, why would Bash not be sufficient?

    I suspect you just haven’t used Bash enough to hit some of the many many footguns.

    Wrong assumption. I’ve been writing Bash for 5-6 years now.

    Maybe it’s the way I’ve been structuring my code, or the problems I’ve been solving with it, in the last few years after using shellcheck and bash-language-server that I’ve not ran into issues where I get fucked over by quotes.

    But I can assure you that I know when to dip and just use a “proper programming language” while thinking that Bash wouldn’t cut it. You seem to have an image of me just being a “bash glorifier”, and I’m not sure if it’ll convince you (and I would encourage you to read my other replies if you aren’t), but I certainly don’t think bash should be used for everything.

    No. If it’s missing $1 will silently become an empty string. os.args[1] will throw an error. Much more robust.

    You’ll probably hate this, but you can use set -u to catch unassigned variables. You should also use fallbacks wherever sensible.

    Absolutely not. Python is strongly typed, and even statically typed if you want. Light years ahead of Bash’s mess. Quoting is pretty easy to get right in Python.

    Not a good argument imo. It eliminates a good class of problems sure. But you can’t eliminate their dependence on shared libraries that many commands also use, and that’s what my point was about.

    And I’m sure you can find a whole dictionary’s worth of cases where people shoot themselves in the foot with bash. I don’t deny that’s the case. Bash is not a good language where the programmer is guarded from shooting themselves in the foot as much as possible. The guardrails are loose, and it’s the script writer’s job to guard themselves against it. Is that good for an enterprise scenario, where you may either blow something up, drop a database table, lead to the lost of lives or jobs, etc? Absolutely not. Just want to copy some files around and maybe send it to an internal chat for regular reporting? I don’t see why not.

    Bash is not your hammer to hit every possible nail out there. That’s not what I’m proposing at all.