[-] varsock@programming.dev 1 points 2 years ago

when running models locally, I presume the models are trained and the weights and stuff are exported to a "model." For example Meta's LLama model.

Do these models get updated, new versions released? I don't quite understand

[-] varsock@programming.dev 1 points 2 years ago

wow 10 months flew by since this was posted and since then the United States had a surprise privacy bill that is bipartisan that sort of addresses the issues you and I mentioned. https://www.washingtonpost.com/technology/2024/04/07/congress-privacy-deal-cantwell-rodgers/

This bill was proposed around the same time the TikTok ban was announced. I speculate that law makers had a difficult time framing the arguments against TikTok when "the data of citizens have no protections so there was no easy legal grounds to forbit the likes of TikTok to harvest it"

From what I've heard, this bill is pretty good. I need to educate myself more on it, however.

[-] varsock@programming.dev 1 points 2 years ago

You can still buy a lifetime licenses of office but you have to buy it from 3rd party sellers and then validate the license with M$. Example Deal..

I bought 2 of them and also saved the install binary to have office suite.

I use libreoffice personally but I have family members that get frustrated when they cannot find the same formatting options

[-] varsock@programming.dev 1 points 2 years ago

I always thought about this. What about those with disabilities, like ADHD? Can companies really maintain their "equal opportunity employer" position while stripping privacy in the workplace? That's an over generalization for moving to an open office.

They will make a few exceptions then at some point say "that's enough" when all the employees need is less stimulation and more privacy

[-] varsock@programming.dev 1 points 2 years ago

cool thanks.

Well I'm glad to hear these things being worked on and worked out

[-] varsock@programming.dev 1 points 2 years ago* (last edited 2 years ago)

I agree that by design Flatpak aims to provide a secure environment through sandboxing; in practice, the implementation has gaps that can lead to security risks, particularly when apps are granted extensive filesystem access. This can undermine the effectiveness of the sandbox and potentially expose systems to vulnerabilities. HOWEVER, being on an immutable system, these risks are mitigated to some degree.

I'm particularly hopeful for Flatpak's promise of fine grained permissions. Flatpak is developing a fine-grained permission system with portals for external interactions, BUT this system relies on integration with toolkits like GTK, rather than app-specific APIs, complicating its implementation. There is more info in the linked article in the previous post, and here it is again.

Admittedly I'm not familiar with distrobox, but my caution is for any approach that distributes containerized programs with their own runtimes; they proved to be a real headache on my "mutable" system and my nvidia GPU until I switched to rolling OS.

I'm glad you found some candidates to potentially resolve your issue. What distro did you end up using? I'm curious to give it a go next chance I have some free time. Cheers.

[-] varsock@programming.dev 1 points 2 years ago* (last edited 2 years ago)

TL;DR: If I were to choose an immutable OS to run on my propriety graphics cards I'd choose an immutable distribution with rolling releases or hardware enablement packages, which tend to do a better job of keeping these graphics libraries up-to-date for new hardware.

I don't have a recommendation but I just learned about immutable Linux OSes from this post. I could see benefits of immutable OS files, but I've been skeptical about package distribution like flatpak and snap, at least in their current state.

Dont get me wrong, the workflow of flatpack is great, but in my experience, apps from flatpack typically ship with their own runtime and don't rely on system runtimes (likely why you have GPU driver issues). As a software developer, I obviously prefer to ship with all dependencies and runtimes so I don't have to rely on the system to be updated but this comes with downsides:

A major problem with alternate runtimes is drivers. New graphics hardware needs new graphics libraries which have a ton of dependencies. Mesa depends on LLVM for compiling shaders. The NVidia driver depends on a kernel module whose version must exactly match that of the library. All of these libraries have their own transitive dependencies like libdrm, libstdc++ and glibc. If you want new hardware to work, you need to be using new versions of all of these libraries.

Linux distributions, especially those with rolling releases or hardware enablement packages, do a great job of keeping these libraries up-to-date for new hardware. Bundled runtimes do not. Source.

