This is possible for servers, which do only a few jobs repeatedly, but for a desktop machine with hundreds of potential applications to fire up and more being developed such a burden becomes huge... I would be really happy to see this happen - various distributions collaborate on default rules for large numbers of applications, so end users could actually use systems that are seriously hardened
No, the solution for SELinux is for the application developers themselves to write policy.
Last time I discussed this with the guys on #selinux, they appeared to think that being non-experts, "regular" developers could not write SELinux policy. I think this is the wrong way to go for several reasons:
Attempting to maintain policy centrally for desktop systems is going to be a disaster - the policy will always be out of date or wrong because no matter how much testing they do, the policy maintainers cannot know every operation the program may wish to take. Current testing seems rather basic - does it start? If I play with it for a few minutes, does anything appear obviously broken? etc etc. Software that breaks in mysterious ways will be the result. Only the developers of the software can write accurate policy IMHO - this opinion is in direct contrast to some of the current SELinux developers however.
You'll have the same mess people have with broken and out of date packages in fact.
Most apps won't have any policy at all
If SELinux policy is so convoluted that you need tons of training in order to write it, it's pretty much doomed as a system we can use globally outside of niche "appliance" scenarios.
Fortunately it's possible to install policy within packages like any other data file. So it just requires good community training, like anything else. When FC3 comes out with a basic SELinux implementation active by default I'd expect to see people play with it a lot more.
Sometimes people get confused - SELinux isn't about preventing malware/spyware type stuff, though theoretically you could use it to help quarantine "alien" programs. It's about giving programs the least priviledge necessary to do their job, so if they are compromised (buffer overflowed etc) somehow, the damage that can be done is limited. It's a defence mechanism.
It's called Helix Player these days, and is a spiffy GTK2 app. You know, that actually feels native and stuff.
The Helix framework IMHO isn't competitive with the GStreamer framework for a whole bunch of reasons, some technical and some licensing based however it is powerful and the Helix player is a nice piece of work.
So what suggestions can Slashdot readers make about how a company (real in particular) goes about regaining that lost trust?
Pretty much what you're doing here, really. Talking direct from employees to customers, doing impressively straight talking interviews like this one, making products that are actually quite good.
It'll take time but I honestly can't think of what else you'd want to do. You guys seem to not only be talking the talk but also walking the walk. Just keep it up!:)
It would be a lot easier to rewrite the libraries in a safe language without pointers, like Java.
No, I'm not joking. Using gcj and some fancy tricks you can compile Java to a C-ABI exporting native library.
Or start doing what Microsoft are doing with SP2 and use a compiler with bounds checking canaries. There are patches to do this for gcc but I don't know why they aren't more widely used.
Indeed. Even if you hack this feature out of glibc (be warned: rebuilding glibc is really hard) it's still possible to write an ELF interpreter in, say, Python or Perl. In fact if you can compromise or overflow *any* program on the system you can perform what's called a userland exec, in which you reload the program with a new binary without using the exec() syscall. That includes attaching to it with a debugger.
Basically, if you can run any code at all via Python or similar scripting languages which allow direct calls to C, or overflow any program running, you can execute any program you like from a noexec mount. noexec is convenient to restrict those who aren't really hard core hackers, but it's not a foolproof security mechanism.
Hmm, this works for you? I don't know what I'm doing wrong, but Firefox auto-update has never worked for me in any capacity. For instance I've tried going somewhere with Flash content, and it just tells me that no suitable plugins were found. What's up with that?
Says who? Based on what evidence? I pirated it, saw that it sucked, and then did exactly what I would have done anyway; I didn't buy it.
That has to be the most pathetic way of justifying crime I've seen for a long time. I bought Black&White, played it for a while, and decided that it didn't have good gameplay. Nonetheless, I had still evaluated it based on a demo (the *right* way to evaluate software), paid for it, and then abandoned it. I made a duff decision, my loss. That doesn't mean I had the "right" to pirate their game.
The piracy problem boils down to mass amorality. It's easy to do something wrong when everybody else is doing it.
That's incorrect. The ABI is versioned such that this won't work. Also the MIPS and SPARC ABI changed for C not C++, as the C++ ABI also changed on x86. ABI changes always cause breakage in your code if you rely on C++ libraries, regardless of what features you use, because they're versioned.
Were the internet a safe place, I'd almost agree with you. Almost.
Requiring the root password for certain tasks does not increase security, IMHO. Most users (a) don't want to be constantly typing in passwords and (b) would type it in whenever it was asked for without thinking too hard about it.
If anything you don't want the typical personal-PC one-user setup to ask for the root password very often because the more often you ask when it's not really needed, the greater "password fatigue" gets and the less likely people are to think critically when they get asked.
Really, if you spend a lot of time thinking about it as I have, you come to the realisation that malware which relies on social engineering doesn't have any useful technical solutions. You can get some way there with things like distributed whitelists but pretty quickly you end up in the realm of civil liberties (who really owns that machine you paid for?).
In short: making tasks hard doesn't increase security, it just annoys the user. If the user has decided they want to do something, they'll do it. So good security in the face of a dangerous net is about advising the user well whilst not getting in their way.
Now, I know you're coming from the viewpoint of a server admin which is fine. Most people aren't server admins. It's wrong to try and apply the tools used to admin servers to home machines.
That's one reason why autopackage can install to home directories. (see the third screenshot), though it's not really something that's encouraged (and it can be disabled by administrators). Another is because it's really useful if you want to use a newer/older version of the software installed on a multi-user machine without interfering with other users. Another is because some shell accounts do let you run programs and it's nice to be able to use binaries.
In fact, in all my production systems, home is ALWAYS mounted as noexec. You want a program on the server, fine, you let me know which one and why, and I'll think about it.
That doesn't help very much, you can still run programs on a no-exec mount if you really want to.
I don't think you're wrong. In fact, this is the same conclusion I came to myself a few months ago. The only way driver management on Linux is going to become easy is if a fully stable binary interface is provided to drivers and people take steps to avoid breaking backwards compat. That in turn requires a fork of the stable series and backporting of patches which don't break things.
Doing so requires manpower and willpower that doesn't currently exist though, I think...
Because drivers for stuff are avalible noone have interest in maintaining open drivers. Linux becomes as encombered as windows when you want to do anthing with it besides desktop PC
This really doesn't happen with the problem devices anyway. Reverse engineering modern video cards/wifi cards etc is really, really hard and usually never happens. Even when specs are released, that doesn't mean a driver will be written. There are cards that still have no open source driver but for which docs are available. Typically video drivers only get written when the manufacturer contracts somebody to write one.
Linus made the right call to not stabilize the ABI and force vendors to either make open drivers or at least have to put up with a wrapper.
It's the users that suffer, not the developers. Linux is still so small that they can totally ignore it and make money nonetheless.
No, he wants it to work the same way it works on Windows and MacOS, where the developers of the software provide binary packages that work on all Linuxes. It's certainly possible to do.
OK, I admit the last time I checked was a long time ago. It's possible that Gentoo have forked it though, they modify software all the time in their ebuilds.
Linus and RMS have never said "binary compatibility is a minus". RMS is a-ok with binaries, in fact IIRC he uses Debian or some derivative thereof. Linus takes pains to maintain the userland syscall interface.
Binaries are just a lot more convenient than source, and they're a lot more convenient when not done centrally as they actually tend to exist, be usable etc.
Static linking isn't just about disk space. It's also about net bandwidth and most crucially memory pressure. The whole point of using shared libraries is that it makes things like complex GUI environments possible in sensible amounts of RAM.
I can guarantee you that if every program on a standard Fedora/GNOME or SuSE/KDE desktop was statically link you would not be able to run it on any reasonable system without decending into swap hell within a few seconds (probably even before that). Not even if you have a gig of RAM.
No, it would be all libraries in a different place so that they don't conflict with each other, every. The hardlinking would just be a way to keep the disk usage down, nothing more.
That doesn't solve the problem of somebody who released a library upgrade thinking it didn't break stuff, but that actually did.
Actually the main problem with making distro neutral packages is the lack of platform stability. In fact there isn't really a platform to speak of. The library your program needs will often not be there, or will be there but not in the right version. Dependency resolution gets you some way but doesn't solve the underlying problem, namely that popular libraries break backwards compatibility all the time.
The second biggest problem is that of binary portability.
Where files and such are put isn't actually that big a problem. I know that's what it looks like at first, I thought the same thing. But in practice, it's really not a problem.
How do I know these things? Because for the last two years I've been working on a distribution neutral packaging format, that installs anywhere and is easy to use. Go check out the screenshots! There are demo packages you can use as well, like the Inkscape CVS nightly builds. Be warned, I think the Zile package isn't working quite right yet.
Autopackage really needs more people working on it. Right now all the 3 main developers are in a time crunch and it's slowed right down to a crawl. If you want to see easy 1 click installs on Linux (easier than apt-get even for newbies...) why not come on over and help out?
b) Go read LinuxQuestions.org (or any newbie forum) for a while. Installing software is still one of the top 3 problems people consistently have. Even on distros that have "dependency checking" like Debian, Fedora etc.
c) Worse is the newbies who trusting in their packagers encounter problems then immediately blame the software, when they have in fact got broken packages.
That's exactly the same thing as having all the shared libraries in the same place, isn't it?
The problems with shared libraries boil down to exactly two things:
Most DSO authors don't understand how to avoid breaking software when they change the code. If they do, they assume the versioning mechanisms they have available give them a free license to break backwards compat whenever they feel like it.
There is no such thing as the Linux platform, not yet. Linux is still making the transition away from "a random collection of software that happens to work together" (ie a distribution) towards a platform that 3rd parties can build upon.
The first means that if you do get a binary from somewhere, chances are it'll be missing a library it needs. Why? Because rather than add a foo_func2() function, the library author added a parameter to foo_func() and broke backwards compatibility. Because they modified the size of a struct that the app wasn't even using anyway. Because the library has a ludicrously fast release cycle and provides new versions every 5 minutes.
The second means there's no baseline which people can target. Instead people scout around, find a library which looks good and use it, only to discover that said library isn't actually packaged anywhere or breaks backwards compatibility every five minutes so the packages which do exist are always of a too new or too old version.
The problems are worsened considerably by the "not my problem" attitude which means free software authors typically say "I provide the source! It's your distributions job to make it easy to install!" which is a totally bogus attitude, and one that not having distributions MacOS and Windows don't suffer at all.
SymphonyOS doesn't have this problem because nobody uses it and it has only toy applications. There's no such thing as a distro there.
None of the above problems can be solved with fancy linker/package manager tricks I'm afraid. It requires a developer education push similar to the usability push GNOME started a few years ago. So there's no quick fix, sorry.
Quite a lot of manpages are awful. The man page for tar does not give you the "tar xzvf" magic invocation to extra.tar.gz files, despite this being the most common task newbies use it for. The man page for sudo attempts to teach you BNF notation instead of simply telling you how to allow a user to access root using their own password.
There are also some really great man pages. But it's hardly a consistently useful resource.
Firstly the linker knows nothing about minor versions unless you apply symbol versioning, which almost nobody does. So it's all too easy to have a program accidentally linked against an older version than what it really needs. Because symbols are lazy linked, this means you can work for an hour, hit the save button and have the app abort with an undefined relocation.
Secondly, it requires shared library authors to actually understand and give a toss about backwards compatibility. Virtually none do - the best, most shining examples in our community maintain ABI compatibility but do not version headers nor preserve semantic compatibility, which can break apps in even more nasty ways than just crashes.
Thirdly, due to the ELF fixup rules, if you get two incompatible versions of the same library linked into the same process image (because the program uses.so.2 and some other library it uses in turn relies on.so.3) things go boom pretty messily. This has happened to at least libpng in the past and broke things like Opera who nowadays statically link it.
The libfoo.so symlink tells ld which version to default to using when compiling new binaries with a "-lfoo" on the link command line.
Which means it's really hard to compile software which needs one version, then immediately afterwards compile software that needs another version. Parallel installable libraries help with this, a bit.
The problem with the apt-get approach is that it's like living in a town with only one supermarket. OK, so it's a really big supermarket but still:
- If you can't find the food you want in there, you're stuck
- If you can but it's stale, damaged or out of stock, you're stuck
- You are totally dependent on the people running the supermarket
- The larger a supermarket is, the harder it becomes to find things in it. Just imagine taking your grandma to a supermarket where the aisles stretched as far as the eye could see!
To stretch the analogy a bit further than it can really go, just imagine if getting tired of this one supermarket you travelled to the next town and bought a lampshade from a shop there. Bring it all the way back, put it in your house and suddenly your TV explodes.
What happened? "Oh, you mixed different repositories". All centralised systems suffer this but Fedora worse than most - you're fine as long as you stick to the core repositories but if you add others (and you do need to do that, if you want a big enough collection to be useful) things will randomly break due to "conflicts". Just imagine trying to explain that to grandma!
Oh yeah. There are a bunch of other problems as well. I've seen a lot of 3rd party packages of software that are totally broken. Often the users don't connect the problems they are seeing with the packages. This happens a lot with complex software like Wine, Mono etc... I've seen quite a few packages of Wine that won't even start! It's pretty clear that many 3rd party packagers hardly test what they produce at all, especially in the case of "new release, I'll just bump the number in the spec and rebuild". I'd estimate that about 40-50% of the tech support problems I deal with in Wine are due to incorrectly built packages. It's not even hard! Just configure, make, make install but people still cock it up mightily - using badly done wrapper scripts and moving files around from where they're supposed to be are the most common, but bad builds happen too.
Apt-get has other problems. You have to duplicate this huge effort over and over again for each distro. This doesn't happen so you get vendor lockin - the very thing we're trying to all get away from, no? I've met more than one person in my life whos number 1 reason for using Debian was "I can apt get lots of software". It was not due to the merits of the distribution itself, it was not due to have a nice installer, slick default desktop, solid PAM setup etc etc. It was because installing software was not a pain in the ass.
Apt-get works great as long as you are willing to throw infinite manpower at the problem. We don't have infinite manpower, duh. So centralised packaging cannot be a scalable, sustainable way forward for our community outside of certain use cases like servers (where it works well).
Slashdot Mirror
No, the solution for SELinux is for the application developers themselves to write policy.
Last time I discussed this with the guys on #selinux, they appeared to think that being non-experts, "regular" developers could not write SELinux policy. I think this is the wrong way to go for several reasons:
You'll have the same mess people have with broken and out of date packages in fact.
Fortunately it's possible to install policy within packages like any other data file. So it just requires good community training, like anything else. When FC3 comes out with a basic SELinux implementation active by default I'd expect to see people play with it a lot more.
Sometimes people get confused - SELinux isn't about preventing malware/spyware type stuff, though theoretically you could use it to help quarantine "alien" programs. It's about giving programs the least priviledge necessary to do their job, so if they are compromised (buffer overflowed etc) somehow, the damage that can be done is limited. It's a defence mechanism.
The Helix framework IMHO isn't competitive with the GStreamer framework for a whole bunch of reasons, some technical and some licensing based however it is powerful and the Helix player is a nice piece of work.
Pretty much what you're doing here, really. Talking direct from employees to customers, doing impressively straight talking interviews like this one, making products that are actually quite good.
It'll take time but I honestly can't think of what else you'd want to do. You guys seem to not only be talking the talk but also walking the walk. Just keep it up! :)
No, I'm not joking. Using gcj and some fancy tricks you can compile Java to a C-ABI exporting native library.
Or start doing what Microsoft are doing with SP2 and use a compiler with bounds checking canaries. There are patches to do this for gcc but I don't know why they aren't more widely used.
He's talking about ProPolice type compiler guards, not exec-shield type runtime guards.
Basically, if you can run any code at all via Python or similar scripting languages which allow direct calls to C, or overflow any program running, you can execute any program you like from a noexec mount. noexec is convenient to restrict those who aren't really hard core hackers, but it's not a foolproof security mechanism.
Hmm, this works for you? I don't know what I'm doing wrong, but Firefox auto-update has never worked for me in any capacity. For instance I've tried going somewhere with Flash content, and it just tells me that no suitable plugins were found. What's up with that?
That has to be the most pathetic way of justifying crime I've seen for a long time. I bought Black&White, played it for a while, and decided that it didn't have good gameplay. Nonetheless, I had still evaluated it based on a demo (the *right* way to evaluate software), paid for it, and then abandoned it. I made a duff decision, my loss. That doesn't mean I had the "right" to pirate their game.
The piracy problem boils down to mass amorality. It's easy to do something wrong when everybody else is doing it.
That's incorrect. The ABI is versioned such that this won't work. Also the MIPS and SPARC ABI changed for C not C++, as the C++ ABI also changed on x86. ABI changes always cause breakage in your code if you rely on C++ libraries, regardless of what features you use, because they're versioned.
If you think that's clever I guess you never heard of Phatbot.
Not that there's anything clever about writing these sorts of viruses, though.
Requiring the root password for certain tasks does not increase security, IMHO. Most users (a) don't want to be constantly typing in passwords and (b) would type it in whenever it was asked for without thinking too hard about it.
If anything you don't want the typical personal-PC one-user setup to ask for the root password very often because the more often you ask when it's not really needed, the greater "password fatigue" gets and the less likely people are to think critically when they get asked.
Really, if you spend a lot of time thinking about it as I have, you come to the realisation that malware which relies on social engineering doesn't have any useful technical solutions. You can get some way there with things like distributed whitelists but pretty quickly you end up in the realm of civil liberties (who really owns that machine you paid for?).
In short: making tasks hard doesn't increase security, it just annoys the user. If the user has decided they want to do something, they'll do it. So good security in the face of a dangerous net is about advising the user well whilst not getting in their way.
Now, I know you're coming from the viewpoint of a server admin which is fine. Most people aren't server admins. It's wrong to try and apply the tools used to admin servers to home machines.
That's one reason why autopackage can install to home directories. (see the third screenshot), though it's not really something that's encouraged (and it can be disabled by administrators). Another is because it's really useful if you want to use a newer/older version of the software installed on a multi-user machine without interfering with other users. Another is because some shell accounts do let you run programs and it's nice to be able to use binaries.
In fact, in all my production systems, home is ALWAYS mounted as noexec. You want a program on the server, fine, you let me know which one and why, and I'll think about it.
That doesn't help very much, you can still run programs on a no-exec mount if you really want to.
Doing so requires manpower and willpower that doesn't currently exist though, I think ...
This really doesn't happen with the problem devices anyway. Reverse engineering modern video cards/wifi cards etc is really, really hard and usually never happens. Even when specs are released, that doesn't mean a driver will be written. There are cards that still have no open source driver but for which docs are available. Typically video drivers only get written when the manufacturer contracts somebody to write one.
Linus made the right call to not stabilize the ABI and force vendors to either make open drivers or at least have to put up with a wrapper.
It's the users that suffer, not the developers. Linux is still so small that they can totally ignore it and make money nonetheless.
No,you can do it with dep resolution as well. Look at autopackage. What's really needed is a unified base set/platform though.
Well, not really. The first 3 items can all break binaries but not source compiles ...
No, he wants it to work the same way it works on Windows and MacOS, where the developers of the software provide binary packages that work on all Linuxes. It's certainly possible to do.
OK, I admit the last time I checked was a long time ago. It's possible that Gentoo have forked it though, they modify software all the time in their ebuilds.
Binaries are just a lot more convenient than source, and they're a lot more convenient when not done centrally as they actually tend to exist, be usable etc.
I can guarantee you that if every program on a standard Fedora/GNOME or SuSE/KDE desktop was statically link you would not be able to run it on any reasonable system without decending into swap hell within a few seconds (probably even before that). Not even if you have a gig of RAM.
No, it would be all libraries in a different place so that they don't conflict with each other, every. The hardlinking would just be a way to keep the disk usage down, nothing more.
That doesn't solve the problem of somebody who released a library upgrade thinking it didn't break stuff, but that actually did.
The second biggest problem is that of binary portability.
Where files and such are put isn't actually that big a problem. I know that's what it looks like at first, I thought the same thing. But in practice, it's really not a problem.
How do I know these things? Because for the last two years I've been working on a distribution neutral packaging format, that installs anywhere and is easy to use. Go check out the screenshots! There are demo packages you can use as well, like the Inkscape CVS nightly builds. Be warned, I think the Zile package isn't working quite right yet.
Autopackage really needs more people working on it. Right now all the 3 main developers are in a time crunch and it's slowed right down to a crawl. If you want to see easy 1 click installs on Linux (easier than apt-get even for newbies ...) why not come on over and help out?
b) Go read LinuxQuestions.org (or any newbie forum) for a while. Installing software is still one of the top 3 problems people consistently have. Even on distros that have "dependency checking" like Debian, Fedora etc.
c) Worse is the newbies who trusting in their packagers encounter problems then immediately blame the software, when they have in fact got broken packages.
The problems with shared libraries boil down to exactly two things:
The first means that if you do get a binary from somewhere, chances are it'll be missing a library it needs. Why? Because rather than add a foo_func2() function, the library author added a parameter to foo_func() and broke backwards compatibility. Because they modified the size of a struct that the app wasn't even using anyway. Because the library has a ludicrously fast release cycle and provides new versions every 5 minutes.
The second means there's no baseline which people can target. Instead people scout around, find a library which looks good and use it, only to discover that said library isn't actually packaged anywhere or breaks backwards compatibility every five minutes so the packages which do exist are always of a too new or too old version.
The problems are worsened considerably by the "not my problem" attitude which means free software authors typically say "I provide the source! It's your distributions job to make it easy to install!" which is a totally bogus attitude, and one that not having distributions MacOS and Windows don't suffer at all.
SymphonyOS doesn't have this problem because nobody uses it and it has only toy applications. There's no such thing as a distro there.
None of the above problems can be solved with fancy linker/package manager tricks I'm afraid. It requires a developer education push similar to the usability push GNOME started a few years ago. So there's no quick fix, sorry.
There are also some really great man pages. But it's hardly a consistently useful resource.
Firstly the linker knows nothing about minor versions unless you apply symbol versioning, which almost nobody does. So it's all too easy to have a program accidentally linked against an older version than what it really needs. Because symbols are lazy linked, this means you can work for an hour, hit the save button and have the app abort with an undefined relocation.
Secondly, it requires shared library authors to actually understand and give a toss about backwards compatibility. Virtually none do - the best, most shining examples in our community maintain ABI compatibility but do not version headers nor preserve semantic compatibility, which can break apps in even more nasty ways than just crashes.
Thirdly, due to the ELF fixup rules, if you get two incompatible versions of the same library linked into the same process image (because the program uses .so.2 and some other library it uses in turn relies on .so.3) things go boom pretty messily. This has happened to at least libpng in the past and broke things like Opera who nowadays statically link it.
The libfoo.so symlink tells ld which version to default to using when compiling new binaries with a "-lfoo" on the link command line.
Which means it's really hard to compile software which needs one version, then immediately afterwards compile software that needs another version. Parallel installable libraries help with this, a bit.
The problem with the apt-get approach is that it's like living in a town with only one supermarket. OK, so it's a really big supermarket but still:
- If you can't find the food you want in there, you're stuck
- If you can but it's stale, damaged or out of stock, you're stuck
- You are totally dependent on the people running the supermarket
- The larger a supermarket is, the harder it becomes to find things in it. Just imagine taking your grandma to a supermarket where the aisles stretched as far as the eye could see!
To stretch the analogy a bit further than it can really go, just imagine if getting tired of this one supermarket you travelled to the next town and bought a lampshade from a shop there. Bring it all the way back, put it in your house and suddenly your TV explodes.
What happened? "Oh, you mixed different repositories". All centralised systems suffer this but Fedora worse than most - you're fine as long as you stick to the core repositories but if you add others (and you do need to do that, if you want a big enough collection to be useful) things will randomly break due to "conflicts". Just imagine trying to explain that to grandma!
Oh yeah. There are a bunch of other problems as well. I've seen a lot of 3rd party packages of software that are totally broken. Often the users don't connect the problems they are seeing with the packages. This happens a lot with complex software like Wine, Mono etc ... I've seen quite a few packages of Wine that won't even start! It's pretty clear that many 3rd party packagers hardly test what they produce at all, especially in the case of "new release, I'll just bump the number in the spec and rebuild". I'd estimate that about 40-50% of the tech support problems I deal with in Wine are due to incorrectly built packages. It's not even hard! Just configure, make, make install but people still cock it up mightily - using badly done wrapper scripts and moving files around from where they're supposed to be are the most common, but bad builds happen too.
Apt-get has other problems. You have to duplicate this huge effort over and over again for each distro. This doesn't happen so you get vendor lockin - the very thing we're trying to all get away from, no? I've met more than one person in my life whos number 1 reason for using Debian was "I can apt get lots of software". It was not due to the merits of the distribution itself, it was not due to have a nice installer, slick default desktop, solid PAM setup etc etc. It was because installing software was not a pain in the ass.
Apt-get works great as long as you are willing to throw infinite manpower at the problem. We don't have infinite manpower, duh. So centralised packaging cannot be a scalable, sustainable way forward for our community outside of certain use cases like servers (where it works well).