Page 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 75

Thread: Systemd's Plan For Stateless Systems, Factory Resets

  1. #21
    Join Date
    Jan 2014
    Posts
    27

    Default

    Daily reminder Prodigy is a disgusting Microsoft rapist paid to troll systemd threads.

  2. #22
    Join Date
    Jun 2014
    Posts
    16

    Default

    I truly hope all the systemd trolls are just trolling for fun, because it must be such a pathetic existence to actually believe the random shit they say on systemd topics.

  3. #23
    Join Date
    Jun 2009
    Posts
    1,184

    Default

    Quote Originally Posted by oneofone View Post
    I truly hope all the systemd trolls are just trolling for fun, because it must be such a pathetic existence to actually believe the random shit they say on systemd topics.
    i do believe they actually believe what they preach probably because most of them aren't devs or are highel level languages devs that never used git before, so they actually believe systemd is an nvidiaesque 30million LoC single blob named systemd that weights 1 Gb that reside in an evil git single repository when the actual facutal truth is that systemd is pretty much KISS compliant, dozens of small service in separate executable running ondemand exclusively when needed and this dozens of binaries only are good at doing very specific things and small sized.

    In fact systemd only need 5 systems to run, PID1 service, Dbus,Udev, journalctl and logind everything else is optional or ondemand and the "evil" additional tools are included to keep the standarization effect but prolly will never be used if it doesn't fit your use case

  4. #24
    Join Date
    Sep 2011
    Posts
    124

    Default

    Quote Originally Posted by justmy2cents View Post
    if i would have to guess, the applications will probably reside in both usr and home as part of http://www.superlectures.com/guadec2...ions-for-gnome
    Quote Originally Posted by interested View Post
    Looking into the crystal ball, the future seems to be that will be two kinds of "apps": the normal ones as we know it, in form of a rpm or deb package, and "sand boxed" apps that are developed via a special SDK, and runs in an environment that are totally independent of the underlying OS.

    Such SB apps can in theory run unmodified on any Linux distribution that support the sand boxing environment. Such apps could in theory be carried over to a new OS (either OS upgrade or another brand) without modification and without loss of data and configuration.
    There still needs a lot of work to make this happens, like kdbus in the kernel etc, so this is mostly theoretical at this point.

    AFAIK, you can just install normal apps either system wide in the "golden master" image (persistent) or in a running OS container if you got the right user permissions (might not be persistent across boots, depending of model.)


    I especially like the "Verifiable System". Security is so damn hard to get right on the Internet and every system exposed is under a constant attack. It would be nice if only a sand boxed container OS was exposed to the net, that could be verified as not-compromised (AV-scanners etc. aren't much help against this these days, and Tripwire and similar also have its problems).
    That makes a lot of sense. So, system wide apps get installed through the package manager to somewhere on / and sandboxed apps go to /home. However, will these sandboxed apps get to make any use of the system-wide installed libraries?

    Quote Originally Posted by justmy2cents View Post
    at least how i get it, i think there is no need for special SDK. making package would be the matter of build tools, where you specify target aka. "i want to run this on everything up from CentOS 5". build tools should simply make the package that will contain all the libraries needed to run on desired targets. no matter if you'll run it on distro that would already supply most of required ones.

    as far as SDK for sandboxing goes, again there should be no need for that. that is matter of sandbox it self, not your application. you need port 34534 for example, your socket code is just as usual, no difference. but, unless you specified sandbox to open it for you, sandbox simply won't allow it to pass trough. beside security, it also gives great overview of what application will do before it can do it. unlike half assed sandboxing in android for example

    not all applications would make sense to deploy like that, hell... i love package distribution. but for a lot... it's a way to go. it's also a way to get commercial development on board since targets are not restricted to singular distribution and you can provide long term support without the need to patch it every week just because some OSS project changed. not to mention the flaw of package management, usually you get constricted to specified version of app for whole life time of that distro, where installing newer can be rather painful experience.
    Could it be made so Gnome's libraries and KDE's Frameworks (which always come with an explicit minimum version of Qt that can be used) be made the SDK? Sort of how the Free Desktop Standards expects Qt and GTK to both be parts of the "Free Desktop" (which is what we all should refer to these desktops collectivitly, it's why the standard is there). This way, each sandboxed app does not have to include all of these libraries AND these important libraries will be sandbox ready.

    Quote Originally Posted by interested View Post
    There are several kinds of sand boxing when it comes to systemd. The present one relies on "kernel capabilities" and "cgroup" and is good for protecting services; you can lock down services so even if the "http" daemon is compromised, the attacker can't get privilege escalation, even by executing arbitrary code. Or prevent an attacked daemon from fork-bombing or hogging IO or CPU time. It can also prevent a compromised daemon from reading certain directories, even if it manages to execute code with system wide rights (root) etc.

    The other kind of sand boxing isn't implemented yet. It will require kdbus and "Portals" (similar to Android's "Intents" http://www.phoronix.com/scan.php?pag...tem&px=MTI5NDQ

    It will probably have a special SDK, so developers can target that instead of the underlying OS.
    The thinking is, that this allows app developers to potentially target all Linux distros at the same time, and will be a tremendous boost for Linux based phones and tablets.

    A problem now a days is, that Linux has a small desktop userbase, and even that base is fragmented into countless variations. This makes it hard to convince e.g. the local Metro train company, or bank to develop a Linux app, and if they do, they tend to only target large userbase Linux distros like Fedora or Ubuntu.
    A stable SDK and API that potentially works across all Linux distros will make it much more attractive for third party developers.

    This kind of sandboxing will of course also be of great use for normal programs: as it is now, a browser can read/write everywhere the user can, even do it without user permission too. This is bad when a browser gets compromised, since it can steal information or plant a trojan or similar.
    When sandboxed the browser may be limited to certain directories and if it wants to read a file, it doesn't do it directly, but will have to ask the "Portal" to fetch it, ensuring that the user can give it permission or deny the request.
    That last part sounds like an amazing use case. That does sound a lot like Android's content providers (which makes use of Android Intents).

    Though that makes me wonder; can Javascript apps like Dropbox and Gmail actually read my files at any given moment, or just the ones I chose using the file chooser?

    Thanks for the anwsers justmy2cents and interested.

  5. #25
    Join Date
    Oct 2013
    Posts
    416

    Default

    Quote Originally Posted by CTown View Post
    That makes a lot of sense. So, system wide apps get installed through the package manager to somewhere on / and sandboxed apps go to /home. However, will these sandboxed apps get to make any use of the system-wide installed libraries?
    Could it be made so Gnome's libraries and KDE's Frameworks (which always come with an explicit minimum version of Qt that can be used) be made the SDK? Sort of how the Free Desktop Standards expects Qt and GTK to both be parts of the "Free Desktop" (which is what we all should refer to these desktops collectivitly, it's why the standard is there). This way, each sandboxed app does not have to include all of these libraries AND these important libraries will be sandbox ready.
    at least as far as i get it. yes,... and... no. if you watch that video link, he mentions how you select target. so, if i selected target like fedora 20, then probably yes. but, if i selected centos5, then it would bundle all libraries needed which means app wouldn't use the ones in system.

    i could also imagine that one could make utility that would strip original sandbox like you ask. don't know that for sure, pure guess

    ahh, and i did one mistake when saying you never need any special SDK. if you have completely locked down sandbox, then you need special SDK. watch the part where it explains how app would access file. except, that isn't some library with its API like usual, but rather known IPC provider for that feature. video is really worth watching, explains whole lot
    Last edited by justmy2cents; 06-17-2014 at 09:33 PM.

  6. #26
    Join Date
    Mar 2013
    Posts
    269

    Default

    Quote Originally Posted by justmy2cents View Post
    what is there to defend against? poster is obviously still in 1985 and way to scared to proceed to reality
    It's because the reality where people believe that utter s..t like systemd can be useful is pretty scary...

  7. #27
    Join Date
    Mar 2013
    Posts
    269

    Default

    Quote Originally Posted by pouar View Post
    That's much worse
    Not according to Phoronix readers. See how excited everyone is?

  8. #28
    Join Date
    Oct 2013
    Posts
    416

    Default

    Quote Originally Posted by prodigy_ View Post
    It's because the reality where people believe that utter s..t like systemd can be useful is pretty scary...
    and here you are wearing your big boy pants and defying the all the horror of reality... all this just to enlighten us. ok, you did your best, even if attempt was at best... lame, useless, well.. whatever, even as trolling it was subpar

    now you can take off the bbpants and return to land of sysv, rainbows and unicorns where it is safe

  9. #29
    Join Date
    Dec 2012
    Posts
    459

    Default

    Cool, we might end up with systemd using SecureBoot to do the same thing Windows is doing.

    Eventually there could be cool sticker involved too .

  10. #30
    Join Date
    Jan 2009
    Location
    Outthere, NSW, Australia
    Posts
    402

    Default

    Quote Originally Posted by justmy2cents View Post
    and here you are wearing your big boy pants and defying the all the horror of reality... all this just to enlighten us. ok, you did your best, even if attempt was at best... lame, useless, well.. whatever, even as trolling it was subpar

    now you can take off the bbpants and return to land of sysv, rainbows and unicorns where it is safe
    Is this guy BO$$? Or just another angry wet mop?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •