| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
 Posted: Thu Apr 09, 2015 3:34 pm Post subject: |
 |
|
| ulenrich wrote: | | Maybe there is a technique behind the curtain giving perfect security |
Once more: Adding security features to an inherently insecure system is pointless.
You cannot add security as a "feature" in an afterthought.
All these "personal firewalls/virus scanners/..." have proved this: By adding code in a system whose insecurity comes from the complexity, you effectively only add new attack vectors.
Indeed, it might safe you from a certain class of previously known attacks, and an average hacker with few resources might not see how to trick a certain limitation directly, but experience has shown that - due to the mere compexity of the underlying code - there is always dozens previously completely unthought new attack vectors introduced by some such "added" security.
Security - if you want it - must be the first and fundamental concept, and everything has to follow it. That's the only way how you get security. Unix had exactly this basis, policykit torpedoed it. |
|
| Back to top |
|
 |
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Thu Apr 09, 2015 4:20 pm Post subject: |
|
|
| mv wrote: | | If you want to offer this particular service you have to think about the exact policy (in which groups should such users be put, which shell will they get, which limitation on the number of users produced in such a way do you put etc) and you have to describe all the details of this poliy in some language. |
How about time of day when the program can be run? Does each of the thousands application in a typical Linux distro have to have one such file that defines all possible policies when the program will be run?
| Quote: | And again a completely wrong assertion. The difference in the maintainer's work between the sane (sudo - A) approach and the unsane (policykit - B) approach is:
A) You write a hand-crafted program/configuration in a language of your choice
B) You write a hand-crafted program/configuration with exactly all the same checks in the language of the policy daemon |
Programming language of choice has nothing to do with this. We're talking about an API that any language can have bindings for.
But I'll ask you again, how do you specify which time of day can a certain binary path be run, by which user? Does steam have a policy file in your or my language of choice, and how do I limit WHEN it can be run on a machine? |
|
| Back to top |
|
|
mrbassie
l33t
Joined: 31 May 2013
Posts: 772
Location: over here
|
| Posted: Thu Apr 09, 2015 4:59 pm Post subject: |
|
|
@GrueXYZ
(Not a loaded question, just want to clarify) are you referencing MS group policy? |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Thu Apr 09, 2015 6:30 pm Post subject: |
|
|
All of this stuff like allowing programs to only run by certain users at certain times or elevating specific processes to perform specific root level actions is all specialty stuff that doesn't need to be baked into the generic linux distribution.
In the case of time locking access, why not create a wrapper that can be configured if someone needs it but isn't even installed in the vast majority of cases? In the case of a hosting company running cpanel, why should their needs affect the default actions of the other 99% of installs that aren't running cpanel?
Where did we come up with the idea that one size MUST fit all and that every niche idea has to be included, regardless of how many people DON'T have any need for any of it? And by having all of this unnecessary and complex cruft lying around that "regular" users don't even know is there or know how to configure to their needs (or lack thereof), we're just creating a larger attack surface, which, in the case of tying all of this together in systemd, not only creates a much larger attack surface, but gives it potential root level access... and that is magnified even more by tying it together with dbus/kdbus.
The solution to niche needs, is niche modules that are optional and only installed for those that do need them. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Apr 09, 2015 9:43 pm Post subject: |
|
|
| saellaven wrote: | All of this stuff like allowing programs to only run by certain users at certain times or elevating specific processes to perform specific root level actions is all specialty stuff that doesn't need to be baked into the generic linux distribution.
Where did we come up with the idea that one size MUST fit all and that every niche idea has to be included, regardless of how many people DON'T have any need for any of it? |
It's a pretty common delusion to fall into; especially if your ego is bigger than your sense of craft, or you've simply never had the experience of building a monster and having to delete a load of cruft, and restart from scratch (along with the concomitant loss of face).
Sometimes it seems to me that the meme of "just push it, we'll patch it later" makes the latter an awful lot less likely. It's hard to rewrite from scratch when people are already using what you do, and thus you have an obligation to them (not to do a libav.)
"One size fits all" is simply One True Way thinking in effect. It only works for base concepts, like "everything's an fd", which are at ABI level, not at userland impl. The whole point of primitives is to accommodate different ways of thinking, with clean interaction between processes, each of which can conceptualise its part of the problem-space in the most effective manner.
Worrying about the efficiency of text is simply misplaced optimisation; unfortunately they've taken that as an axiom, and instead bottlenecked the entire system. Now they're hoping they can shove the problem onto the kernel coders instead; whatever happens it won't be their fault anymore, for having pushed such an awful userland design. Or at least that's how they're going to sell it.
The one thing they will not do, is admit that there is anything wrong with the design; as such they should just get a perma-NAK (ie never raise this again) on the whole idea.
| Quote: | | And by having all of this unnecessary and complex cruft lying around that "regular" users don't even know is there or know how to configure to their needs (or lack thereof), we're just creating a larger attack surface, which, in the case of tying all of this together in systemd, not only creates a much larger attack surface, but gives it potential root level access... and that is magnified even more by tying it together with dbus/kdbus. |
Yeah, but but, once it's in the kernel, everyone else will be responsible for it, so it won't be associated with RedHat, Sievers and Poeterring any more; it'll just be a stain on the reputation of Linux itself. It's not potential root; it's confirmed always-root, always-running, always pid1 so we know exactly what to attack (we don't even have to make a mild effort), and more we get instant DoS (see Linux is "catching up with Windows") since if init goes, the kernel panics, deliberately.
After all, "if it was that bad an idea", RH wouldn't have been able to "leverage" their paid developer-base into arm-twisting kdbus into the kernel. We've all heard idiot memes like that, excuses not to do the thinking, which are fine for end-users, but absolutely fatal for sysadmins.
I can just see it in a few years; "See; Linux is just as bad as Windows. So why bother?"
| Quote: | | The solution to niche needs, is niche modules that are optional and only installed for those that do need them. |
Indeed; PAM. (which Grue appears never to have heard of.)
Really all this is, is RH trying to do a Microsoft with Linux; buy up "developers" and coopt half the community into going with them, on the basis of some bulshytt, and money for the few (usually those most amenable to scamming others.)
They want to be in the position where if you think Linux, you think RedHat, and "no-one ever got fired for buying RedHat" (even though it led to the site being compromised.)
More honestly it should be: if you think RedHat, think Lennux. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Apr 09, 2015 10:01 pm Post subject: |
|
|
| steveL wrote: | | All it does is enforce a GPL-evasion mechanism across the mainstream Linux install base, and serve the user up as a product to be monetised. |
| ulenrich wrote: | | Android users are affected of exactly this since years. The Google "Binder" ipc mechanism has just seen the light of Linux kernel mainline. |
So what? We should just sit back and accept a mechanism for GPL evasion in-kernel, a project that relies on the GPL?
Puhleez.
If you want to back up your assertion that Binder is equivalent to dbus in terms of GPL evasion, by all means do so.
It won't change the fact that dbus does what several of us have said it does; provide a mechanism to kludge function calls into "localised RPC" which is in itself an oxymoron, and the only reason to do this so inefficiently is that precise effect: providing a mechanism to end-run around the GPL.
Although in fact the "functional interface" aspect has already been addressed, apparently. So all it is, is a lawsuit waiting to happen, only you won't be able to call RH on it, since you knew exactly what you were doing (as an embedded manufacturer employing programmers, for example.) The most you'd be able to do is name them as co-conspirators and facilitators of the whole shebang; it won't enable you to plead ignorance, by any means.
| Quote: | | Otherwise, hearing Ms talking about to open source, there are a whole lot of forces driving the industry. And there are DRM bounds for users regarding content not directly related to computing source code. |
More bulshytt afaic. You read like a Markov-generated stream of "whatever I can think of to make it sound like systemd is a good thing, really, kk not so bad a thing, don't you want your systems convenient, hint hint" (let's bring in some other acronyms to make it sound like I know what I'm on about, even though I haven't actually said anything.)
I note you haven't even acknowledged the points put to you earlier; you just come out with more vague each time, to create "the impression that something has been said". |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Apr 09, 2015 10:06 pm Post subject: |
|
|
| GrueXYZ wrote: | I never said PolicyKit itself was a solution I only acknowledge the problem that requires policies beyond users and groups.
SteveL,
I never said (k)dbus ITSELF were the solution |
Hmm "I never said X was the solution" twice; something fishy there. As stated, PAM for the first.
If you don't have admins able to deal with it, then you don't actually have a need for all this stuff; it's just general speculation, and as such boring.
| Quote: | | I only acknowledge that message-passing instead of executing code at the CPU level, is the proper way to do lo-priv <-> hi-priv communication. |
Yes that's why UNIX has IPC (in several different forms.)
| Quote: | | Such mechanism can establish a policy |
Huh? Message-passing establishing policy makes zero sense, as does any mechanism establishing policy.
Mechanisms implement policy; policy comes from configuration. End of.
| Quote: | | and then create and give access to sockets and file descriptors for actual data transfer. |
ie: reinvent the kernel. which is exactly what I've been saying for at least a year is the whole problem.
Instead of letting the kernel multiplex, dbus tries to multiplex everything, and bottlenecks. Now let's push that into the kernel, instead of realising that what we've designed is a turd.
Instead of letting the kernel permission model work for us, wrap a userland layer instead, subvert all the kernel mechanisms so admin control is out the window, and instead rely on a fast-moving, experimental javascript engine (of all things) to provide "flexibility" since we are incompetent at shell, and we cannot use those boring old PAM modules, as that wouldn't be "innovative" (or crap, as some of us think.)
| Quote: | | Sure, I think that sending audio or video through (k)dbus messages is beyond insane. |
Sure, I just think: so is all the rest of what you've presented. Use-cases there may be, but they've already been addressed, and they simply do not apply to the vast majority of device-users, who this was all supposed to be in aid of.
When the "reasons why" keep changing, it means you're being sold a pig-in-a-poke. ("Performance," no wait everyone tells us that's our own fault, "races" no one argues with that one, after our last cock-up with network names, so yeah um "Races".)
Similarly in this thread, people keep bringing up points (like "trojaned mirrors") and then ignoring the response; let's just elide and move on to the next "point". So I'm going to repeat myself, as this is important imo:
In summary, systemdbug is insecure by design, adds a shedload of work for everyone, and doesn't even add value for the core userbase.
Nor does it for the serious admin, who won't touch such a convoluted mess which they cannot stake their reputation on, because it is simply too complex in its desire to be the One True Init, and far too inflexible with its amateur-hour rejection of modularity.
As a community we should recognise that we don't need to keep arguing about it; it's crap.
Let's move on and address the interesting use-cases in a more sane manner. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Fri Apr 10, 2015 1:29 am Post subject: |
|
|
| steveL wrote: | | Hmm "I never said X was the solution" twice; something fishy there. As stated, PAM for the first. |
Nothing fishy. You guys keep putting words in my mouth. I never said *kits or systemd were the proper solution, only that there exists a real problem, but you keep mentioning them in replies to what I said.
BTW the A in PAM stands for authentication. We're talking authorization here in different contexts that go far beyond what PAM will ever be capable of doing. Otherwise, someone should drop a note to SELinux/AppArmor/GrSec devs and tell them they're wasting their time, there's PAM, right? Yeah, right.
And with that, all I see is complete ignorance toward the actual problems with zero acknowledgement that the problem still exists, regardless of whether systemd and *kits are poor solution to them or not. I think I was clear on that. Also what I'm reading here is complete ignorance of MAC/RBAC security models, and in 2015 I'm begin convinced that writing a shell script to encompass a complex policy with zero integration on the OS-level is the way to go. I guess in the minds of some people here the computer user is still a bearded scientist who can write complex shell scripts, with zero acknowledgement that maybe mere mortals would like to point and click around their laptops and block Steam for their kids past 9pm.
Well fine. I have zero interest to continue the discussion, it lost real technical merit long time ago. I'm done. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Apr 10, 2015 5:42 am Post subject: |
|
|
IDK I lost track of your diatribe about MAC, given that you on the one hand said we need it (implying we don't have it) and then later mentioned that the UNIX MAC isn't something or the other.
If you have points to make about them, instead of just mentioning them as given, especially considering the confusing way you use the terms at different times, why not just outline what exactly you mean, and what you're after, and how PAM doesn't address it, and could never address it.
ATM there's zero technical points in your swansong; it reads like it's not about the actual problems, but all about posturing. So yeah I agree the technical discussion went out the window a while back; pretty much since you started wading in, afaict.
Feel free to have the technical discussion though; just you don't seem to have started yet, only outlined use-cases. On which point I refer you to my previous answer. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Apr 10, 2015 6:57 am Post subject: |
|
|
| GrueXYZ wrote: | | How about time of day when the program can be run? |
SteveL is so right that discussion with you fanbois just so pointless:
You brought up a very particular problem for a niche application, and I showed you how to solve this much more efficiient and secure in the traditional way.
Realizing that you claims cannot be hold you start to shift goals.
Now you claim that an additional unmotivated restriiction is not part of the provided solution, making implicitly the wrong claim that it would be part of the policykti solution.
Of course, the latter claim is as false as it can be: In both cases, you can trivially solve the problem by adding a line or two to the code in the former case, and if he has chosen the policykit "solution" he would also have to add a line or two to his policykit code. So what?
| Quote: | | Programming language of choice has nothing to do with this. We're talking about an API that any language can have bindings for. |
Yes, you can call your own program also with policykit, i.e. you write exactly the tradiitional code in the language of your choice, thus have solved your problem perfectly with sudo, and then completely unnecessarily wrap policykit around it. Then the only purpose whcih policykit serves is to add an unnecessary complexity layer which makes the originally safe solution insecure.
| Quote: | | But I'll ask you again, how do you specify which time of day can a certain binary path be run, by which user? |
Do youi really need to be shown how to check the time of the day or how to read the environment variable SUDO_USER in some programming language?
| Quote: | | Does steam have a policy file in your or my language of choice, and how do I limit WHEN it can be run on a machine? |
And again the goals are shifted. And you do not even realize that the now shifted goal is solved in exactly the same way:
You write a script which tests the time/user and the parameters for steam and then invokes steam.
I already foresee your next shift of goals: You want such a script for several games. Absolutely no problem, either...
If you continue the goal-siftiing game: Yes, once you invent enough randomly unmotivated requirements, it may be more efficient that yoiu write a library for your program. In a such a far-fetched situation, by all means, write some library/subprogram/... to do a certain subclass of tests. If you are sane, you call this library with lowered permissions.
And no, this librarary will still be much less a thread to your system's security than any policy daemon, since it can only decide whether steam, ... can be called and cannot in a failure case execute practically everything. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Fri Apr 10, 2015 3:48 pm Post subject: |
|
|
More new news from Phoronix. "fwupd: Simple, Open-Source Device Firmware Updating" http://www.phoronix.com/scan.php?page=news_item&px=fwupd-UEFI-Firmware-Update
This is just so wrong in so many ways. Like any software, firmware updating should be as simple as possible. Perhaps simplicity is even more necessary, because firmware updates can be a great brick production tool. But there's a difference between simple and convenient. Firmware updates should be a seldom-done thing, and it should never be convenient. Firmware updates should only be done with full knowledge and scheduling of the equipment owner/maintainer. This thing is a daemon, for Pete's sake. Let's put a persistent attack vector out there, make it easy/likely to get tucked into system startup so it's always around, then make it so we can activate it with fork/exec or dbus!
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Apr 14, 2015 6:53 pm Post subject: |
|
|
| ulenrich wrote: | | But the whole rest of the Gnu-Linux community thinks they can rely on (a few mini communities an exception). I still cannot believe it |
Indeed, this is the most worrysome of the whole story: How did these guys trick the communities and manage that these all make fools of themselves?
Most distributions practically had no choice, since RedHat took systematic control over all upstreams.
You can call this conspiracy theory or not, but it is simply a verifiable fact that most big upstream projects include patches - many written by systemd-co-authors, who are simultaneously co-members of the upstreeams project and official RedHat developers - which serve no other purpose than remove the ability of this project to work with anything else than systemd. Just recently, we had some examples here.
So, at least, it is verifiable by everybody, that these actions and decisions are not community-driven, as you claim, but steered by RedHat, or at least by a large group of RedHat developers: If you do not believe, look at the ChangeLogs of the projects where such things happened and who committed the patches; we had such examples just recently.
Communitiies like Debian/Ubuntu/SuSE only have the choice between either dropping important upstreams and go with some substitutes - which would certainly cause a lot of protest - or take over a lot of upstreams by themselves - unreasonable, since they need their full manpower already for just providing the distro - or to bite the bullet and switch to systemd, independent of the security threads.
Moreover, in the beginning, systemd disguised as more or less harmless. I also thought in the beginning (e.g. when Debian discussed the switch) that it is not that bad. But with each release - when they added more and more insanitites which have nothing lost in a permanently running root daemon - I could only shake my head more and more: How can one be that stupid? or evil?
I am sure, people at Debian feel the same, but they have no way to retreat anymore. Practically Debian never had a choice, like most distributions. Gentoo is only lucky, because Gentoo is about choice from its very concept. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Tue Apr 14, 2015 7:15 pm Post subject: |
|
|
mv,
Debian could have choosen to drop Gnome. That wouldn't have been any less contraversial than adopting systemd but it would have stopped the systemd takeup in its tracks. Unfortunately, Red Hat was in control of Debian.
If the fork is still going, that would be the easient way to keep a Debian fork systemd free.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
| Posted: Tue Apr 14, 2015 9:11 pm Post subject: |
|
|
| NeddySeagoon wrote: | mv,
Debian could have choosen to drop Gnome. That wouldn't have been any less contraversial than adopting systemd but it would have stopped the systemd takeup in its tracks. Unfortunately, Red Hat was in control of Debian.
If the fork is still going, that would be the easient way to keep a Debian fork systemd free. |
I could understand all your suspect to systemd. But at the end of the day dropping Gnome is no point. The lag here was that there wasn't any Way to mere Gnome 3 to the init-systems that was already in use. In the evolutionary point of View, the old init-sytem where to komplex to merge the functionality of Gnome3 to openrc. Or the pressure wasn't big enough.
As today seen with docker and other virtual bundle/multiplex Programs i think this issue have the power today to split a community. But the Progress is all ready done. Systemd is on all of my Desktop Systems, just because i think to understood how it works. I never checked the code myself :/ But think its fast, looks secure. But i got stomach pains with all the options that systemd will HAVE in the feature.
The Point is, other systems have to be better, then there opponents and dropping Gnome3 Support isn't any behaviour that is better, its worth.
If Systemd could just launch Gnome3 i think that i had migrate to openrc and KDE4. Right now, i love Gnome3 and never boot into KDE4. Because Gnome read all my wishes from my Lips.
Right now, even if i use Systemd and Gnome3 i would support and spend mony if there is a Kickstarter that try to programm openrc, debian, systemd-free. But with the same parallel Boot. And that also boot Gnome3. But i think that power could also be good in monitoring systemd code.
I am not sure, the issue is not easy to balance. Maybe we have to put more pressure (also financial) on the systemd Team, to build some kind of Systemd-Light. Right now i think that i could use a light Version of Systemd by disabling just some fancy sub-programs. But yes, the tree grow faster than i could build my treehouse! |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Apr 14, 2015 10:37 pm Post subject: |
|
|
| ChrisJumper wrote: | | The lag here was that there wasn't any Way to mere Gnome 3 to the init-systems that was already in use. |
This is the faulty premise the rest of your argument is built on.
Since it is flawed, the rest does not matter. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Tue Apr 14, 2015 10:50 pm Post subject: |
|
|
I'm pretty sure the early versions of gnome 3 used polkit.
And I know that as of a few months back, funtoo had a version of gnome 3 with the logind piece being replaced.
So it was doable. RH just didn't want to, they went for vendor lock.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Wed Apr 15, 2015 1:04 am Post subject: |
|
|
| Just because some software seems secure, does not mean it is. Case in point: openssl & Heart Bleed and how hard that bit everyone in the butt. It's a known fact, as the code base grows, the higher chance for more security issues to pop up. Considering systemd is intent on combining everything into one code base, that's just having it's code base grow exponentialy. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Apr 15, 2015 1:57 am Post subject: |
|
|
| Quote: | | Where did we come up with the idea that one size MUST fit all and that every niche idea has to be included, regardless of how many people DON'T have any need for any of it? |
Redmond. Some people (me, for one) came to Linux looking for a free Unix. Others (most, perhaps) came looking for a free Windows. They have the Windows philosophy of a kitchen sink OS that has everything included and you shut off what you don't need. Unix, OTOH, had the philosophy of a program doing one thing, doing it very well, and connecting it together with pipes and such. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Apr 15, 2015 2:01 am Post subject: |
|
|
| Quote: | | , with zero acknowledgement that maybe mere mortals would like to point and click around their laptops and block Steam for their kids past 9pm. |
If you need a program to make it impossible for your kids to disobey you, you have major parenting problems. There is no virtue without free will. How will your kids learn that disobedience to authority has consequences? When they are booked at a police station? When the IRS attaches their goods? Humans are social animals. The young need to be taught to obey. They want approval and inclusion not disinterested remote control. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Apr 15, 2015 1:04 pm Post subject: |
|
|
| NeddySeagoon wrote: | mv,
Debian could have choosen to drop Gnome. |
It is not done with dropping gnome. You would have to drop/fork udisks, upower, udev, hwids, ..., k3b (probably many other kde programs, too), ...
It would simply mean to drop half of their distribution, or to use substitutes many people would complain about.
I mean, I also saw it in my case how it hurted to drop all of kde which needs policykit, and debian is a distribution for professional institutions who cannot just urgently switch their policy about the programs they use - perhaps they trained their secretaries in it, or whatever...
No, I do not think that Debian had such an option. Even dropping gnome (and all its utilities like evince) would not be an option for them. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Apr 15, 2015 1:53 pm Post subject: |
|
|
mv said: | Quote: | | debian is a distribution for professional institutions who cannot just urgently switch their policy about the programs they use - perhaps they trained their secretaries in it, or whatever... |
Could they not have dropped Gnome in favor of Mate? After all, Mate is really Gnome 2 that all those personnel have been trained on. Gnome 3 is a whole new interface, Much like Windows 8. Everywhere, businesses are sticking with Windows 7 (USPS) and even Windows XP, rather than migrate to Windows 8. That sort of revolt might have made a difference. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Apr 15, 2015 2:34 pm Post subject: |
|
|
| Tony0945 wrote: | | Could they not have dropped Gnome in favor of Mate? |
And who will make sure that Mate will continue to be developed, in particular security issues in gtk-2 being actively searched and fixed?
Moreover, what to do with all the other programs I mentioned (including much of KDE, e.g.)?
| Quote: | | That sort of revolt might have made a difference. |
It would have been a sort of revolt, indeed. But Debian is probably the most conservative distribution on earth.So, in a sense, it was much less a revolt for them to switch to systemd than to take all the other consequences immediately.
It is the same problem as with policiticians or with economy: They go the route which is most convenient in the first steps. Whether it leads to the cliff in the long run - nobody cares. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Wed Apr 15, 2015 6:42 pm Post subject: |
|
|
| ChrisJumper wrote: |
The lag here was that there wasn't any Way to mere Gnome 3 to the init-systems that was already in use. In the evolutionary point of View, the old init-sytem where to komplex to merge the functionality of Gnome3 to openrc. Or the pressure wasn't big enough. |
I hold that that quote is factually incorrect. See Do you support systemd
Its my opinion that the rest of your argument is based on the incorrect fact above and one or more additional faulty premises.
@mv,
I agree about the path of immediate least pain. If you have a long memory or are good with Google or both, you can make Olde Fashioned Gentooee work. I quite like it :)
As you say, there is none of the 'guff' that you list.
All
I like to think of Microsoft, Digital Equipment Corporotion, Apollo, Prime, Control Data Corporation and now Red Hat as dinosars on the road to extinction via customer lock in. Four of them are already extinct. The discussion about the part that customer lock in played in the extinctions is for another thread.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Wed Apr 15, 2015 6:48 pm Post subject: |
|
|
https://lkml.org/lkml/2015/4/15/104
| Quote: | > > Honestly, I think that tightly coupling systemd and udev to certain
> > kernel versions in lock step is crap.
>
> Where do you see that happening?
>
> > That you require some minimum version after some reasonable time,
> > sure.
> > But in lockstep? Seriously.
>
> Has that happened in the past? Look at the minimum requirements of
> systemd/udev today, something like the 3.7 kernel release, many years
> old.
I refer to the linked mailing list post from Lennart as I quote here:
> To make this clear, we expect that systemd and kernels are updated in
> lockstep. We explicitly do not support really old kernels with really
> (which means 3.4 right now), but even that should be taken with a grain
> of salt, as we already made clear that soon after kdbus is merged into
> the kernel we'll probably make a hard requirement on it from the systemd
> side.
Thats plenty clear, isn´t it? As soond as kdbus is merged into kernel,
systemd will depend on it, and then… if I need to go back to older kernel,
I have to downgrade systemd as well? |
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Apr 15, 2015 10:07 pm Post subject: |
|
|
NeddySeagoon said: | Quote: | All
I like to think of Microsoft, Digital Equipment Corporotion, Apollo, Prime, Control Data Corporation and now Red Hat as dinosars on the road to extinction via customer lock in. Four of them are already extinct. The discussion about the part that customer lock in played in the extinctions is for another thread. |
I'd love to read that. Please start one. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
