|
Suspicious Dish posted:here's the source code so far: https://github.com/alexlarsson/xdg-app/ this looks like a much more complicated attempt to solve the same problems NeXT solved around the time you were born. NeXT had no significant "distro" differences to paper over, of course. they had only a couple iterations of their API before it settled down with OpenStep in 1993. if Ubuntu and Fedora tomorrow said "we're only shipping GNOME 3 from this coming version on," they could achieve something similar (but suckier). they did version their APIs while there was some churn, of course, that's why AppKit and Foundation are in "Versions/C" in their respective bundles now (and there was also libappkit.dylib way back when). they've been at those versions since 1993 though, and iOS uses shallow bundles as this kind of versioning winds up not really being needed. on the other hand if this takes off I expect the typical Linux system in a few years to have org.gnome.platform-x86_64-3.14 and 3.15 and 3.16 and 4.1 and… not to mention all the KDE this and Xt that which comes from not aggressively saying no. this is not a good solution. basically what you're calling "a runtime" is the job of the drat operating system. also, the entire structure is orthogonal to sandboxing; a sandboxed app really just needs a kernel that will actually enforce some fine-grained access control policies and a way to extend the app's rights based on user actions. oh, and reasonable kernel-supported IPC so system services (like those that extend an app's rights) can be implemented via daemons that can reliably check caller authorization. same for development and update; these problems were solved long ago, you just quit and replace an app to update it, you just shut down services and put files in place to update the OS and its frameworks, etc. but as I expected, nobody in the Linux world really wants to make the truly hard policy decisions ("What application-level API do we want to support? What do the controls look like?") so instead they invent all sorts of complicated mechanisms instead under the theory that a thousand flowers will bloom. what they'll get instead is yet another tangled mass of weeds.
|
#
?
Mar 20, 2015 05:05
|
|
|
|
| # ? Jun 5, 2024 00:10 |
|
|
eschaton posted:same for development and update; these problems were solved long ago, you just quit and replace an app to update it, you just shut down services and put files in place to update the OS and its frameworks, etc. this is of course the wrong solution, the correct way to update apps is to install the new version, tell any current instances of the old version to serialize their current state, terminate them, and then start the new version of the app and tell it to deserialize the preserved state, and finally delete the old version bonus points if you wait until the user won't notice that their app is being restarted, balancing user inconvenience against active security threats
|
|
#
?
Mar 20, 2015 05:20
|
|
|
So you're saying "if you ignore all of the technically and socially and politically hard problems of our situation, all of this is unnecessary". The reason that this whole project exists is because it hasn't worked that way. Yes, it's a frustrating situation, but it's the one that exists, and we have to make the best of it. We can't make a claim to eliminate all distros, because the way that the Linux community has built out has been a distro model. Trying to tear down that would only backfire. We're working to make the distro irrelevant, not trying to destroy it from the outset. And we need to do that to grow the platform, because distro differences are frustrating for application developers. Distros handling the packaging of all software is a frustrating problem that cannot scale to a size we want to be at. So, we need technical and political leverage to make the distro irrelevant, while giving developers a baseline to target to. NeXT's bundle system doesn't answer security updates (what happens when an application bundles an old copy of SQLite?). No, upgrading an application isn't as simple as shutting down the application. You first need to make sure that application components are separated from system components in order to do that, and actually, that you can identify processes belonging to an application, and shut them down in a safe manner. An application might also extend system components (e.g. extending a keyboard). Your sandboxing solution is technically vague and fundamentally insecure from a user experience level. (Vista-style UAC, counterintuitively, helped attacks more than it stopped because users got trained to clicking "Yes" to prompts to stop their applications from breaking). You can't simply ask the user if an app wants to access your files after it's already made the request in an SELinux-style fashion: we know from past experience that users find their apps break, and then just turn the drat system breaking their apps off. You need new API primitives and higher-level concepts that provide context, not fine-grained control. Yes, we're writing those, and having sandboxxed several applications already, I have a good structure of what kinds of things we want. We're pushing hard to get get a kernel-level IPC system that, at a base level, is unspoofable, but the pushback from the community should show you how difficult it is to introduce something in that area without upsetting our community. Automated distribution, deployment and version management is difficult to get right without breaking. Ask anybody who has tried to write such a system.
|
|
#
?
Mar 20, 2015 05:24
|
|
|
Suspicious Dish posted:So you're saying "if you ignore all of the technically and socially and politically hard problems of our situation, all of this is unnecessary". The reason that this whole project exists is because it hasn't worked that way. Yes, it's a frustrating situation, but it's the one that exists, and we have to make the best of it. and never ever try to change it, don't make any hard decisions and try to drive the platform forward. quote:NeXT's bundle system doesn't answer security updates (what happens when an application bundles an old copy of SQLite?). why is an app bundling SQLite in the first place, instead of using the version included with the operating system? apps bundling these sorts of things instead of using what the OS provides is part of the problem, and all you're going to do is ensure that users have org.sqlite-i386-3.9.12 and org.sqlite-i386-3.9.13 on their systems because some special snowflake must-have app will take a hard dependency on a specific version instead of whatever "sure, this time we promise binary compatibility, honest" token this system uses. (the answer is that if an app bundles something insecure, it's the app's security problem, not the operating system's. it's nice to try to make that more tractable, but a better way is for apps to be careful about the dependencies they take outside the OS. that requires a strong and stable idea of what the OS is of course.) quote:No, upgrading an application isn't as simple as shutting down the application. You first need to make sure that application components are separated from system components in order to do that, and actually, that you can identify processes belonging to an application, and shut them down in a safe manner. An application might also extend system components (e.g. extending a keyboard). yes, and while shutting down an app and relaunching it isn't an easy problem, it is much easier when you're willing to draw a line around what represents "the operating system" and what it even means to be "an app." which this proposal doesn't really seem to do. does this system try to work around this by saying "process 12345's controlling executable lives inside this container, therefore it's an app" or something? as another poster said, the best thing for app update would be to serialize an app's state, shut it down (and any of its extensions), replace it, bring it back up and restore its state, and do this invisibly to the user. this is only really possible if you have a strong concept of what an "app" even is. (like, say, OS X and iOS do.) quote:Your sandboxing solution is technically vague and fundamentally insecure from a user experience level. (Vista-style UAC, counterintuitively, helped attacks more than it stopped because users got trained to clicking "Yes" to prompts to stop their applications from breaking). You can't simply ask the user if an app wants to access your files after it's already made the request I was intentionally short in my response because I didn't want to elaborate on the whole powerbox model, which is actually a pretty good model for extension of rights to sandboxed apps to provide them the access the user has said they need (and no more). if you've done your job right as an OS vendor, you don't necessarily need new primitives either; your "open file" panel and your "user double-clicked something in the file manager" IPC mechanisms don't need to change to handle interposition of a powerbox or providing sandbox extensions. quote:Yes, we're writing those, and having sandboxxed several applications already, I have a good structure of what kinds of things we want. some people have worked on operating systems that have had app sandboxing for the better part of a decade, and have millions of sandboxed apps in common use.
|
|
#
?
Mar 20, 2015 06:03
|
|
|
Happy Belated Birthday, thread! One year of linux-talk. Let's keep at it and bring Linux to every desktop! (linux smartphones on the desk is about as far as it'll go)
|
|
#
?
Mar 20, 2015 09:17
|
|
|
eschaton posted:why is an app bundling SQLite in the first place, instead of using the version included with the operating system? your second paragraph here is exactly right, and obviates the first one. "bundles SQLite" is an implementation artifact that should be opaque to the OS's packaging system. it should be treated the same as the app author having implemented SQL by hand: if the app has a security issue then the app gets updated to fix it.
|
|
#
?
Mar 20, 2015 14:29
|
|
|
Suspicious Dish posted:here's the source code so far: https://github.com/alexlarsson/xdg-app/ how the gently caress do i patch anything when every app bundles its own runtime? (steam is one of the worst offenders on this; they've been shipping a known-bad version of sdl since day one, and it remains broken today. it's up to the user to manually replace it)
|
|
#
?
Mar 20, 2015 16:24
|
|
|
Subjunctive posted:your second paragraph here is exactly right, and obviates the first one. "bundles SQLite" is an implementation artifact that should be opaque to the OS's packaging system. it should be treated the same as the app author having implemented SQL by hand: if the app has a security issue then the app gets updated to fix it. because this model works so well on windows and osx adobe update manager for linux oracle java updater for linux oh boy this will be great
|
|
#
?
Mar 20, 2015 16:25
|
|
|
Notorious b.s.d. posted:how the gently caress do i patch anything when every app bundles its own runtime? How the gently caress do I patch anything when 20 applications are linked to the same library and updating breaks half of them ?
|
|
#
?
Mar 20, 2015 16:25
|
|
|
jre posted:How the gently caress do I patch anything when 20 applications are linked to the same library and updating breaks half of them ? red hat takes care of that for you they guarantee a stable api/abi and insulate you from upstream's retarded bullshit
|
|
#
?
Mar 20, 2015 16:26
|
|
|
no one is going to use this sand boxing poo poo
|
|
#
?
Mar 20, 2015 16:27
|
|
|
Notorious b.s.d. posted:red hat takes care of that for you No, we don't.
|
|
#
?
Mar 20, 2015 16:31
|
|
|
Suspicious Dish posted:No, we don't. Red Hat posted:One of the core goals of the Red Hat Enterprise Linux family of products is to provide a stable, consistent runtime environment for thirdparty applications. To support this goal, Red Hat seeks to preserve application binary compatibility, configuration file compatibility, and data file compatibility for all package updates issued within a major release. For example, a package update from Red Hat Enterprise Linux 6.1 to Red Hat Enterprise Linux 6.2, or a package update that fixes an identified security vulnerability, should not break the functionality of deployed applications as long as they adhere to standard Application Binary Interfaces (ABIs).
|
|
#
?
Mar 20, 2015 16:33
|
|
|
Notorious b.s.d. posted:red hat takes care of that for you What if I want to use things that aren't in the extremely limited Redhat repos ?
|
|
#
?
Mar 20, 2015 16:37
|
|
|
jre posted:What if I want to use things that aren't in the extremely limited Redhat repos ? don't if it's not in debian's official apt pools I don't install it
|
|
#
?
Mar 20, 2015 16:39
|
|
|
jre posted:What if I want to use things that aren't in the extremely limited Redhat repos ? if you download source code and build it yourself, congratulations, you're maintaining a new internal application.
|
|
#
?
Mar 20, 2015 16:41
|
|
|
the key word is "should". you severely overestimate the level of professionalism in that goes into making rhel.
|
|
#
?
Mar 20, 2015 16:42
|
|
|
Suspicious Dish posted:the key word is "should". you severely overestimate the level of professionalism in that goes into making rhel. should, as in, when something is broken by an update, i can file a support ticket and point the finger at the vendor. (this has happened to me twice, ever, in rhel. and once the bug was in yum itself) it doesn't pay to overestimate professionalism in information technology. 9/10ths of it is about finger-pointing
|
|
#
?
Mar 20, 2015 16:43
|
|
|
Notorious b.s.d. posted:then you're on your own, just like any other stupid thing you build from source Who said build from source ? What if you install from EPEL or similar? Can you imagine if someone was suggesting only installing software packaged directly from Microsoft?
|
|
#
?
Mar 20, 2015 16:45
|
|
|
Suspicious Dish posted:the key word is "should". you severely overestimate the level of professionalism in that goes into making rhel. yet still orders of magnitude higher than letting upstream handle it
|
|
#
?
Mar 20, 2015 16:45
|
|
|
jre posted:Who said build from source ? What if you install from EPEL or similar? if microsoft somehow offered a service that stripped malware from installers and made sure some sensible defaults were set and allowed all software to safely and uniformly handle interdependencies you bet your loving rear end I'd be on that like white on rice and eliminate all usage of any other downloading or distribution source case in point: microsoft bundled flash because gently caress letting adobe software updater handle it
|
|
#
?
Mar 20, 2015 16:46
|
|
|
jre posted:Who said build from source ? What if you install from EPEL or similar? getting binaries from third parties implies trusting third parties to distribute your security updates without breaking your poo poo the only 3rd party binaries on my linux desktop are firefox, chrome, and steam. i trust two of the three to update things promptly. the third one shits in my face but hey what are you going to do i wouldn't trust epel if i were you jre posted:Can you imagine if someone was suggesting only installing software packaged directly from Microsoft? i would not choose to run anything 3rd party on windows literally the only reasons i can imagine deploying a windows host:
yes, it's a short list. edit: and i would be delighted if all these things came through windows update instead of me having to gently caress with vs.net's lovely installer/updater Notorious b.s.d. fucked around with this message at 16:52 on Mar 20, 2015 |
|
#
?
Mar 20, 2015 16:49
|
|
|
Notorious b.s.d. posted:it doesn't pay to overestimate professionalism in information technology. i thought you had a job, though?
|
|
#
?
Mar 20, 2015 16:59
|
|
|
Notorious b.s.d. posted:getting binaries from third parties implies trusting third parties to distribute your security updates without breaking your poo poo 
|
|
#
?
Mar 20, 2015 17:05
|
|
|
did you expect me to say, "sure, it's a great and wonderful idea to install random 3rd party binaries on windows"
|
|
#
?
Mar 20, 2015 18:08
|
|
|
Could someone tell a joke please? I've forgotten which forums Linux thread I'm in.
|
|
#
?
Mar 20, 2015 18:10
|
|
|
the joke is installing ubuntu
|
|
#
?
Mar 20, 2015 18:14
|
|
|
SYSV Fanfic posted:Could someone tell a joke please? I've forgotten which forums Linux thread I'm in. eric s raymond
|
|
#
?
Mar 20, 2015 18:14
|
|
|
the punchline is "it sucks"
|
|
#
?
Mar 20, 2015 18:14
|
|
|
|
|
#
?
Mar 20, 2015 18:17
|
|
|
Notorious b.s.d. is weirder than I thought
|
|
#
?
Mar 20, 2015 18:57
|
|
|
Ubuntu continues to work fine for me. You guys must be bad at linux.
|
|
#
?
Mar 20, 2015 19:05
|
|
|
SYSV Fanfic posted:Ubuntu continues to work fine for me. You guys must be bad at linux. non canon
|
|
#
?
Mar 20, 2015 19:21
|
|
|
SYSV Fanfic posted:Ubuntu continues to work fine for me. You guys must be bad at linux. i used it to bulk-set repeater presets on my amateur radio yesterday
|
|
#
?
Mar 20, 2015 19:36
|
|
|
i use it to do assignments that hinge on ancient versions of java, a job it is currently failing at because the servers I need to run a trivial program on keep falling over
|
|
#
?
Mar 20, 2015 19:59
|
|
|
The short list of operating systems where when you install something (like a package containing a server program), it doesn't automatically start it, and it especially doesn't make it start on every boot forever: Fedora OpenBSD What can we learn from this list? That there are very few good operating systems. Seriously, why the gently caress does Debian assume that just because I install buttd, I want to run it immediately with the default configuration, and on every subsequent boot? It doesn't loving do that for non-server programs, now does it?
|
|
#
?
Mar 20, 2015 20:04
|
|
|
Athas posted:What can we learn from this list? That there are very few good operating systems. Seriously, why the gently caress does Debian assume that just because I install buttd, I want to run it immediately with the default configuration, and on every subsequent boot? It doesn't loving do that for non-server programs, now does it? debian doesn't start daemons at install time i just tried it myself. installed apache2, daemon was not started. it is configured to start on boot, but that's good.
|
|
#
?
Mar 20, 2015 20:07
|
|
|
Athas posted:It doesn't loving do that for non-server programs, now does it? how dumb is this motherfucker
|
|
#
?
Mar 20, 2015 20:13
|
|
|
lol
|
|
#
?
Mar 20, 2015 20:16
|
|
|
|
| # ? Jun 5, 2024 00:10 |
|
|
i'm the server program wait no im the non-server program
|
|
#
?
Mar 20, 2015 20:19
|
|
