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

/tech/ - Technology

Winner of the 68rd Attention-Hungry Games
/d/ - Home of Headswap and Detachable Girl Threads

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

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)


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?


Why not just compile your code?



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



>what are dependencies



>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



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



Name one.



his suicide



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



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.



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.


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.



>muh duplicated libs

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



Absolute pozz. Snap is absolutely the worst dumpster fire of package managers. Flatpak is, perhaps, acceptable for proprietary software, like steam.


Not >>984559

But Linux NEEDS better Audio system and init+process supervisor, but SystemDick and PukeAudio are just awful.


Having the storage space capacity is not an excuse for bad engineering, soydev.


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.



I tried downloading some snaps and they just didn't work. PATH variables all fucked up. Get your shit together, Shuttleworth.



>But Linux NEEDS better Audio system

All it needs is a proper OSSv4 implementation.


It prevents dependency hell so I'm all for it



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



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.


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


Appimages are fine, especially for shit like Krita, which requires KDE5 libs to run. Everything else is cancer. Especially snaps, fuck Ubuntu lock-in.



>your pic




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.


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?



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


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



>not appimages and guix


Talk about timing




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?



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



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.



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



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.



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



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


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


>complaining about minor grammar issues on an image board

Look faggot grammar cucking is for reddit



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.



Snap and flatpak straight up make my software run faster. It's alright



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.



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.


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.


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.



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.



>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




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


>Do you think it's poetteringware trying replace package managers as we know them?


Always beware of solutions in search of a problem.




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.



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.



Wow this must be bait no one can be this fucking retarded.



The problem is the fact that there's



>arch tar.xz

>slackware tgz and txz

>whatever gentoo uses for binary packages


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.



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.



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.




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



So isn't running a random binary online.



Felt, >>>/grammar/


Depends your threat model.

I'm waiting on my respondent to answer.


Thank you brother.


How is pkgsrc 'shit'.


Because sooner or later your dependency will be new hardware after a nice rootkit.


>Any "solution" to this is guaranteed to be over-engineered

I didn't know Jails were difficult to implement.


It's ok not knowing how to make



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



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


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


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



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



> /dev/usr/build/2.5/gimp/ &/dev/build/stable/gimp




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



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



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.


>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



>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



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


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


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.



Is that what sold people to Windows?


... And how is that 'safer' than source builds?


>but new users *must* understand that GNU/Linux/BSD/UNIX/whatever isn't Windows.


These LPoS inbreeds want NotWindows, with all the flaws, faults, and botnet.


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


There's a scalability issue in their model.



>And if your fresh software breaks your stable kernel, what do?


How can a browser "break" a kernel again?

>so does a rootkit

Ah, never mind.



>But Linux NEEDS better Audio system

Alsa + jack has never failed me once and works fine

>and init+process supervisor

>process supervisor

Fuck off.



You've never vectored video&images to break your display server?



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



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.



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.



I agree. As long as proprietary licensed code is better use it.



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.


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


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





>intentionally using inferior software just because of ideology

this is your brain on down syndrome



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.


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


Nice projection there.


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



>other people should be banned from writing their own software if it uses yours

okay bud nice proprietary goal u got there


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


Are you retarded? The GPL doesn't even say that. What the fuck is with these /g/tards posting here the past few weeks?



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.



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.


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.



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


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


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





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


Nigger we're talking about stuffing binaries and libraries into THICC FatELF packages. You can open another thread to sperg over the GPL.


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


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


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


>You can open another thread


What a wonderful idea!


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


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

We'll call it .EXEcutable!


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


FatELF is the granddaddy of these universal packages, how new are you?


Lets keep 'ELF' in the name as a justification to post lewd elves.


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


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



Same was as Appimage can would work.


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


Oh great! Let's make another dependency!


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





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


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


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

Also pkgsrc has been recalled 2x



How's that going to work for proprietary apps?


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


This is why Blender being free is a bad thing.



just don't run them, same for GPL, don't need em


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


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


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


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


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


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.


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


Copyright Anonymous Doe 2018

All rights reserved.


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



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



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.


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


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.


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


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.


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


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



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


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


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


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


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?



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


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


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?



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


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


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



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



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


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.


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)


My friend, I never introduce Wine, I called out the slider.


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



>Totally lacking content: the post.

Look kid go back to cuckchan.


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


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.


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


>just audit literally everything you run goy

>virtualization is broken goy you can't trust it


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


Here's a projection store for you!


How's your proprietary software CoC sucking going btw?


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


I'm still waiting for even a single argument.


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


Of what my dear?

Everything that could have been discussed has.

Or do you really want to LARP?



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.



Still waiting for even just a single one.



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.


What Sprectre vulnerabilities? ARM Cortex-A7 and older chips that don't do speculative execution don't have this problem.




i'm waiting for you to mention any actual pros instead of just sitting back lazily expecting cons


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



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



Seems uncle has a stalker...



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



Doesn't sound like him to me.





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 ]