[ / / / / / / / / / / / / / ] [ dir / acme / agatha2 / arepa / asmr / fascist / general / mde / vg ]

/tech/ - Technology

September 2018 - 8chan Transparency Report
Email
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Flag
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options

Allowed file types:jpg, jpeg, gif, png, webm, mp4, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 3 per post.


File: 4bd7b74dcc7c7c9⋯.png (11.45 KB, 1680x1200, 7:5, snapcraft_green-red_hex.png)

 No.984541

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

Why not just compile your code?


 No.984552

>>984541

>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

>>984548

>what are dependencies


 No.984555

>>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

>>984555

To be fair, poettering has good ideas SOMETIMES, but he can never execute them remotely well.


 No.984568

>>984559

Name one.


 No.984571

>>984568

his suicide


 No.984580

>>984541

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

>>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

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

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

>>984633

>muh duplicated libs

Oh no, 2 GB extra. Whatever will I do.


 No.984649

>>984541

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

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

>>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

>>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

File: 4c948adad320cc5⋯.jpg (1.19 MB, 3125x3508, 3125:3508, 1520542324930.jpg)

>>984541

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

>>984838

>your pic

owo


 No.984845

>>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

File: c5c9f25117dfd4c⋯.jpg (47.06 KB, 640x911, 640:911, c5c9f25117dfd4ca1d01e009b7….jpg)

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

>>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

File: e9add668197e2cb⋯.jpg (75.88 KB, 643x768, 643:768, 87bc370dd017f9e90bb86a2dc8….jpg)

>flatpak

>snap

>not appimages and guix


 No.984882

Talk about timing

https://flatkill.org


 No.984887

>>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

>>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

>>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

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

>>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

>>984898

Because compiling shit and then running it provides no isolation what so ever.


 No.984901

File: 1699d12025a186f⋯.jpg (18.14 KB, 640x504, 80:63, 1538405312653.jpg)

>>984898

>complaining about minor grammar issues on an image board

Look faggot grammar cucking is for reddit


 No.984903

>>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

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

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

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

>>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

>>984849

>>984879

This. Why Flatpak over appimage, if you just want to distribute a standalone program without worrying about dependencies?


 No.984927

>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

>>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

>>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

>>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

>>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

>>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

File: f4a146da82deec5⋯.jpg (228.75 KB, 1001x678, 1001:678, f4a146da82deec5f28399778e0….jpg)

>>984541

>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

>>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

>>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

>>985095

git is for code. He's talking about rollbacks of literal binary compiled programs.


 No.985109

>>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

>>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

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

>>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

>>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

>>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

>>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

>>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

File: 2c8b696abdf1f60⋯.jpg (39.6 KB, 591x585, 197:195, DU9VGaJV4AAVumt.jpg)

>>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

>>985748

>intentionally using inferior software just because of ideology

this is your brain on down syndrome


 No.985768

>>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

File: 3e82f42fa88eadb⋯.png (2.7 MB, 2448x1828, 612:457, fang_the_wyvern_by_fer7dra….png)

>>985754

Nice projection there.

>>985768

This isn't hypothetical; it's already happening to the MIT-licensed Clang compiler with proprietary extensions.


 No.985778

>>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

File: d2a6a0514c4536e⋯.jpg (69.31 KB, 1187x399, 1187:399, DnNueLaX0AAwJPY.jpg)

>>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

>>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

>>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

File: 99ac7e64ec18886⋯.png (727.28 KB, 1058x1500, 529:750, 63915fa22faffc19ebe6a948c8….png)

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

>>985785

>hurrr durr you have to be enslaved in order to actually be free because being chained is actually the end of limitation.


 No.985788

File: 7467c7184fc5a70⋯.jpg (149.05 KB, 951x500, 951:500, 112df5268461c268e40614ea0f….jpg)


 No.985789

File: d33b43959390e8d⋯.png (2.08 MB, 2000x1304, 250:163, d33b43959390e8dfe5ab5ba414….png)

>>985786

.tar.gz

.dar.lzma


 No.985790

File: 5fadb70aa906630⋯.png (161.33 KB, 659x1200, 659:1200, 68a510c4fe16dd2f5bd063d677….png)

>>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

File: b39740dfef9ae53⋯.jpg (314.68 KB, 1000x1314, 500:657, 9a3323fb863dcc0ca0d0d9986d….jpg)

>>985789

Obviously, the standard will need to be updated a little.


 No.985792

File: 98572ccd2ae11a7⋯.png (304.3 KB, 595x850, 7:10, aHR0cHM6Ly9zb2NpYWwuc3VwZX….png)

>>985790

>You can open another thread

>FatELF

What a wonderful idea!


 No.985794

File: 1fed34f18b00ae7⋯.jpg (144.48 KB, 986x1140, 493:570, 1fed34f18b00ae749b3ecc04fb….jpg)

>>985791

Let's deviate as much as possible and use DEFLATE instead!

We'll call it .EXEcutable!


 No.985795

File: 379bee577b82a48⋯.jpeg (Spoiler Image, 240.22 KB, 1200x1500, 4:5, 00dffb2104b029092a5a1969c….jpeg)

>>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

File: e5092f0fd9005a8⋯.jpg (222.38 KB, 688x971, 688:971, e5092f0fd9005a8bb9f421454a….jpg)

>>985795

Oh goodie! And how do they isolate anything?!?


 No.985798

>>985796

Same was as Appimage can would work.


 No.985799

