Announcement

Collapse
No announcement yet.

Systemd 251 Released With systemd-sysupdate Introduced, Many Other Additions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • jacob
    replied
    Originally posted by waxhead View Post

    I don't think it will happen , but systemd allows for linking to proprietary libraries and since it is such an important part of the system my point is merely that the mechanism/basework is there (the way I see it) to allow for possible extensions that could "transform" systemd to a more sinister variant. Will it happen? Quite honestly I think not , at least not in the short term. If it does happen I am sure someone will fork systemd and it may gain traction. The danger with Microsoft is that far too often have they executed the infamous embrace, extend and extinguish tactics and I believe they are going to do that again sooner or later to slowly and surely work on the first E's - at least the way I see it.

    PS! sinepgib : Did this answer your question too? I am concerned about the possibilities - not exactly what is possible or sensible right now.
    Once again, systemd allows that exactly in the same way as glibc (which is LGPL too - in fact the LGPL was originally created specifically for glibc). You can link glibc with nonfree libraries. For example Qt used to be nonfree for a while and it was built with g++ and linked with glibc. The LGPL is not a permissive licence like BSD or MIT. It allows linking to proprietary code but on the condition that the original LGPL code remains accessible under the LGPL. So no, it can't be used to turn systemd into something "sinister" just like glibc never turned into anything sinister. On the other hand, many of the systemd bashers (I'm not implying that you are one) always proclaim how they will move to BSD, well, the BSD licence explicitly DOES allow that.

    Leave a comment:


  • waxhead
    replied
    Originally posted by jacob View Post
    So in short yes, you can develop non-free software that uses systemd in the same way it uses the glibc, the desktop environments and the kernel. But you can't take systemd and make it proprietary. It's not a game changer in any way from that point of view.
    I don't think it will happen , but systemd allows for linking to proprietary libraries and since it is such an important part of the system my point is merely that the mechanism/basework is there (the way I see it) to allow for possible extensions that could "transform" systemd to a more sinister variant. Will it happen? Quite honestly I think not , at least not in the short term. If it does happen I am sure someone will fork systemd and it may gain traction. The danger with Microsoft is that far too often have they executed the infamous embrace, extend and extinguish tactics and I believe they are going to do that again sooner or later to slowly and surely work on the first E's - at least the way I see it.

    PS! sinepgib : Did this answer your question too? I am concerned about the possibilities - not exactly what is possible or sensible right now.
    Last edited by waxhead; 23 May 2022, 12:27 AM.

    Leave a comment:


  • NotMine999
    replied
    birdie

    One day you will fill up your Phoronix "ban list" with the name of every user in the Phoronix forums.

    And then you will post a message on some topic and get no replies in return.

    Sounds like a perfect world for you.

    Leave a comment:


  • jacob
    replied
    Originally posted by waxhead View Post

    Just for the record. I am not a systemd hater. In fact I like it and I think it does solve more problems than it creates. I am also aware that systemd is a bunch of utilities albeit very tightly integrated. However since systemd allows you to link to proprietary software without contributing back you essentially can build "drivers" for systemd which again shims over kernel APIs.

    As for the OS within OS argument, ok that was perhaps a bit enthusiastically and dramatically described by me, but when you got lot of de facto standard functionality it can easily be used badly with lgpl.

    For example, systemd exposes a dbus API, and you can link something to systemd that uses this API which you don't have to provide the source code for, which again can provide convenient functionality that may be a decent lock-in starting point.

    So unless I have misunderstood the lgpl I think I have a valid point here.

    Will it ever happen? Not sure, but it is a possibility which can be used nevertheless.
    IANAL but to the extent I understand the LGPL, it means that you can use a licence of your choice for any derived work as long as the LGPL part itself remains LGPL, with its source code available etc. Note that the LGPL is used for many important userland components, not least for Glibc. It has been that way literally for decades now, if it was a Trojan horse for lock-in, we would have noticed by now. Systemd only uses the already existing licence, by doing so it changes absolutely nothing as far as the ecosystem goes.

    Regarding the DBUS APIs, it would be a question for someone more knowledgeable than me on the fine technicalities of software licensing, but my guess is that merely invoking a DBUS API wouldn't be considered a derived work so the LGPL that covers systemd wouldn't affect the client software in any way. In fact we already have numerous precedents. Software that talks to the Linux kernel over the syscalls API is not a derived work of the kernel and the kernel's GPL doesn't transfer to it. Similarly software that interacts with Mutter (or another Wayland compositor) over the Wayland protocol and DBUS is not a derived work of the compositor.

    So in short yes, you can develop non-free software that uses systemd in the same way it uses the glibc, the desktop environments and the kernel. But you can't take systemd and make it proprietary. It's not a game changer in any way from that point of view.

    Leave a comment:


  • birdie
    replied
    Originally posted by oleid View Post

    Not true. At least they don't use Windows exclusively. Where I work all machines which get in contact with the source code (the secret sauce) use Linux. Only sales is on windows.
    Anecdotal evidence is anecdotal. Congrats.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by waxhead View Post
    Just for the record. I am not a systemd hater. In fact I like it and I think it does solve more problems than it creates. I am also aware that systemd is a bunch of utilities albeit very tightly integrated. However since systemd allows you to link to proprietary software without contributing back you essentially can build "drivers" for systemd which again shims over kernel APIs.
    What kind of driver? What could you possibly do to achieve lock-in that requires no more and no less* coupling than dynamic linking or access to D-BUS APIs?

    *No less because the alternatives are mostly loosely coupled services that you could, for example, call from within whatever you're doing, not being subject to releasing the source code of the caller.

    Originally posted by waxhead View Post
    For example, systemd exposes a dbus API, and you can link something to systemd that uses this API which you don't have to provide the source code for, which again can provide convenient functionality that may be a decent lock-in starting point.
    And you don't need to provide the source code for applications using Linux native system calls either, so what's your point? For any interesting case you'd need to actually modify systemd, which makes it a derivative, which in turns means you need to release the source code. The things systemd actually expose as APIs don't really allow for much more than creating frontends and notifying readiness of your services. Pretty useless for vendor lock-in.
    Besides, lots of desktop functionality has been exposing D-BUS APIs for a long time, I'd say most, and because you don't need to link to those APIs even the GPL doesn't really protect you from interaction with those, but here's the catch: none of them have obvious ways to be used to vendor lock-in without modifying the original sources.

    Originally posted by waxhead View Post
    So unless I have misunderstood the lgpl I think I have a valid point here.
    You understood the LGPL correctly. But you'll need to provide a practical scenario where the things exposed by systemd as a library are actually useful for vendor lock-in, which is at best non-obvious.

    Leave a comment:


  • oleid
    replied
    Originally posted by birdie View Post
    [*]Pretty much all the serious businesses of the world use Windows and MacOS (to a much less extent) which means they are willingly leaking trade secrets to Microsoft/the US government, right?
    Not true. At least they don't use Windows exclusively. Where I work all machines which get in contact with the source code (the secret sauce) use Linux. Only sales is on windows.

    Leave a comment:


  • waxhead
    replied
    Originally posted by jacob View Post

    Systemd is not "an operating system within an operating system". What does that even mean? Systemd is part (or more precisely a collection of parts) of an operating system. It's not an "OS within an OS" any more that the BSD userland is. As to the licencing being a vector for lock-in, seriously? It's LGPL. Let me say this again because it apparently still evades lots of people: It's LGPL. So unless the (L)GPL is now a lock-in licence, it has exactly the same lock-in effect as the Linux kernel itself, or glibc or GCC. That is to say, none whatsoever.
    Just for the record. I am not a systemd hater. In fact I like it and I think it does solve more problems than it creates. I am also aware that systemd is a bunch of utilities albeit very tightly integrated. However since systemd allows you to link to proprietary software without contributing back you essentially can build "drivers" for systemd which again shims over kernel APIs.

    As for the OS within OS argument, ok that was perhaps a bit enthusiastically and dramatically described by me, but when you got lot of de facto standard functionality it can easily be used badly with lgpl.

    For example, systemd exposes a dbus API, and you can link something to systemd that uses this API which you don't have to provide the source code for, which again can provide convenient functionality that may be a decent lock-in starting point.

    So unless I have misunderstood the lgpl I think I have a valid point here.

    Will it ever happen? Not sure, but it is a possibility which can be used nevertheless.

    Leave a comment:


  • birdie
    replied
    Originally posted by rabcor View Post
    It's on open conspiracy, not a conspiracy theory... A lot of governments have started moving away from windows or are using older versions of windows (older versions of windows are still a mistake for governments or high value targets, because there are backdoors in them
    Not a single proof or quote, goodbye. Not gonna read a wall of "I love conspiracies".

    There's also so much lunacy and idiocy it's actually cringe worthy, specially the part about using old unsupported versions of Windows which are rife with remotely exploitable vulnerabilities, not to mention that e.g. on Windows XP/Vista you cannot run modern versions of web browsers which means you leave your PC wide open to hundreds of vulnerabilities and nothing is required except simply visiting a malicious website or watching a malicious advertisement (multiple ad networks allow you to embed your own JS code).

    Linux fans continue to prove they are not friends with facts, logic and common sense.
    Last edited by birdie; 22 May 2022, 04:07 AM.

    Leave a comment:


  • rabcor
    replied
    Originally posted by birdie View Post

    MOAR CONSPIRACIES PLEASE.

    Lunatics are everywhere.
    • Pretty much all the governments in the world use Windows which means they are willingly leaking private info to Microsoft/the US government, right?
    • Pretty much all the intelligence agencies of the world use Windows which means they are willingly leaking state secrets to Microsoft/the US government, right?
    • Pretty much all the serious businesses of the world use Windows and MacOS (to a much less extent) which means they are willingly leaking trade secrets to Microsoft/the US government, right?
    • Windows leaking any info has not been conclusively proven even once during its entire lifetime. I mean you can have all the tools, sniffing, Wireshark, virtual machines, etc. Where are all the proofs??
    Ah, never mind.
    It's on open conspiracy, not a conspiracy theory... A lot of governments have started moving away from windows or are using older versions of windows (older versions of windows are still a mistake for governments or high value targets, because there are backdoors in them, but for those backdoors to be used they'd have to be specifically targeted, which means for us common users it's less of a thing to worry about, but still a bit uncomfortable), it's well known that Russia and China have been striving to move away from windows for years, but governments are slow in such things (I mean I think my own government still only has actual UNIX machines for some pretty important things; it's a first world country.) Of course the US is using it, they don''t have to be too worried about data leaking to themselves after all, but I'm fairly certain they either do not use windows, or use windows but leave the computers unconnected from the internet with just about any machine that contains actual sensitive data. The US military for instance uses linux quite extensively, more than it does windows, despite the absolute control their government has over microsoft.


    Legitimate businesses have less to hide and with expensive lawyers, less to worry about from leaks to governments about misdeeds (since it's still (if barely) illegal for the government to obtain information via microsoft's data collection, doesn't mean they don't do it, just means they're more limited in using it). Business machines also tend not to contain personal data, just professional data, it stands to reason people would generally be less invested in protecting, but did you know pretty much all CEOs and people of similar positions, which yes, tend to use macs or windows, will tape over their webcams when they're not in use? It goes to show how they simply do not trust these operating systems, and they're correct in not trusting them.

    As for the data collection of windows, that's not even a secret, it's public knowledge and microsoft doesn't even bother trying to hide it (it's at such a point where the people who defend microsoft, like you're doing rn, usually don't bother denying windows data collection any more, they just claim to have 'nothing to hide'...), windows 10 and up will steal most data on every internet connected computer, and it has been proved many, many times by tools you mentioned such as wireshark. You just don't seem to have bothered looking it up.


    I don't know where you heard that all the intelligence agencies in the world use Windows but i at least am not privy to such information about agencies that operate mostly in secrecy and would benefit greatly from obfuscating such things by, for instance, lying about which OS they use
    Last edited by rabcor; 22 May 2022, 03:08 AM.

    Leave a comment:

Working...
X