Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Package Manager

antonz.org

Post reply on HN
Print view View original

101–106 of 106 posts

Re: Writing a Package Manager

#101

Post by nextaccountic »

seabass-labrax wrote: post #89
nextaccountic wrote: post #10

Earlier quoted context omitted.

> Apple already uses something like this today Some Linux distros too have things like this but unfortunately there is no buy-in across the ecosystem so "sandboxing" is done in a half-baked way. The problem is when applications in general aren't written with sandboxing in mind, and when you have to choose between apps not working properly or having a leaky sandbox, you will opt for the latter. I wish some big corp bi…

You're describing Red Hat! After spending multiple years helping with the development of Flatpak, which is a sandboxed environment with file pickers just like you describe, they recently announced[1] that they would no longer be contributing to LibreOffice in Fedora and instead will be contributing to a Flatpak version instead. Personally, I am not so sure about Flathub (the 'official' repository for Flatpak bundles)…

That's interesting. So is Flatpak actually secure against malicious code? That is, would you trust running malware if it's packaged as Flatpak?

I'm saying this because we're talking through a platform that is trusted by the majority of pepple to run malware - the web browser. We don't manually check if the Javascript or Wasm code is good or bad before we visit a web page. Few people disable scripts altogether. We could have this level of trust in applications running on our system - but does Flatpak deliver it?

Re: Writing a Package Manager

#102

Post by salawat »

pxc wrote: post #97
salawat wrote: post #95

Earlier quoted context omitted.

...Why not use Jitsi? I'm also in the process of whipping through getting prosody (a subcomponent on which jitsi is built) set up in such a way as to also be able to handle most of what people would use Slack or Discord for. The primitives for much of the modern corpo-ware environments have been available for a while. The best part is that those you build from scratch don't even require extra firewall config to nuke…

Jitsi meet is a pretty easy one to convince others to use, since it works in the browser and requires no accounts. For the others, it can be more work. Either way, the reality is that many people install those untrustworthy proprietary apps insecurely today, using vendor-provided DEBs that have a history of huge misbehavior and serious security vulnerabilities.

Won't argue with you there, but I've gotten tired of turning into the old man shouting "If you have not read what you are preparing to deploy at least once, you don't know what it does! You are not engineering! You're doing a ritual!" at the clouds.

Re: Writing a Package Manager

#103

Post by Eddygandr »

notatallshaw wrote: post #85
Eddygandr wrote: post #39

Bit of a tangent here but what’s a pip/npm/cargo like package manager for C++? For example ‘pip install boost’? I’ve never worked it out for hobby projects and never worked with it commercially

FYI pip is specifically not a package manager, it's a package installer. Pip does not attempt to resolve dependency conflicts of already installed packages, only the ones it is currently trying to install. Nor does it try to manage the life cycle of installed packages, such as removing transitive dependencies never specified or no longer needed or create consistent environments with a lock file. As package specificat…

Thanks for the info! That would explain why I spend so much time fighting dependency errors when I upgrade something ML related ...

Re: Writing a Package Manager

#104

Post by pxc »

salawat wrote: post #102
pxc wrote: post #97

Earlier quoted context omitted.

Jitsi meet is a pretty easy one to convince others to use, since it works in the browser and requires no accounts. For the others, it can be more work. Either way, the reality is that many people install those untrustworthy proprietary apps insecurely today, using vendor-provided DEBs that have a history of huge misbehavior and serious security vulnerabilities.

Won't argue with you there, but I've gotten tired of turning into the old man shouting "If you have not read what you are preparing to deploy at least once, you don't know what it does! You are not engineering! You're doing a ritual!" at the clouds.

That resonates deeply with me— even though, of course, I run lots of software I have not read.

Trying to understand what's going on in a computer or a network can be overwhelming. I understand the need to simplify, to take for granted, to abstract away— to ritualize, even.

But sometimes I do feel frustrated that engineers (whether in application development or infrastructure or networking, whatever) can be frustratingly uncurious about the tools they're using. 'How it works' should never mean 'how to operate it', but a lot of people use those terms interchangeably, even within tech.

For me, though, using F/OSS isn't about reading code. It's about feelings and values like trust, respect, control, and peace. When you manage to avoid proprietary software entirely, you can recover those things in your computing life in a way that is totally opposite to the adversarial relationships most people have with the software they run today. It's easy to 'not know what you're missing', especially because you don't really get it from just using a few pieces of F/OSS on a proprietary platform.

But the real reason to use F/OSS is to take refuge and let go of that tension of the posture you have to take with software whose authors don't have your interests at heart, that alertness and readiness to swat away nags, to dodge traps, to dig up the checkboxes and registry hacks and configuration files you need to disable an endless onslaught of individually small but nonetheless malicious behaviors.

Imo, that makes it worth it to try to convince a few of your friends to explore Jitsi or Matrix or Revolt with you instead of trying to make room for whatever proprietary social media apps are trendy right now, even if you have never read a line of code in your life.

Re: Writing a Package Manager

#105

Post by kdeldycke »

mijoharas wrote: post #21

It's surprisingly to me that no-one has built a asdf style package manager. (I'm not talking about system package managers, their language software packages are always out of date and get installed globally instead of locally to a project). Having a unified interface to a package manager per language that will use the languages registry could be really nice (I guess you'd have some core dependency management function…

Something like Meta Package Manager? https://github.com/kdeldycke/meta-package-manager

Re: Writing a Package Manager

#106

Post by seabass-labrax »

nextaccountic wrote: post #101
seabass-labrax wrote: post #89

Earlier quoted context omitted.

You're describing Red Hat! After spending multiple years helping with the development of Flatpak, which is a sandboxed environment with file pickers just like you describe, they recently announced[1] that they would no longer be contributing to LibreOffice in Fedora and instead will be contributing to a Flatpak version instead. Personally, I am not so sure about Flathub (the 'official' repository for Flatpak bundles)…

That's interesting. So is Flatpak actually secure against malicious code? That is, would you trust running malware if it's packaged as Flatpak? I'm saying this because we're talking through a platform that is trusted by the majority of pepple to run malware - the web browser. We don't manually check if the Javascript or Wasm code is good or bad before we visit a web page. Few people disable scripts altogether. We cou…

I wouldn't say that Flatpak is secure against specifically designed malware - applications can still run machine code directly on the CPU and make Linux system calls, and so could exploit any vulnerabilities (like privilege escalation) that they might have. However, I would certainly trust Flatpak to protect me against excessively snooping applications which are otherwise legitimate, which it can do by limiting access to specific filesystems or devices.

For JavaScript, web browsers have good sandboxing, but arguably also have a smaller attack surface than Flatpak because the page cannot run system calls directly. I don't yet know enough about WASM to know if that tangibly changes the situation.

Post reply on HN