I'd recommend checking out that article I linked as source. There are also security concerns of using apps, some of which are mitigated by having an immutable filesystem, but there are more points and this comment is long enough as it is.

EDIT: I reread my comment and it comes off as "immutable bad, blah blah". Truth is I don't know much about these OSes but I wanted to point out that distributing apps in containers comes with its own challenges; which I gather is necessary for immutable OSes. So my TL;DR is to narrow down to a distribution that is immutable and has a rolling release or distributes hardware enablement packages.

[-] varsock@programming.dev 1 points 3 years ago

set -- "${@[0,eoo]:/(#m)^-*/${MATCH:a}}" "${@[eoo+1,-1]:a}"

spoiler

The given script appears to be written in the Zsh shell syntax. Let's break it down step by step:

  1. set --: This command sets the positional parameters of the script. In Zsh, the -- option is used to signify the end of options and the beginning of positional parameters.

  2. "${@[0,eoo]:/(#m)^-*/${MATCH:a}}": This part refers to the expansion of the positional parameters, specifically targeting the elements from index 0 to the end of options offset (eoo). Here's what the individual components mean:

    • ${@[0,eoo]}: This refers to a sub-array of positional parameters from index 0 to eoo. It extracts the elements corresponding to command-line options.
    • /(#m)^-*: This is a pattern match within a substitution. It matches any occurrences of hyphens (-) at the beginning of each element. The (#m) flag enables multiline mode for pattern matching.
    • ${MATCH:a}: This is the replacement part of the substitution. It expands the matched pattern (${MATCH}) and applies the :a modifier, which removes leading hyphens from the matched string.

    In summary, this part removes leading hyphens from the command-line options.

  3. "${@[eoo+1,-1]:a}": This part refers to the expansion of the positional parameters, specifically targeting the elements from the end of options offset (eoo + 1) to the last element. Here's what the individual components mean:

    • ${@[eoo+1,-1]}: This refers to a sub-array of positional parameters from the end of options offset (eoo + 1) to the last element. It extracts the arguments that come after the command-line options.
    • :a: This applies the :a modifier, which removes leading hyphens from each element.

    In summary, this part removes leading hyphens from the command-line arguments that come after the options.

Overall, the script modifies the command-line options and arguments by removing leading hyphens. The modified values are then set as the new positional parameters using the set command. The exact purpose or context of the script can only be determined by understanding its broader context and usage.

[-] varsock@programming.dev 1 points 3 years ago

[ "${(Oa@)argv[1,-2]}" "${argv[-1]//(#m)[[]]/${(#)$((6 ^ #MATCH))}}" # this one is definitely not useful

spoiler

The given shell script appears to be written in the Zsh shell syntax. Let's break it down step by step:

  1. [ "${(Oa@)argv[1,-2]}" "${argv[-1]//(#m)[\[\]]/${(#)$((6 ^ #MATCH))}}" ]: This line encloses the entire script within square brackets [ ]. In Zsh, square brackets are commonly used for conditional expressions.

  2. "${(Oa@)argv[1,-2]}": This part refers to an expansion of the argv array, which typically holds command-line arguments passed to the script. Here's what the individual components mean:

    • ${(Oa@)}: This is a parameter expansion flag in Zsh that sorts the elements of the array in ascending order and expands each element as separate words. The @ symbol is used to indicate the array variable argv.
    • argv[1,-2]: This is array slicing syntax that extracts a sub-array of elements from index 1 to the second-to-last element (-2). It excludes the last element, which is assumed to be the final argument.

    In summary, this part expands and sorts the elements of the argv array, excluding the last argument.

  3. "${argv[-1]//(#m)[\[\]]/${(#)$((6 ^ #MATCH))}}": This part refers to another expansion of the argv array, specifically targeting the last element (argv[-1]). Here's what the individual components mean:

    • "${argv[-1]//pattern/replacement}": This is a parameter expansion that performs pattern substitution within the last element of the argv array.
    • (#m): This is an extended globbing flag in Zsh that enables multiline mode for pattern matching. It allows patterns to match across multiple lines.
    • [\[\]]: This is the pattern to match. It matches any occurrence of square brackets ([ or ]).
    • /${(#)$((6 ^ #MATCH))}}: This is the replacement part of the substitution. It calculates the bitwise XOR (^) of 6 and the matched pattern (#MATCH), and uses (()) to perform arithmetic expansion. The (#) flag is used to indicate that the result should be expanded.

    In summary, this part performs a substitution on the last element of the argv array, replacing any occurrence of square brackets with the result of a bitwise XOR operation between 6 and the matched pattern.

Overall, the script appears to process command-line arguments, sort and manipulate them, and then enclose the result in a conditional expression for further evaluation or use. The exact purpose or context of the script can only be determined by understanding its broader context and usage.

[-] varsock@programming.dev 1 points 3 years ago

print -rn $termcap[sc]${termcap[ch]//(%i|%p1|%d)}$termcap[ct]${(j::)s}$termcap[rc]

spoilerThe given shell script appears to be written in Zsh, a popular Unix shell. Let's break down the script step by step:

  1. print -rn: This command is used to print the output without a newline character (-n) and without interpreting any escape sequences (-r).

  2. $termcap[sc]: It refers to a termcap variable sc, which stands for "save cursor position." Termcap is a database and library used to control the behavior of terminals. $termcap[sc] saves the current cursor position.

  3. ${termcap[ch]//(\%i|\%p1|\%d)}: This part performs a substitution on the value of the termcap variable ch. The double slashes (//) indicate a global substitution, and the pattern (\%i|\%p1|\%d) matches any of the three percent sequences: %i, %p1, or %d. It replaces all occurrences of these sequences with an empty string.

  4. $termcap[ct]: It refers to the termcap variable ct, which stands for "clear to end of line." It clears everything from the cursor position to the end of the current line.

  5. ${(j::)s}: This uses parameter expansion to join the array variable s using colons (:) as separators. The (j::) flag indicates that colons should be used as separators.

  6. $termcap[rc]: It refers to the termcap variable rc, which stands for "restore cursor position." It restores the saved cursor position.

In summary, this shell script saves the cursor position, performs a substitution on the value of ch termcap variable, clears the current line from the cursor position to the end, prints the value of array variable s joined by colons, and finally restores the cursor position. The purpose and context of this script can only be determined based on the larger context or the values of the termcap variables sc, ch, ct, s, and rc.

[-] varsock@programming.dev 1 points 3 years ago

local d=("${(@s[/])${(%):-%~}}")

spoilerThe given shell script is written in the Zsh shell syntax. It initializes a local array variable d with the expansion of a string. Let's break it down step by step:

  1. local d=: This line declares a local variable d. The local keyword is used to define variables with local scope, meaning they are only accessible within the current scope, such as within a function or a block of code.

  2. "${(%):-%~}": This part of the script performs string expansion and substitution to populate the array d.

    • %~ is a special parameter expansion in Zsh that expands to the current working directory (tilde expansion).

    • (%): is another parameter expansion flag that performs splitting and globbing on the value obtained from %~. It splits the resulting string into separate elements based on the / delimiter and performs globbing (filename expansion) on each element.

      For example, if the current working directory is /path/to/some/directory, then %~ expands to /path/to/some/directory, and (%): splits it into individual components: path, to, some, and directory. If there are any glob patterns present, such as * or ?, they would be expanded as well.

  3. ("${(@s[/])${(%):-%~}}"): This part surrounds the expanded string with parentheses to create an array and stores it in the variable d. The (@s[/]) syntax is an array flag in Zsh that splits the resulting string into separate elements based on the / delimiter. Each element represents a directory component obtained from the %~ expansion.

In summary, this script initializes the local array variable d with the directories present in the current working directory's path. Each directory is stored as a separate element in the array d.

[-] varsock@programming.dev 1 points 3 years ago

i didnt know you paid for it 😯. thank you 🥹 if I was in the position to contribute I would. for now I'll just refrain from using to to drive up your costs

view more: ‹ prev next ›

varsock

0 post score
0 comment score
joined 3 years ago
MODERATOR OF