File: bce65de05480b1c⋯.jpg (57.59 KB, 750x750, 1:1, DoRhRb3W0AAm3vG.jpg)

>>985798

Oh great! Let's make another dependency!


 No.985800

File: daff46a7fac42cc⋯.png (Spoiler Image, 872.18 KB, 1200x1200, 1:1, DTm8dqqW4AAp4O4.png)

>>985795

Nice...


 No.985801

>>985799

And how do you propose we handle 3rd-party application distribution?


 No.985803

File: d8829ca75cbd84d⋯.jpg (285.23 KB, 1365x2048, 1365:2048, d8829ca75cbd84d2ded8047ad6….jpg)

>>985801

There's a thing called `make`, it's really cool!

Also pkgsrc has been recalled 2x


 No.985804

>>985803

How's that going to work for proprietary apps?


 No.985805

File: f9b9f4b1db1b472⋯.jpeg (105.44 KB, 1434x2048, 717:1024, Cq9M97sUkAAsAcS.jpg:large.jpeg)

>>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

File: 316a737f4ffff21⋯.png (77.8 KB, 240x265, 48:53, 316a737f4ffff2194a48dafa42….png)

>>985804

We don't give a shit about (((proprietary apps))) so you can fuck off back to /g/


 No.985810

File: 00ff654f4fd5610⋯.jpg (554.88 KB, 846x1000, 423:500, 6dc8130aac076de4d2ed2e850f….jpg)

>>985807

Is that why Wine is seeing so much attention here these days?


 No.985811

File: 77090b410fa6078⋯.jpg (34.69 KB, 720x570, 24:19, DjiA581VsAA3EwC.jpg)

>>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

File: 21be73a35ce0e4e⋯.jpg (110.11 KB, 768x1024, 3:4, DoVb2KOU8AApsVG.jpg)

>>985804

Copyright Anonymous Doe 2018

All rights reserved.


 No.985815

File: 502259d0d338bcc⋯.png (916.32 KB, 1024x1024, 1:1, 502259d0d338bcc2affea9d8f6….png)

>>985811

>>985810

>Oy vey you can't fix every single thing so just give up


 No.985816

>>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

File: e75579ab4754f16⋯.png (760.46 KB, 1046x675, 1046:675, llY02cp.png)

>>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

File: db8ea1b6bc6896a⋯.png (538.76 KB, 600x800, 3:4, 034a1db9d9a55b8db983ed397f….png)

>>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

File: 955c23441bb0c7f⋯.jpg (152.92 KB, 826x1168, 413:584, DoQNCQ8U4AEebSg.jpg)

>>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

>>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

File: 70984caf176577d⋯.jpeg (131.79 KB, 400x500, 4:5, d409c667d540869ca69e5cb2a….jpeg)

>>985820

Nothing Valve has done with Proton is proprietary. Wine and even ReactOS can just fork everything whenever they want.


 No.985837

File: 5b86a6256ca67b2⋯.jpg (688.75 KB, 1073x1514, 1073:1514, 66281678_p0.jpg)

>>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

>>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

File: be90ea5f0524fb6⋯.jpg (174.58 KB, 1920x1080, 16:9, small hint.jpg)

>>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

>>985837

The GPL literally has nothing to do with what I said. Wine is mostly LGPL.


 No.985844

File: 9ff40cdbaad3ba1⋯.jpg (36.22 KB, 620x445, 124:89, gjx1b.jpg)

>>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

>>985844

Stop trying to derail. Wine is meant for running proprietary windows apps. When is your halfchan ban up?


 No.985850

>>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

File: 7063b1f8bc0c4e0⋯.jpg (133.14 KB, 700x700, 1:1, 27-gamergate.w700.h700.jpg)

File: 6e83d0bb0620aa4⋯.jpg (58.68 KB, 800x450, 16:9, large.jpg)

>>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

>>985856

>Totally lacking content: the post.

Look kid go back to cuckchan.


 No.985877

File: 6dea6eb3c637a3a⋯.jpg (23.47 KB, 500x333, 500:333, Laughing-Men-In-Suits.jpg)

>>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

File: 01053dca07f8ddf⋯.jpg (87.58 KB, 669x696, 223:232, 1535725705177.jpg)

>>985877

>just audit literally everything you run goy

>virtualization is broken goy you can't trust it


 No.985887

File: b51feb3d501923c⋯.jpg (26.17 KB, 600x200, 3:1, 600x200.jpg)

>>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

File: 9bcb85abad6d9b8⋯.jpg (86.15 KB, 1030x720, 103:72, 9bcb85abad6d9b8c1cbba8b566….jpg)

>>985887

I'm still waiting for even a single argument.


 No.985892

File: 0e250e7c8b0c4f3⋯.jpg (6.99 KB, 128x128, 1:1, 8Kof22m8_reasonably_small.jpg)

>>985889

Of what my dear?

Everything that could have been discussed has.

Or do you really want to LARP?


 No.985897

>>984541

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

>>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

File: b39d76424d08cef⋯.jpg (60.16 KB, 680x383, 680:383, DpPCwjkUUAAFWuO.jpg)

>>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

>>985949

Seems uncle has a stalker...


 No.985975

>>985971

That weird twitter screenshot? Seems more like namefagging to me.


 No.985976

>>985975

Doesn't sound like him to me.


 No.985980


 No.985985

>>985822

>ReactOS

I really wish that had better hardware support.




[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / acme / agatha2 / arepa / asmr / fascist / general / mde / vg ]