[–]▶ No.984541>>984552 >>984580 >>984621 >>984649 >>984838 >>984895 >>984905 >>985074 >>985897 [Watch Thread][Show All Posts]
What do you think of all these supposed upgrades to package managers? Do you think it's poetteringware trying replace package managers as we know them?
▶ No.984548>>984553
Why not just compile your code?
▶ No.984552>>984555
>>984541 (OP)
>Do you think it's poetteringware
Flatpak makes it a point on their website that they do not and will not require systemd, only needing it on an old, long-outdated version.
▶ No.984553>>984617
>>984548
>what are dependencies
▶ No.984555>>984559
>>984552
>The idea of using application containers in GNOME was first proposed in 2013 by Lennart Poettering ... it was originally called xdg-app.
It is literally Poeterringware
▶ No.984559>>984568 >>984649
>>984555
To be fair, poettering has good ideas SOMETIMES, but he can never execute them remotely well.
▶ No.984568>>984571 >>984649
▶ No.984571
▶ No.984580
>>984541 (OP)
I think it might have some utility as a poor man's container for servers.
It's worse than useless for desktop.
I don't think it's trying to replace package managers as much as it's a poorly made piece of software that doesn't know it's a package manager
▶ No.984617>>984798
>>984553
Is this your argument, that source packages can't bundle or self make their dependencies recursively?
Isolation should be at the kernel, where it was always designed to be.
▶ No.984621
>>984541 (OP)
It's mainly attractive for proprietary software like Steam. Another good thing is that it does not requires sudo and does not mess with your system. However, for that I prefer a package manager like Guix or Nix instead, it's the superior design.
▶ No.984633>>984640
For the most part it's fucking stupid. You wouldn't use it for 99% of programs because then you'd end up with over six gorillion copies of the same libs and dependencies on your computer eating up your disk space. One acceptable use for them would be something like distributing windows games for GNU/linux since setting up games to work with wine is an absolute nightmare, but so far the only ones offering this are a handful of internet pirates who only like obscure indie games.
▶ No.984640>>984649
>>984633
>muh duplicated libs
Oh no, 2 GB extra. Whatever will I do.
▶ No.984649>>984770 >>985035 >>985055 >>985323
>>984541 (OP)
Absolute pozz. Snap is absolutely the worst dumpster fire of package managers. Flatpak is, perhaps, acceptable for proprietary software, like steam.
>>984568
Not >>984559
But Linux NEEDS better Audio system and init+process supervisor, but SystemDick and PukeAudio are just awful.
>>984640
Having the storage space capacity is not an excuse for bad engineering, soydev.
▶ No.984674>>984720
Snap is fucking garbage.
Regret ever using it.
Everything is broken.
Disabled all snaps I had before, only kept Slack and VS-Code on it because I don't want that shit directly installed on my machine.
▶ No.984720
>>984674
I tried downloading some snaps and they just didn't work. PATH variables all fucked up. Get your shit together, Shuttleworth.
▶ No.984770>>984826
>>984649
>But Linux NEEDS better Audio system
All it needs is a proper OSSv4 implementation.
▶ No.984795
It prevents dependency hell so I'm all for it
▶ No.984798>>984845
>>984617
>Isolation should be at the kernel, where it was always designed to be.
Well faggot if you knew what you were talking about you would know this is just a standard combination of the existing kernel isolation tools. That's all docker is 2. A convenient wrapper to manage the existing kernel isolation tools (that are a massive PITA to use manually).
▶ No.984826
>>984770
I've had nothing but shit with both ALSA and Pulseaudio hanging my system whenever I try to change my headphone amp's impedance on the Xonar Stx II.
▶ No.984838>>984843
>>984541 (OP)
Appimages are fine, especially for shit like Krita, which requires KDE5 libs to run. Everything else is cancer. Especially snaps, fuck Ubuntu lock-in.
▶ No.984843
▶ No.984845>>984860
>>984798
Docker isn't being discussed.
And if you are my respondent, so are you admitting dependencies are non issues when source compiling compared to a wrapper that duplicates dependencies.
▶ No.984849>>984926
So is this right?
Appimage's are fine and easiest to use but could have security flaws.
Flatpak's have better security but are made by poettering.
Snaps suck because it's locked into Ubuntu?
Docker is more for deploying apps on servers?
▶ No.984860>>984887
>>984845
>Docker isn't being discussed.
T. retard who can't read.
>so are you admitting dependencies are non issues
If you want to just re-invent the package manager and manually patch shit instead of virtualization another package system which all this shit allows. Enjoy your security bugs faggot.
▶ No.984879>>984926
>flatpak
>snap
>not appimages and guix
▶ No.984882>>984889 >>984903
▶ No.984887>>984894
>>984860
You are confusing.
I thought that by being able to read and verify every part of the compilation process I have more control and can fuzz with test cases, making it more secure than a binary I downloaded off the internet that pretends to isolate it's run time.
The one introducing docker in the entire thread is you. Or are you dismissing the kernel shouldn't be responsible for isolation resource, and instead a binary downloaded off the internet?
▶ No.984889>>984890
>>984882
This has been discussed for a while, im not sure why anyone would willingly use flatpak. The only reason people did is because they were plebs who couldnt find a way to properly install proprietary shit
▶ No.984890
>>984889
This also means Appimage, snap, etc. are vulnerable to the same vectors described in the post.
Oh well, never cared about these bundles of trojans.
▶ No.984894>>984898
>>984887
>Or are you dismissing the kernel shouldn't be responsible for isolation resource
You the idiot STILL fail to understand that this IS the kernel isolating resources. These are just utilities that use the existing kernel protocols to setup up sandboxes. All these tools docker, flatpak, snap, lxd, are using the same kernel features.
▶ No.984895
>>984541 (OP)
Docker running some statically linked distro (suckless gang wins again) is better, and has actual features (load balancing over a cluster, for example) instead of dumb memes and a GUI.
▶ No.984898>>984900 >>984901
>>984894
>this are the kernel isolating resources
I'll assume you're a secondary English learner.
Why would I implement these, than source compiling on a hardened [micro] kernel.
Explain to me the advantage.
▶ No.984900>>985019
>>984898
Because compiling shit and then running it provides no isolation what so ever.
▶ No.984901>>985019
>>984898
>complaining about minor grammar issues on an image board
Look faggot grammar cucking is for reddit
▶ No.984903>>984911 >>984912 >>985019
>>984882
Could a sandbox even work with something like Gimp? Being able to write images to any directory is something I would expect from an image editor.
▶ No.984905
>>984541 (OP)
Snap and flatpak straight up make my software run faster. It's alright
▶ No.984911
>>984903
You could disable network access, have it use the secure mode x connection (can't key log you like x over ssh), limit it to your images folder (and the config folder), and then you have a way way way more secure image editor that can't destroy your user after you open a meme with an exploit in it.
▶ No.984912
>>984903
If this was improved on you could have a mode that isolates everything by default and then gives you a popup.
>thiis application wants to open this file
>this application wants to connect to this site
Things like this would make every day applications way more secure for the average user.
▶ No.984917>>984919 >>984946 >>985019
The desktop OS permissions model is just fucked and no amount of ghetto rigged patches will solve it, I am afraid. How many programs you have installed need full disk access? Your GIMP doesn't need access to anything else than media directories, nor most /tmp files; GIMP may be a benign and hard to exploit program, but what about Firefox? Why the fuck does it have access to your .bashrc? You know finding an RCE and then modifying it to load your backdoor is the easiest fucking way to install a userland keylogger to get your root password when using su or sudo from one of your terminals, then proceed to infect the rest of the system, right? Given, it is very obvious, but who checks their all their init files daily before writing their passwords?
Also, why the fuck are the kernel's security extensions only set-able by root? Why can't I, as a user, tell a program not to have access to certain kernel calls? In order to set up certain sandboxes, you need to invoke a SUID executable to set up all correct permissions, which kind of defeats the point of security.
We need to get our shit together. Sandboxing is a patch; a nice patch, but a simple patch over a gigantic hole, after all. Not all programs need access to every capability, and you don't need to escalate privileges to limit privileges. That's just stupid. The only OS that gets this more or less right is Android, and the rest of it is a dumpster fire so go figure.
▶ No.984918>>984920 >>985019
Existing package managers are complete shitshows, so any change is welcome. Windows standalone installs would actually be welcome at this point. At least they have one, consistent root install dir.
▶ No.984919>>984930
>>984917
And let's be far even android is not nearly granular enough. I end up just putting much of the shit I run in it's own VM for each thing. PITA but I have the RAM for it.
▶ No.984920
>>984918
>At least they have one, consistent root install dir.
Not for the last 20 years. Almost every program is in 50 different places. Hell even minecraft has shit in .appdata
▶ No.984926>>985019
>>984849
>>984879
This. Why Flatpak over appimage, if you just want to distribute a standalone program without worrying about dependencies?
▶ No.984927>>984954
>Do you think it's poetteringware trying replace package managers as we know them?
Yes.
Always beware of solutions in search of a problem.
▶ No.984930
>>984919
>VM
That's kind of the beef I have with security systems: it's either all insecure all open, or full blown Qubes autism.
It wouldn't be difficult to design a system with UNIX permissions that let each program have their own nicely compartmentalized area and make it mostly transparent to the user. Set up your home directory to symlink stuff to "areas" (thematic directories owned by their own group: ie folder "images" by "imagesgroup", folder "documents" by "documentsgroup", etc), and set up permissions so only members of the zonegroup can access it. Then, set up a user and home directory for every program you want to use, register them in the groups of the common zones you want to let them access (most programs have clear areas they should or should not access, so sane defaults may be applied: Firefox doesn't need write access on .bashrc WHATSOEVER, and questionably read access too), then symlink them to their homes too. If you want extra security, and I know some people will slap me for saying this, you can chroot them too and only symlink strictly the stuff you need (contrary to popular belief, chroot is a security enhancement if the program you are using is not run as root or someone finds a way to escalate privileges, in which case you are fucked with or without chroot). Use LXC maybe. Configure Xorg to accept clients running under a different user, and the configure Pulseaudio (via UNIX sockets) or whatever system you are using to accept audio from other users, too, and you have an easily configurable system that only lets each program see what they need to see, kind of like the NixOS store.
This is relatively simple to develop, easy to automate, easy to make it mostly transparent to a user (maybe they will get confused at first why can't their programs see every file in the "open file" dialog, but whatever), and easy to configure with sane defaults (unlike firejail, which sometimes kills programs with the default firejail configs for that specific program), so I do not get why nobody has attempted it.
▶ No.984946>>984949 >>984965
>>984917
I don't really understand this argument. Capability people are like, "why can my PDF reader access every file". Where the hell do they get this idea?
If you open a non-pdf file with a PDF reader, it'll say something along the lines of "Cannot open files of this type". I tested this with the zathura reader and evince.
If you open a non-image or non-gimp file in gimp... you actually can't do that. They literally don't show up.
▶ No.984949
>>984946
Wow this must be bait no one can be this fucking retarded.
▶ No.984954>>984968 >>984972 >>985109
>>984927
The problem is the fact that there's
>rpm
>deb
>arch tar.xz
>slackware tgz and txz
>whatever gentoo uses for binary packages
>etc
Not exactly practical for someone who wants to do a windows style "here's your .exe file installable on every system with bundled dependencies, bro"
Now as for why flatpak would be better or worse for this than snap or appimages, beats me, but that's part of the reason for such solutions' existence, along with sandboxing or some shit like that.
▶ No.984965
>>984946
Okay, I will bite.
GIMP has the capability of opening anything, it just politely refuses to open files they do not support. Keyword "politely". If GIMP were to go rogue due to a RCE/buffer overflow exploit (if you wanna learn what's this in a fun way, watch some AGDQ hacks demos to shoe the kind of shit this could do), it could open anything amd overwrite anything, including text files.
This is a really serious vulnerability and it's just waiting to get exploited. Your music player has the potential to upload your saved passwords to some remote server because there is nothing stopping it from doing it, let that sink in. It is even worse that Firefox trusts itself with its own sensitive data, but there is no way around it unless we start implementing some sort of login server protocol to let another smaller, more specialized and isolated program handle logins for other programs.
▶ No.984968>>984972 >>985019 >>985106 >>985110
>>984954
Yeah I don't really consider that a problem, any more than the existence of distros themselves is a problem. It should fall on individual communities to provide and maintain binaries. Any "solution" to this is guaranteed to be over-engineered and make life worse for everybody.
Other users have said that this makes it easier to distribute proprietary binaries like Steam. That doesn't surprise me, since Red Hat has long sought to corporatize Linux with every piece of shit scheme it cooks up. The problem is proprietary software. If Valve wants to make money off the free software ecosystem while refusing to play along, then we shouldn't roll out a red carpet for them. Let them distribute their own fucking blobs.
On the whole Linux is completely unrecognizable to me compared to when I started using it. I'm so glad I jumped ship when systemAIDS was being pushed on everyone.
▶ No.984972>>985019
>>984954
>>984968
The main issue is we fucked up from the beginning. The whole RPATH shit in ELFs is dumb and shouldn't exist in the first place. Libraries should, in some way, register their "capability" and version to the system themselves, rather than letting packagers decide where to put the libraries or how to name them. Regardless of where the dumb fuck packagers would put it, libraries would be accesible by the linker as described by the ELF (which would now name the required capability and version number) regardless of where they put it or how they named them, as long as they didn't patch the "capability" name registered themselves, which they shouldn't do unless there is a conflict between two libraries or they are retarded. By registering both capability and version, you could even have several versions of the same library installed, and all of them would just werk; in fucking fact, you could use semver to let the linker know when you can use newer versions and when you need to keep older versions.
tl;dr we went so deep in the bazaar we can't build cathedrals with our bazaar-exclusive tools
▶ No.985019
>>984900
So isn't running a random binary online.
Next
>>984901
Felt, >>>/grammar/
>>984903
Depends your threat model.
I'm waiting on my respondent to answer.
>>984917
Thank you brother.
>>984918
How is pkgsrc 'shit'.
>>984926
Because sooner or later your dependency will be new hardware after a nice rootkit.
>>984968
>Any "solution" to this is guaranteed to be over-engineered
I didn't know Jails were difficult to implement.
>>984972
It's ok not knowing how to make
▶ No.985035>>985095 >>985109
>>984649
<Having the storage space capacity is not an excuse for bad engineering, soydev.
>can install several versions of the same program
>can easily rollback updates if one has a regression or bug
>can install the latest programs even on stable distros like Debian Stable or CentOS
>completely eliminates the chance of a PPA or AUR fucking up your system or to suffer a dependency hell
>programs are sandboxed
<muh duplicates libs muh windows does it so it must be rong
Windows doesn't sandbox programs, cannot roll back updates necessarily (because Registry shenanigans), cannot install several versions of the same program at once and doesn't have a repository system like Snappy and Flatpak do.
So you can go fuck yourself.
▶ No.985055
>>984649
>Having the storage space capacity is not an excuse for bad engineering, soydev.
Being able to handle multiple copies and different versions of libraries is better engineering than not being able to handle them.
Being able to reuse the same version of a lib for multiple programs is good too, but that's not in question here.
▶ No.985074>>985562
>>984541 (OP)
>supposed upgrades to package managers
They're the latest in retarded nu-loonix memeware designed to turn Loonux into Wangblows 2.0.
Other memeware in this category include SystemDicks, PissAudio, Rust, and Go.
Speaking of memeware, Linux itself is memeware at this point since Torvalds cucked out.
BSD is the future. At least BSD isn't suffering from this influx of memeware... yet.
▶ No.985095>>985099 >>985107
>>985035
>can install several versions of the same program
You are saying this like you couldn't before these existed. Like if we didn't have /dev/usr/build/2.5/gimp/ &/dev/build/stable/gimp
>can easily rollback updates if one has a regression or bug
Oh wow, tell me more about this! How intricate are the rollbacks compared to git revert!
>can install the latest programs even on stable distros like Debian Stable or CentOS
So, you're saying you couldn't experiment on Development while on Stable, all the while isolating dependencies on a separate build partition. I wonder how software ever got made then.
>completely eliminates the chance of a PPA or AUR fucking up your system or to suffer a dependency hell
Oh, I didn't know some people didn't know how to use wget tar.gz && tar xzf
>programs are sandboxed
This magical sandboxing, can you view the source code, and process intricately?
▶ No.985099
>>985095
> /dev/usr/build/2.5/gimp/ &/dev/build/stable/gimp
wut
▶ No.985106>>985162 >>985531
>>984968
The idea is
>roll out the red carpet for proprietaryfags
>more people consider Linux 'finished' because it now has "muh adobe" or "muh gaymes"
>marketshare increases
>hardware companies realize Linux isn't some shitty toy OS with regards to the desktop
>they start actually giving decent support for things
▶ No.985107>>985162
>>985095
git is for code. He's talking about rollbacks of literal binary compiled programs.
▶ No.985109>>985117 >>985162
>>984954
I know what you mean, but new users *must* understand that GNU/Linux/BSD/UNIX/whatever isn't Windows.
Both Gentoo and Slackware just use standard tarballs (or git) In addition to makefiles, Gentoo also has ebuilds which are similar to PKGBUILDS in ArchLinux. But I agree that Appimages and Flatpaks can be useful for installing software with a lot of dependencies or non-free software.
>>985035
>can install several versions of the same program
You can already have different versions installed at the same time. You can just fetch the source tarball and install it to your home directory, or use portage (or some other package manager that supports it). OR Install GoboLinux
>can easily rollback updates if one has a regression or bug
You could use the filesystem (like ZFS or HAMMER or things like LVM) or tarballs to do this.
>can install the latest programs even on stable distros like Debian Stable or CentOS
This completely defeats the purpose of using a distro that's made for servers and corporations. Just install Debian sid or whatever.
>programs are sandboxed
How? Why? You can sandbox programs without Appimages, Flatpaks or Snap cancer
▶ No.985110
>>984968
>It should fall on individual communities to provide and maintain binaries.
Why is that? When a browser security update rolls out, I want that update this instant, not when the middleman (maintainer) finds time to update the package.
>Other users have said that this makes it easier to distribute proprietary binaries like Steam.
Except.. It doesn't help proprietary software in particular, it just helps everyone.
Btw (((proprietary))) software developers tend to not like user-controlled sandboxing. It may e.g. prevent Chrome from benevolently scanning your files, you know
▶ No.985117>>985162
>>985109
>This completely defeats the purpose of using a distro that's made for servers and corporations. Just install Debian sid or whatever.
W-wait wasn't free software all about choice?
I, like most users, want some software to be fresh, e.g. browser, editor, games, etc, whilst I want the kernel, init systemd and shits to be stable and secure. There's nothing in the latest linux that isn't in lts that I miss on my desktop.
>Why?
Do you even security?
> You can sandbox programs without Appimages, Flatpaks or Snap cancer
But flatpak makes that easy and out-of-the-box'y. Also, appimages are not really similar to flatpak or snap
▶ No.985148>>985162
GUIX looks really attractive to me. I want freedom in my software, and the ability to have rollbacks and generations all wrapped up in Guile is nice.
▶ No.985162>>985320
>>985106
Is that what sold people to Windows?
>>985107
... And how is that 'safer' than source builds?
>>985109
>but new users *must* understand that GNU/Linux/BSD/UNIX/whatever isn't Windows.
THANK YOU
These LPoS inbreeds want NotWindows, with all the flaws, faults, and botnet.
>>985117
>I, like most users, want some software to be fresh, e.g. browser, editor, games, etc, whilst I want the kernel, init systemd and shits to be stable and secure.
And if your fresh software breaks your stable kernel, what do?
>you even security?
Do you?
>flatpak makes that easy and out-of-the-box
So does a rootkit!
>>985148
There's a scalability issue in their model.
▶ No.985320>>985335
>>985162
>And if your fresh software breaks your stable kernel, what do?
Wut
How can a browser "break" a kernel again?
>so does a rootkit
Ah, never mind.
▶ No.985323
>>984649
>But Linux NEEDS better Audio system
Alsa + jack has never failed me once and works fine
>and init+process supervisor
>process supervisor
Fuck off.
▶ No.985335
>>985320
You've never vectored video&images to break your display server?
▶ No.985531
>>985106
more like
>hardware companies realize Linux isn't some shitty toy OS with regards to the desktop, it's a golden goose
>they overwhelm all the finnish programming elders and throw spaghetti all over the kernel, leaving critical blobs here and there like a rabid chimp after an enema
but at least you can play your videogame anon
▶ No.985562>>985644
>>985074
None of the BSDs even have the GPL to mitigate the damage these mentally unstable eunuchs are wreaking in F/OSS. They're a stop-gap at best.
▶ No.985644>>985658 >>985748
>>985562
The license doesn't matter. You can fork GPL or BSD code. What matters is: how clean is the code? how many developers do you need? (not many with NetBSD or TempleOS. too many with Linux. others are in between).
And also the people in charge and the general culture of the project matters more than the license.
▶ No.985658>>985727 >>985748
>>985644
I agree. As long as proprietary licensed code is better use it.
▶ No.985727
>>985658
To clarify (if it wasn't obvious), I was talking about "open" licenses, where you can legally fork the code. Obviously if you use proprietary code in your open source project, it's going to invite lawsuits.
▶ No.985748>>985754 >>985768
>>985644
The license DOES matter when we're talking about CoCs and EEE. There is no kind of defense for making proprietary forks that are simply better than the open version
>>985658
Faggot.
▶ No.985754>>985773
>>985748
>intentionally using inferior software just because of ideology
this is your brain on down syndrome
▶ No.985768>>985773
>>985748
That's a hypothetical scenario that has no basis in reality. What happens is open source project gets subverted with corportate goons into key positions, and then the license doesn't matter because it's still the same license as before. Linux is still GPL, and FreeBSD is still BSD, and you can use them all you want, if you don't mind the SJW and big corporate stank everywhere.
So the personality of the individuals involved is more important than the license, because that's what decides how well they resists subversion. And so long as *their* project continues unmolested, it's fine. The fact that someone else can made a closed fork, or a CoCked fork doesn't matter. That's a different project, not theirs.
And the size and cleanliness of the code matters also, because then you can still recover in the event the mainline gets subverted somehow. With Linux, it hard. With NetBSD it's not as hard. That's again not because of the license, but just plain technical reasons.
▶ No.985773>>985778 >>985929
>>985754
Nice projection there.
>>985768
This isn't hypothetical; it's already happening to the MIT-licensed Clang compiler with proprietary extensions.
▶ No.985778>>985781
>>985773
>other people should be banned from writing their own software if it uses yours
okay bud nice proprietary goal u got there
▶ No.985781>>985784
>>985778
Are you retarded? The GPL doesn't even say that. What the fuck is with these /g/tards posting here the past few weeks?
▶ No.985784>>985785
>>985781
GPL specifically says that I have to follow the GPL for any code I write that happens to depend on yours. It is a proprietary license that does not respect user freedom.
▶ No.985785>>985787
>>985784
Keeping code GPL isn't the same as disallowing people to write their own modified versions, my dear immigrant. The only reasons you'd want to do that is either to be a dick to your users, or hide your shitty code.
▶ No.985786>>985788 >>985789
You faggots done? Can we get back to alternatives for packaging Linux apps? Personally, I think we should go back to square one and resurrect FatELF.
▶ No.985787>>985790
>>985785
>hurrr durr you have to be enslaved in order to actually be free because being chained is actually the end of limitation.
▶ No.985790>>985792
>>985787
Nigger we're talking about stuffing binaries and libraries into THICC FatELF packages. You can open another thread to sperg over the GPL.
▶ No.985791>>985794
>>985789
Obviously, the standard will need to be updated a little.
▶ No.985792>>985795
>>985790
>You can open another thread
>FatELF
What a wonderful idea!
▶ No.985794>>985795
>>985791
Let's deviate as much as possible and use DEFLATE instead!
We'll call it .EXEcutable!
▶ No.985795>>985796 >>985800
>>985792
FatELF is the granddaddy of these universal packages, how new are you?
>>985794
Lets keep 'ELF' in the name as a justification to post lewd elves.
▶ No.985796>>985798
>>985795
Oh goodie! And how do they isolate anything?!?
▶ No.985798>>985799
>>985796
Same was as Appimage can would work.
▶ No.985799>>985801
>>985798
Oh great! Let's make another dependency!
▶ No.985801>>985803
>>985799
And how do you propose we handle 3rd-party application distribution?
▶ No.985803>>985804
>>985801
There's a thing called `make`, it's really cool!
Also pkgsrc has been recalled 2x
▶ No.985804>>985806 >>985807 >>985812
>>985803
How's that going to work for proprietary apps?
▶ No.985805
>>985800
This is why Blender being free is a bad thing.
▶ No.985806
>>985804
just don't run them, same for GPL, don't need em
▶ No.985807>>985810 >>985811
>>985804
We don't give a shit about (((proprietary apps))) so you can fuck off back to /g/
▶ No.985810>>985815
>>985807
Is that why Wine is seeing so much attention here these days?
▶ No.985811>>985815
>>985807
Get the fuck off this site with that proprietary CPU you are using, on that proprietary motherboard, with the proprietary keyboard, with the proprietary screen.
▶ No.985812
>>985804
Copyright Anonymous Doe 2018
All rights reserved.
▶ No.985815>>985816 >>985817 >>985818
>>985811
>>985810
>Oy vey you can't fix every single thing so just give up
▶ No.985816>>985819
>>985815
I agree you should not give up despite some things being proprietary. This is why we need a good way to deal with photoshop on our systems. GIMP is not a viable alternative as the SHIT free CPUs you could be using are not viable.
▶ No.985817>>985929
>>985815
Not the two faggots you're replying to, 1) loving the new OC, 2) plenty libre hardware already in the market.
Not that they are Spectre 2.0 safe, not even the latest RiscV chips.
Plus, nothing stops anyone from homebrewing.
▶ No.985818>>985820
>>985815
This has literally nothing to do with what I said. Wine is going to be a boon for game preservation. Video games are not like other programs; there are cultural artifacts that NEED to be preserved for future generations. If some crazy autists want to totally rewrite the engine, then all the better, but most of the time we won't have a perfect FSF-approved solution for this problem.
▶ No.985819>>985839
>>985816
>good way to deal with photoshop on our systems.
It's called licensing, plenty property software on Linux.
The issue already discussed is that no amount of "isolation" software under ring 1 will be safe or secure, including libre software which proved already to successfully trojanize.
If libre software managed to get trojanized, proprietary only means it will.
▶ No.985820>>985822
>>985818
>Wine is going to be a boon for game preservation.
By allowing Valve, the wedge between your GPU and full ring 0 access?
Isn't this tactic called sliding?
▶ No.985822>>985837 >>985985
>>985820
Nothing Valve has done with Proton is proprietary. Wine and even ReactOS can just fork everything whenever they want.
▶ No.985837>>985842
>>985822
If Jacobsen can DMCA his code to disallow a company from using his GPL code, Valve with a team of attorneys can easily enforce BSD code as they please. In fact, relicensing is often committed to ensure maximum rights withheld.
Now, the discussion is still safety & security: licensing does everything proprietary companies desire, ignorant of whether they open source or not. So much so, end user agreements are licensed, and often agreed upon.
Did you ever click that ☑ stating you agree to comply to that GPL "app" you installed?
That's an EULA.
Guess which company innovated that digital contract?
FatELF won't secure your computer. Nor anything in the OP.
Guess who's job is that?
▶ No.985839>>985840
>>985819
>I don't understand how spectre works and am a total retard
look fuckwit you idiots keep spreading misinformation about how damaging this shit is. How about you think for just 10 seconds before posting. Notice how there are not millions of reports of VPS companies having all of their customers secrets stolen? The Intel ME shit also you faggots all complain about. Turns out that none of that shit actually matters.
▶ No.985840>>985850
>>985839
Speculating how memory will be addressed if you know the all the registers of an architecture?
Yeah I know how Spectre2 works.
Do you know what's the latest threat affecting all architectures without initial knowledge whatsoever about the hardware or even software?
>Notice how there are not millions of reports of VPS companies having all of their customers secrets stolen?
Do you know what they call this fallacy?
>Intel ME
Did I mention this? Or did you?
▶ No.985842>>985844
>>985837
The GPL literally has nothing to do with what I said. Wine is mostly LGPL.
▶ No.985844>>985846
>>985842
>GPL literally has nothing to do with what I said. Wine is mostly LGPL.
Your irony is so thick, I'm choking in laughter.
And you have yet to defend a single position you have stated.
Tell me uneducated hearsayer, why would "we" invest any development work to provide ease to proprietary companies to embed their products to a libre project comprised of hackers that built an operating system on internet, groomed in hacker ethics?
▶ No.985846>>985850 >>985856
>>985844
Stop trying to derail. Wine is meant for running proprietary windows apps. When is your halfchan ban up?
▶ No.985850>>985856
>>985846
Actually WINE is for running any program that follows the windows spec. There is nothing particular about WINE that has anything to do with proprietary software. For example WINE can run ReactOS software
>>985840
Yeah faggot you are going to have a hard time admitting none of the security shit you larp about is actually meaningful. Meanwhile shitty application exploits because someone forgot to check the size of a list happen every day.
▶ No.985856>>985861
>>985846
My friend, I never introduce Wine, I called out the slider.
>>985850
>Yeah faggot you are going to have a hard time admitting none of the security shit you larp about is actually meaningful.
Did I stroke a nerve? Or do you even know what LiveActionRolePlay even means anymore?
What character am I, I mean anyone in this thread is roleplaying as? Flak employees?
You still don't know how to argue, how pitiful, it's almost laughable!
▶ No.985861>>985877
>>985856
>Totally lacking content: the post.
Look kid go back to cuckchan.
▶ No.985877>>985882
>>985861
I'm not so sure who's more cuckheld, the one telling you Flatpack&FatELF won't secure you than reading and evaluating every process of the reproducible compilation, or the one that trusted some developer that claimed their software will be free off any "bad" things because they used X isolation gimmick.
Btw, you're Twitter feed is unzipped.
▶ No.985882>>985887
>>985877
>just audit literally everything you run goy
>virtualization is broken goy you can't trust it
▶ No.985887>>985889
>>985882
Here's a projection store for you!
https://en.wikipedia.org/wiki/Psychological_projection
How's your proprietary software CoC sucking going btw?
▶ No.985889>>985892 >>985945
>>985887
I'm still waiting for even a single argument.
▶ No.985892>>985903
>>985889
Of what my dear?
Everything that could have been discussed has.
Or do you really want to LARP?
▶ No.985897
>>984541 (OP)
I don't think I need any of this. To be honest I just want to keep my portage and pacman and want them to keep working like they always did.
▶ No.985903
>>985892
Still waiting for even just a single one.
▶ No.985929>>985949
>>985773
OpenBSD doesn't use any proprietary clang extensions. If another open source OS does, it means the people in charge aren't resistant to subversion. That's the root cause.
>>985817
What Sprectre vulnerabilities? ARM Cortex-A7 and older chips that don't do speculative execution don't have this problem.
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
▶ No.985945
>>985889
i'm waiting for you to mention any actual pros instead of just sitting back lazily expecting cons
▶ No.985949>>985971
>>985929
Spectre2
>CVE-2018-3640 -- Rogue System Register Read (RSRE) – also known as Variant 3a >Systems with microprocessors utilizing speculative execution and that perform speculative reads of system registers may allow unauthorized disclosure of system parameters to an attacker with local user access via a side-channel analysis. https://access.redhat.com/security/cve/cve-2018-3640 >CVE-2018-3639 – Speculative Store Bypass (SSB) – also known as Variant 4 >Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. https://access.redhat.com/security/cve/cve-2018-3639 >>This issue is known to affect CPUs of various microarchitectures from: AMD, ARM, IBM POWER8, POWER9, and SystemZ series, and Intel processors. https://bugs.chromium.org/p/project-zero/issues/detail?id=1528 https://www.redhat.com/en/blog/speculative-store-bypass-explained-what-it-how-it-works https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/
▶ No.985971>>985975
>>985949
Seems uncle has a stalker...
▶ No.985975>>985976
>>985971
That weird twitter screenshot? Seems more like namefagging to me.
▶ No.985976>>985980
>>985975
Doesn't sound like him to me.
▶ No.985980
▶ No.985985
>>985822
>ReactOS
I really wish that had better hardware support.