trevor

joined 2 years ago
[–] trevor@lemmy.blahaj.zone 2 points 13 hours ago (1 children)

That's not what any of that means. Your reading comprehension could use some work.

[–] trevor@lemmy.blahaj.zone 3 points 14 hours ago* (last edited 14 hours ago) (3 children)

You are really trying hard to contort things into things I didn't say.

The people problem is being ignored, and it wasn't until Linus was made aware of a technical justification for slapping Hellwig down that Linus focused his disapproval away from Marcan, who was rightly calling this out, to the person creating the problem.

And we lost at least three solid R4L devs, of which, Marcan was one, and there's zero acknowledgement from Linus that fixating on Marcan rightly calling this shit out was wrong.

The people problem of letting obstinate babies block valid code for any non-technical reason still has not been addressed, and this will keep happening until that changes.

[–] trevor@lemmy.blahaj.zone 3 points 14 hours ago* (last edited 14 hours ago)

I'm very firmly in the Rust for Linux camp because I am in the "make Linux better" camp, and I don't see why eventually getting Zig in the kernel would be a problem. If Zig solves problems that C and Rust don't, by all means, it should be brought in.

However, one of the primary reasons Rust was chosen is that it is memory-safe by default. Zig, on the other hand, has opt-in safety. So unsafe Zig should probably only go in very specific places where C and Rust can't do the job. And ideally, there would be some rules that require the usage of safe Zig everywhere else.

Ignoring Zig, the language, Zig's compiler toolchain is hands-down, the best I've ever seen, and I think introducing Zig to the kernel by making "Zig-built Linux" a thing, would be a really natural way to get that process going.

[–] trevor@lemmy.blahaj.zone 3 points 15 hours ago (5 children)

Nothing speculative about it. The substance of the problem (obstinate, crotchety baby that was blocking useful code) was ignored and Linus instead chose to wrongly focus on Marcan calling out the problem. There's nothing wrong with people calling out toxic bullshit, and it seemed that social media was necessary for that in this case, yeah.

[–] trevor@lemmy.blahaj.zone 12 points 1 day ago* (last edited 1 day ago) (11 children)

Exactly. Airing-out Hellwig's successful attempt to sabotage Rust efforts (and it was successful, given that at least two important maintainers have already resigned) was good, actually.

Unfortunately, it seems that Linus doesn't have the maturity to recognize that, and this cycle is likely to continue, barring something good and unforeseen happening.

[–] trevor@lemmy.blahaj.zone 30 points 1 day ago* (last edited 1 day ago) (2 children)

I just cant wrap my head around why they're willing to go so far to gain good will from people by having such a generous free tier, but somehow licensing the code under a FOSS license is out of the question??

Why not just go all the way and make sure everyone who cares about reading the souce could also give you free contributions?

[–] trevor@lemmy.blahaj.zone 1 points 3 days ago (1 children)

Well, hopefully the get on that. They have to realize that a large portion of their target demographic (people fed up with garbage search) also rightly don't want their search histories tied to their real identities.

[–] trevor@lemmy.blahaj.zone 2 points 4 days ago

Yes, because private property is theft. But unequal enforcement of copyright law is worse. Right now, LLMs are just lying machines trained on pirated data and the companies that run them are acting with impunity for doing something a normal person would get put in jail for.

Copyright is immoral, but as long as it exists, the laws should be extra strict on companies that steal others' works.

[–] trevor@lemmy.blahaj.zone 1 points 4 days ago (3 children)

What does this actually do? Is it possible to use Kagi without providing them personal information to create your account yet?

[–] trevor@lemmy.blahaj.zone 9 points 6 days ago

I don't disagree with most of that, but none of what you said actually addresses the problem. The problem is that there are functionally two (notable) flatpak repositories, but one of those is going against the will of the upstream software devs and shipping broken software that they have asked them to stop packaging. And Fedora users are getting the broken flathub repository as the default, without really having reason to suspect that their "flathub store" would ever trick them into installing from a different source. The "verified" badge, especially the lack thereof, does not address that.

As for users feeling “tricked”? That’s a difficult thing to say. I would like to say that users should at least know something about the distro they are choosing (ie Ubuntu users should know about snap; Fedora/Debian users should know about their stances on FOSS, security, and patents; Arch users should know its a DIY distro).

You can RTFM someone all day, but if you actually want Linux to be adopted by more people, you need to reduce the anti-patterns. Snaps are generally known about because they are infamous for also breaking packages. And they're still major footguns when people are recommending Ubuntu to people that are new to Linux, who are the least likely to know that their apt package installations are going to be installing differently-packaged software that has its own set of problems. If we get to a point where Flatpaks have a similar problem to Snaps, we've taken a wrong turn, and it will only hurt Linux adoption.

[–] trevor@lemmy.blahaj.zone 9 points 6 days ago* (last edited 6 days ago)

The OBS and Bottles packages have been broken for a long time. Long enough that both upstream projects asked them to stop many months ago. They don't get to pretend it was a mistake. This isn't just another case of a minor packaging bug getting to users. They are packaging the software incorrectly.

[–] trevor@lemmy.blahaj.zone 11 points 6 days ago (3 children)

I answered most of this in the other thread, but I am aware that anyone can make flatpaks. What I meant is that flatpaks were supposed to make it easier for devs to get their software to end users by allowing them to not have to worry about distro-specific packaging requirements or formats.

But when someone else takes it upon themselves to make broken flatpaks, ones that you've requested they stop doing, now they're making things worse for everyone involved and should be considered a hostile fork and treated as such.

 

I am looking for something that can take a Dockerfile, like the following as an input:


FROM --platform=linux/amd64 debian:latest
ENV DEBIAN_FRONTEND=noninteractive

RUN apt update && apt install -y curl unzip libsecret-1-0 jq
COPY entrypoint.sh .
ENTRYPOINT [ "/entrypoint.sh" ]

And produce a a multi-stage Dockerfile where the last stage is built from scratch, with the dependencies for the script in the ENTRYPOINT (or CMD) copied over, like this:


FROM --platform=linux/amd64 debian:latest as builder
ENV DEBIAN_FRONTEND=noninteractive

RUN apt update && apt install -y curl unzip libsecret-1-0 jq

FROM --platform=linux/amd64 scratch as app
SHELL ["/bin/bash"]

# the binaries executed in entrypoint.sh
COPY --from=builder /bin/bash /bin/bash
COPY --from=builder /usr/bin/curl /usr/bin/curl
COPY --from=builder /usr/bin/jq /usr/bin/jq
COPY --from=builder /usr/bin/sleep /usr/bin/sleep

# shared libraries of the binaries
COPY --from=builder /lib/x86_64-linux-gnu/libjq.so.1 /lib/x86_64-linux-gnu/libjq.so.1
COPY --from=builder /lib/x86_64-linux-gnu/libcurl.so.4 /lib/x86_64-linux-gnu/libcurl.so.4
COPY --from=builder /lib/x86_64-linux-gnu/libz.so.1 /lib/x86_64-linux-gnu/libz.so.1
# ...a bunch of other shared libs...

# entrypoint
COPY entrypoint.sh /entrypoint.sh

ENTRYPOINT [ "/entrypoint.sh" ]

I've had pretty decent success creating images like this manually (using ldd to find the dependencies) based on this blog. To my knowledge, there's nothing out there that automates producing an image built from scratch, specifically. If something like this doesn't exist, I'm willing to build it myself.

view more: next ›