• 0 Posts
  • 25 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle

  • The idea is that the string of lights has a male end and a female end. That way you can have several daisy chained and just plug the one with the male end into the outlet. But if you plan it wrong then you may end up with the wrong end in the wrong place, in which case yeah, use an extension cord or hang the lights all over again.

    Oh and it’s actually relatively safe this way… Each string of lights normally has a fuse in it, so it prevents the cords from carrying more current than they are designed for.



  • That makes about as much sense as saying that pip, gem, npm, cargo, or nix should called be the default package manager on Mac OS…

    The default package manager is the default because it manages the system’s software. RPM, Deb/apt, pacman, etc. Homebrew is like pip or docker or cargo or snap or whatever else. You can set it up if you’d like but it’s certainly not a default. (Though I’m not trying to dispute that it’s good 😊)

    Mac OS doesn’t have a good default package management solution (though they would if they just opened up the app store and added a CLI). It’s ok to admit it, and say that third party folks (who Apple does not support unless I’m missing something) are powering a pretty good third party experience. If only Apple cared about people who wanted a truly free an customizable computer, they could make a great OS :)


  • The closest analogy is specific tech skills, like say DBs, for a small firm its just something one backend dude knows decently, at a large firm there are several DBAs and they help teams tackle complex DB questions. Same with say Search, first Solr and nowadays Elastic.

    Yeah I mean I guess we’re saying the same thing then :)

    I don’t think prompt engineering could be somebody’s only job, just a skill they bring to the job, like the examples you give. In those cases, they’d still need to be a good DBA, or whatever the specific role is. They’re a DBA who knows prompt engineering, etc.


  • I’m totally willing to accept “the world is changing and new skills are necessary” but at the same time, are a prompt engineer’s skills transferrable across subject domains?

    It feels to me like “prompt engineering” skills are just skills to compliment the expertise you already have. Like the skill of Google searching. Or learning to use a word processor. These are skills necessary in the world today, but almost nobody’s job is exclusively to Google, or use a word processor. In reality, you need to get something done with your tool, and you need to know shit about the domain you’re applying that tool to. You can be an excellent prompt engineer, and I guess an LLM will allow you to BS really well, but subject matter experts will see through the BS.

    I know I’m not really strongly disagreeing, but I’m just pushing back on the idea of prompt engineer as a job (without any other expertise).




  • Not a “hater” in terms of trying/wanting to be mean, but I do disagree. I think a lot of people downvoting are frustrated because this attitude takes an issue in one application (yay), for one distro, and says “this is why Linux sucks / can’t be used by normies”. Clearly that’s not true of this specific instance, especially given that yay is basically a developer tool. At best, “this is why yay sucks”. (yay is an AUR helper - a tool to help you compile and install software that’s completely unvetted - see the big red banner. Using the AUR is definitely one of those things that puts you well outside the realm of the “common person” already.)

    Maybe the more charitable interpretation is “these kinds of issues are what common users face”, and that’s a better argument (setting aside the fact that this specific instance isn’t really part of that group). I think most people agree that there are stumbling blocks, and they want things to be easier for new users. But doom-y language like this, without concrete steps or ideas, doesn’t feel particularly helpful. And it can be frustrating – thus the downvotes.


  • 100% monitoring and control doesn’t exist. Your children will find a loophole to access unrestricted internet, it’s what they do.

    Similarly, children will play in the street sometimes despite their parents’ best efforts to keep them in. (And yes, I would penalize Ford for building the trucks that have exploded in size and are more likely to kill children, but that’s a separate discussion.)

    I get what you’re saying, I just think it’s wrong to say “parental responsibility” and dust off your hands like you solved the problem. A parent cannot exert their influence 24/7, they cannot be protecting their child 24/7. And that means that we need to rely on society to establish safer norms, safer streets, etc, so that there’s a “soft landing” when kids inevitably rebel, or when the parent is in the shower for 15 minutes.







  • People aren’t misunderstanding the issue. Third party cookie support is being dropped by all browsers. Chrome is also dropping them, but replacing them with topics. Sure, topics is less invasive than third party cookies, but it is still more invasive than the obvious user friendly approach of not having an invasive tracker built into your browser. No other major browser vendor is considering supporting topics. So they’re doing an objectively user unfriendly thing here. This is the shit that happens when the world’s largest internet advertising company also controls the browser.





  • You might be even more concerned to find that your Fedora package manager, DNF, is also written in Python: https://github.com/rpm-software-management/dnf

    Fact of the matter is that Python is a language that gets used all the time for system level things, and frequently you just don’t know it because there is no “.py” extension.

    I’m not sure I understand your concerns about python…

    1. Performance is worse than C, yes. But writing performance sensitive code in Python is quite silly, it’s common to put that in a C library and use that within python to get the best of both worlds. DNF does this with libdnf.
    2. “It feels like an extension of proprietary hardware planned obsolescence and manipulation.” This is very confusing to me. There has been one historic version change (2->3) which broke compatibility in a major way, and this version change had a literal decade of help and resources and parallel development. The source code for every Python interpreter version is freely available to build and tweak if you’re unhappy with a particular version. Most python scripts are written and used for ages without any changes.
    3. “i don’t consider programs written in Python to have permanence or long term value because their toolchains become nearly impossible to track down from scratch.” Again, what? As I said, every Python version is available to download, build, and install, and tweak. It’s pretty much impossible for python code to every become unusable.

    Anyway, people like the Fedora folks working on anaconda choose a language that makes sense for their purpose. Python absolutely makes sense for this purpose compared to C. It allows for fast development and flexibility, and there’s not much in an installer program that needs high performance.

    That’s not to say C isn’t a very important language too. But it’s important to use the best tool for the job.