• 4 Posts
  • 27 Comments
Joined 9 months ago
Cake day: October 20th, 2023
  • BigBlackCockroach@lemmy.worldtoMemes@lemmy.ml•Don't be a no-poster
    202·
    8 months ago

    Maybe we could use AI to generate new and original content?

    Since that might produce too much content for anybody to read, upvote and engage with, we could cover the user side with AI bots as well.

    If we do this right we could completely automate social media. Maybe one day you won’t even have to look at your phone because an army of bots is doing it for you.

  • BigBlackCockroach@lemmy.worldOPtoMemes@lemmy.ml•Unix < GNULinux < GNUHurd
    231·
    8 months ago

    https://www.gnu.org/software/hurd/hurd/what_is_the_gnu_hurd.html

    The Hurd is the GNU project’s replacement for UNIX, a popular operating system kernel.

    The Hurd is firstly a collection of protocols formalizing how different components may interact. The protocols are designed to reduce the mutual trust requirements of the actors thereby permitting a more extensible system. These include interface definitions to manipulate files and directories and to resolve path names. This allows any process to implement a file system. The only requirement is that it have access to its backing store and that the principal that started it own the file system node to which it connects.

    The Hurd is also a set of servers that implement these protocols. They include file systems, network protocols and authentication. The servers run on top of the Mach microkernel and use Mach’s IPC mechanism to transfer information.

    The Hurd provides a compatibility layer such that compiling higher level programs is essentially transparent; that is, by means of the glibc, it provides the same standard interfaces known from other UNIX-like systems. Thus, for a typical user, the Hurd is intended to silently work in the background providing the services and infrastructure which the microkernel itself has no business implementing, but that are required for higher level programs and libraries to operate.

  • BigBlackCockroach@lemmy.worldtoAsklemmy@lemmy.ml•in your opinion, what is the biggest downside of Flatpaks?
    132·
    9 months ago

    I only use apt, or compile from source but here is what some guy online wrote:

    * Creates larger packages from compiling in most/all of the libraries used in development that use up more storage space because you are storing additional copies of libraries already on your system.

* Slower loading because you are loading a separate copy of libraries that may already be loaded and available for use.

* Updates to external libraries that add features, fix bugs, or change functionality are not available to the existing flatpak, which also reduces the testing use base for updates to support libraries.

* Breaks the fundamental concept of *NIX which is to separate out development of different subsystems, meaning that if an external system (library) changes how it does things, your program may no longer work or have features suddenly limited because it is using an older version of the library.

* Depends on the Application Binary Interface (ABI) remaining stable in the Linux kernel, which is preferred but not guaranteed. If an ABI is changed, the flatpak can stop working.

* Can be difficult to adapt to different distributions of Linux. Many Linux distributions have package maintainers that compile programs from source to ensure it works on and is compatible with the particular distribution they are supporting, and flatpaks can struggle to work on a different distribution.

* Sometimes avoids the work necessary to make the source generally compile-able across distributions. It's easier to compile a flatpak on the system it was developed on because all of the testing was done on one particular distribution. However, different distributions may have differences like the files in different locations, different software or libraries installed, different versions, different compilers, and without the program being compiled from source with all these differences, the codebase may never be updated to be take into account the differences in systems. The source code can be very stale, in a sense.

* Not a long-term solution. Flatpaks generally age out over time because they can't keep pace with distribution changes over time, as the open source environment is still very dynamic. Only source code that is legal to share is really sustainable over the long-term.

* Reduce use testing and reporting of bugs. Reported bugs usually get ironed out over time, as most program and package maintainers take pride in their work. With flatpaks, users don't get to test the program against updates to support libraries, so there are less user reports of bugs, and it can mean that bugs don't get identified as quickly or ever.

* Harder to identify bugs. Because flatpaks are monilithic binaries comprising both original and external work, it can be hard to figure out if a given bug is in the original program or supporting library, leading to mis-reporting of bugs, which adds effort to figure out the real source of the bug.