• 0 Posts
  • 91 Comments
Joined 1 year ago
cake
Cake day: April 3rd, 2024

help-circle

  • AI isn’t taking off because it took off in the 60s. Heck, they were even working on neural nets back then. Same as in the 90s when they actually got them to be useful in a production environment.

    We got a deep learning craze in the 2010s and then bolted that onto neural nets to get the current wave of “transformers/diffusion models will solve all problems”. They’re really just today’s LISP machines; expected to take over everything but unlikely to actually succeed.

    Notably, deep learning assumes that better results come from a bigger dataset but we already trained our existing models on the sum total of all of humanity’s writings. In fact, current training is hampered by the fact that a substantial amount of all new content is already AI-generated.

    Despite how much the current approach is hyped by the tech companies, I can’t see it delivering further substantial improvements by just throwing more data (which doesn’t exist) or processing power at the problem.

    We need a systemically different approach and while it seems like there’s all the money in the world to fund the necessary research, the same seemed true in the 50s, the 60s, the 80s, the 90s, the 10s… In the end, a new AI winter will come as people realize that the current approach won’t live up to their unrealistic expectations. Ten to fifteen years later some new approach will come out of underfunded basic research.

    And it’s all just a little bit of history repeating.




  • Of course you wouldn’t use an existing database engine as the foundation of a new database engine. But you would use an existing database engine as the foundation of an ERP software, which is a vastly different use case even if the software does spend a lot of time dealing with data.

    If I want to build an application I don’t want to reimplement everything. That’s what middleware is for. The use case of my application is most likely not to speak a certain protocol; the protocol is just the means to what I actually want to do. There’s no reason for me to roll my own implementation from scratch and keep up with current developments except if I’m unhappy with all current implementations of that protocol.

    Of course one can overdo it with middleware (the JS world is rife with this) but implementing a communication protocol is one of the classic cases where it makes sense.








  • A mITX or µATX case with 4+ 3.5" bays and a little flip-up display would be excellent for a home server.

    The display could be the cheapest TN junk they can find as long as it works – you rarely need it and when you do you care about seeing the recovery terminal and not about visual fidelity.

    Alternatively, a little combination screen/keyboard world also work for me. A little clamshell device the size of a Nintendo DS that attaches via HDMI and USB for maximum compatibility. When it’s not needed I can just stash it next to the server and it won’t take up a lot of space.

    Maybe I’d try building something like that but I have no idea where even to find a keyboard for it. It’d probably have to be a custom job.






  • Mind you, enemies of encryption have claimed that backdoors or encryption bans would’ve prevented attacks where it’s known that the perpetrators have been communicating with bog-standard unencrypted email and text messages. Most of the time there problem is not encryption but insufficient collaboration between agencies.

    Often enough, going for encryption is an abstract power grab wrapped in security theater. Plus, “we need to been encryption” or its modern counterpart “the police need a universal backdoor key” are simple solutions to complex problems, which is a common approach for scoring with voters who have no idea what’s going on.

    Encryption is simply on the list of acceptable targets.