| View previous topic :: View next topic |
| Do you want systemd as default on Gentoo? |
| I <3 systemd!! I want Gentoo to switch!! |
|
12% |
[ 26 ] |
| Get that horse-crap away from Gentoo as far as possible! |
|
87% |
[ 186 ] |
|
| Total Votes : 212 |
|
| Author |
Message |
Sulman
n00b
Joined: 15 Feb 2014
Posts: 63
|
 Posted: Tue Nov 04, 2014 6:13 pm Post subject: |
 |
|
Sigh. Just ran into this at work.
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022749.html
A tool that is supposed to aid in the creation and maintenance of Static addresses is broken.
Along with NFS shares not mounting correctly because the network isn't up.
All of it black boxed, all of it in C (which I am very poor at) and I have nowhere to go, so my solution is to write a shell script and use systemd to call it.
A shell script.
A. Shell. Script. You know, that redundant piece of nonsense that is so symptomatic of crazy old dudes and their wacky init systems. |
|
| Back to top |
|
 |
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Tue Nov 04, 2014 6:57 pm Post subject: |
|
|
| Sulman wrote: | Sigh. Just ran into this at work.
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022749.html
A tool that is supposed to aid in the creation and maintenance of Static addresses is broken.
Along with NFS shares not mounting correctly because the network isn't up.
All of it black boxed, all of it in C (which I am very poor at) and I have nowhere to go, so my solution is to write a shell script and use systemd to call it.
A shell script.
A. Shell. Script. You know, that redundant piece of nonsense that is so symptomatic of crazy old dudes and their wacky init systems. |
Reading TFA in more detail, and it looks to me that clearly systemd comes from an organization called "freedesktop", as in they're somewhat clueless about things beyond the basic desktop.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Tue Nov 04, 2014 8:32 pm Post subject: |
|
|
But, but, but! You're being unfair! Surely every software zis young iz bound to have errors, non?
No, monsieur Grue. Le that piece of crapware is reinventing what had 20+ years to mature and go through all those beginner bugs'n all.
Oui.
Ah, just wait until the not-immediately-obvious problems start to surface... At the worst possible moment (server down, failover didn't fail over, 2 am and you're trying to fix it over ssh.... ) |
|
| Back to top |
|
|
RazielFMX
l33t
Joined: 23 Apr 2005
Posts: 835
Location: NY, USA
|
| Posted: Tue Nov 04, 2014 8:50 pm Post subject: |
|
|
| GrueXYZ wrote: | But, but, but! You're being unfair! Surely every software zis young iz bound to have errors, non?
No, monsieur Grue. Le that piece of crapware is reinventing what had 20+ years to mature and go through all those beginner bugs'n all.
Oui.
Ah, just wait until the not-immediately-obvious problems start to surface... At the worst possible moment (server down, failover didn't fail over, 2 am and you're trying to fix it over ssh.... ) |
Don't worry, Red Hat will provide RHELCE classes (for a fee) to those who want to learn how to administer RedHat Linux; it comes with a shiny certificate too. This way you can be assured that your system admin knows how to fix any said problem.
_________________
I am not anti-systemd; I am pro-choice. If being the latter makes you feel that I am the former, then so be it. |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Wed Nov 05, 2014 2:39 am Post subject: |
|
|
| ct85711 wrote: |
The point I am making, is that you should only make a socket when you intend it to be used. If you only intend a socket to be used for 1 specific portion of code, it should be opened around there; and afterwards be closed. If you want a socket specifically for listening, then you should set it up so your sanitizing everything you receive from that socket (it's better to consider it like a user interface, and not risk having some hostile app use that listening socket to attack your program). A open socket should always be treated as a potential point of attack. |
UHmm .. give me an example of what socket and to where that systemd is pre-allocating in the manner you describe because ... I know how to program, sockets are pretty easy, been doing it a very long time, and you aren't making any sense to me. |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Wed Nov 05, 2014 2:49 am Post subject: |
|
|
| steveL wrote: |
The problems with that API are firstly the userland-specified buffer, and secondly that they don't use normal file-descriptors (though they may, and in Linux, do); the latter isn't usually a problem since if it really matters you're using signals in any case, like X does. The whole point of the API is that it's part of POSIX.4 (the realtime API), which is why the implementation is given latitude to separate out the mechanism. But it would be nice to have an fd as standard, rather than coding per-OS, which is always a drag afaic.
And additionally the broadcast aspect; which is where the networking code is useful, since it already handles this, and is optimised to death. Hopefully you can see there's scope to tie the things together and provide a simple API that doesn't really do much more at app level than provide broadcast message-queues. Doing it generically would actually be easier, as well as cleaner and useful to everyone, rather than a mechanism for coercion of the user-base. And if it turns out we don't need any kernel involvement beyond current abilities, that's an even bigger win, since it means we can forget about a load of useless work.
Though none of that changes the fact that if you're shoving megabytes of data down a common multiplexed bus, YDIW. |
You may have gone over my head. First, is there any point to namespaces other than containers? I think supporting namespaces for containers should be more cut and dry than this, and shouldn't affect user-space code, nor would 99% of user-space code know the difference. It shouldn't thats the point of the container, right?
Second, who is broadcasting megabytes of data to who? Posix message queues are hardly the right API to send tons of bandwidth through. What exactly is the problem that this message bus is trying to solve? I'm still not too keen on dbus, but at least it doesn't require a kernel mod. Its not at all how I would have done it. Perhaps you could enlighten me on what the end goal is supposed to be. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Nov 05, 2014 9:55 am Post subject: |
|
|
| uudruid74 wrote: | | steveL wrote: | Doing it generically would actually be easier, as well as cleaner and useful to everyone, rather than a mechanism for coercion of the user-base. And if it turns out we don't need any kernel involvement beyond current abilities, that's an even bigger win, since it means we can forget about a load of useless work.
Though none of that changes the fact that if you're shoving megabytes of data down a common multiplexed bus, YDIW. |
You may have gone over my head. First, is there any point to namespaces other than containers? I think supporting namespaces for containers should be more cut and dry than this, and shouldn't affect user-space code, nor would 99% of user-space code know the difference. It shouldn't thats the point of the container, right? |
Why are you pulling namespaces and containers into the discussion?
| Quote: | | Second, who is broadcasting megabytes of data to who? Posix message queues are hardly the right API to send tons of bandwidth through. What exactly is the problem that this message bus is trying to solve? I'm still not too keen on dbus, but at least it doesn't require a kernel mod. Its not at all how I would have done it. Perhaps you could enlighten me on what the end goal is supposed to be. |
It's not how I'd do it either. There is no real technical goal, only a business one: to enforce "dbus everywhere" so that GPL software can be used illegally, by claiming that RPC is not a function call, and that since it goes to another process, this is only IPC.
Technically-speaking, there's nothing but downsides, which we've explored in this thread and a few others on these forums.
At the desktop level, privileged operations should be separated out, and as for desktop app communication, that is better done by a library, rather than a library + a mandatory bottleneck. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Wed Nov 05, 2014 12:10 pm Post subject: |
|
|
| steveL wrote: | | enforce "dbus everywhere" so that GPL software can be used illegally, by claiming that RPC is not a function call, and that since it goes to another process, this is only IPC. |
I've seen this mentioned a lot, but how is that violation of the GPL license? systeMd aside, dbus is just a way to register functions to the system and delegate calls between software that requires and provides said function, or am I totally of the mark?
The linking provisions of GPL are there because you have to redistribute the lib your proprietary code depends upon (calls its functions), and the provisions are there to ensure that such usage is within the terms of the license. But if your proprietary software does not care or know which other software, GPL'd or otherwise, will provide the function, so you're not redistributing it with your binary, is there a violation? Sure RPC is a function call, but the issue here is requirement to bundle/redistribute binaries and sources of the caller and callee.
Also, is dbus in spirit much different from a shell call? A proprietary script uses /bin/sh. It doesn't care which is it, dash, bash, as long as it is compliant to the POSIX standards, ie. expects conformity to certain API specifications. It issues a call #!/bin/sh and expects SOMETHING to comply, the parent shell interpreting that and delegating the call to appropriate binary, just like dbus would.
No? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Nov 05, 2014 12:50 pm Post subject: |
|
|
| GrueXYZ wrote: | | steveL wrote: | | enforce "dbus everywhere" so that GPL software can be used illegally, by claiming that RPC is not a function call, and that since it goes to another process, this is only IPC. |
I've seen this mentioned a lot, but how is that violation of the GPL license? systeMd aside, dbus is just a way to register functions to the system and delegate calls between software that requires and provides said function, or am I totally of the mark? |
IOW: the same thing a library ABI does, or when using a network protocol, RPC does.
The systemd/dbus developers freely admit that dbus is an RPC implementation, in that kernel-thread on kdbus, linked several times above.
RPC only exists to mimic function calls where the processes are on separate machines. Localising it is idiotic, to say the least, except when you're testing.
You're still tied to the various versions of the functions you call, so you haven't got away from ABI concerns; even if the underlying protocol doesn't care, the application certainly has to. The CPU and asm language doesn't particularly care either, but the C programmer has to be concerned about it. So it's exactly the same set of problems for the developer. (and RPC has pretty much fallen out of favour in the last 20 years or so.)
| Quote: | | The linking provisions of GPL are there because you have to redistribute the lib your proprietary code depends upon (calls its functions), and the provisions are there to ensure that such usage is within the terms of the license. But if your proprietary software does not care or know which other software, GPL'd or otherwise, will provide the function, so you're not redistributing it with your binary, is there a violation? Sure RPC is a function call, but the issue here is requirement to bundle/redistribute binaries and sources of the caller and callee. |
No the issue is that a library is provided, under the GPL so it can link to other GPL code, which only provides a dbus api, and no standard function entry points. Then an accompanying "library" under the LGPL is provided, which makes calls via that dbus api: this is the only method to use that code, which is completely ass-about-tit, and technically stupid.
The net effect is that a proprietary app is allowed to utilise other GPL libs, while pretending that all it's doing is "IPC", when it is most definitely not mere IPC, but a function call.
In this instance the provider of that pseudo-GPL lib and accompanying API (which as we've seen can only be accessed via an LGPL dbus layer) is facilitating an end-run around the GPL; in the cases of commercial distributions, or embedded hardware companies employing developers to write just that type of "interface", knowingly and deliberately so. That's the win for them, and why they invest money in doing exactly that, despite the fact that it is technically deficient.
| Quote: | Also, is dbus in spirit much different from a shell call? A proprietary script uses /bin/sh. It doesn't care which is it, dash, bash, as long as it is compliant to the POSIX standards, ie. expects conformity to certain API specifications. It issues a call #!/bin/sh and expects SOMETHING to comply, the parent shell interpreting that and delegating the call to appropriate binary, just like dbus would.
No? |
No. See above; it's a function call interface, which gives access to API functionality, exactly the same as linking to a library. That is a completely different thing to executing an external program with a set of command-line switches and arguments.
It's made more evident by the fact that it is a bad idea technically, and can only be less performant than simply providing an API in the first place.
sh is a language, the guardians of whose specification happen to be POSIX, much like WG14 are the guardians of C.
In design terms, while all-encompassing notions usually appeal to novices, more thinking should have been done, perhaps by more experienced people, which could easily have been done by not restricting the process to self-styled "experts" supposedly from the "kernel" who couldn't even see a race coming, nor even be bothered to do any testing with any real admins. Pathetic, really, imo.
==
Oh I mentioned a Google+ post a couple of times wherein Roy Marples shows how fast dhcpcd is so there's the link.
Seems to me that dhcpcd does what the "networkd" of systemd does, already, only much better, and without locking us in to a load of other crap. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Wed Nov 05, 2014 1:19 pm Post subject: |
|
|
| steveL wrote: | No the issue is that a library is provided, under the GPL so it can link to other GPL code, which only provides a dbus api, and no standard function entry points. Then an accompanying "library" under the LGPL is provided, which makes calls via that dbus api: this is the only method to use that code, which is completely ass-about-tit, and technically stupid.
The net effect is that a proprietary app is allowed to utilise other GPL libs, while pretending that all it's doing is "IPC", when it is most definitely not mere IPC, but a function call. |
Thanks for your elaborate answer, but this part is really what is confusing me.
How is this different from an RPC call to a web service API built upon GPL code but proprietary in nature, and there is no redistribution? In other words, software A is issuing RPC to software B, where B is using GPL'd libs, but isn't redistributing it? Surely there is no violation of GPL (at least GPL 2, not sure about 3) and the IPC carrier is HTTP. Are there provisions that make a distinction based on physical proximity or CPUs used? What about virtualized code? Software A and B could be run on same physical hardware but separated through KVM because they belong to different companies, and just happen to, coincidentally, run on same hardware. What if the virtualization is OpenVZ or LXC, then it really does become IPC in the strict sense of the word, no?
So that's what I was asking about. If proprietary software just needs functionality but doesn't rely on particular library, doesn't link to it directly (in terms of ldd and .so execution points), and "merely" utilizes the dbus API calls, is that really in violation of GPL if the caller is proprietary and calee is GPL'd ? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6099
Location: Dallas area
|
| Posted: Wed Nov 05, 2014 1:38 pm Post subject: |
|
|
Interesting, at least to me, that the timing between LP's infamous screed where he rants and raves against Linus
and kernel devs in general and the submission of the kdbus code (even though GKH has had it since at least Jan 2014).
It's as if LP hoped to have a groundswell of support from others forcing the kern devs to allow his code in.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Nov 05, 2014 1:57 pm Post subject: |
|
|
GrueXYZ
The idea there is put something in between GPLed software and proprietary to bypass the GPL need.
If you need interface from A(proprietary)->B(GPL)
You can instead A->X(could be free, and even open, as long as it allow you to be link with A)->B
This way, you dismiss B licensing issue, as your A program is not using B, but X and is tied then only to X license issue.
Now could dbus be use with GPL and proprietary program to bypass the GPL? http://dbus.freedesktop.org/doc/dbus-faq.html#idp49340912
So when someone dev a GPL software using dbus interface, they aren't aware they are abuse.
There's a difference from a free and/or open license and GPL, GPL have a restriction to enforce the free and open code is also apply to someone using your work (it's viral, and this include libraries, LGPL isn't for libraries, the L in it is lesser, not library, so we are speaking in that case to avoid license issue of libraries under GPL).
So instead of just releasing your code open and free to use, you release it under GPL to make sure anyone using your work will provide his work to other also (the idea is "i gave you my code BUT you must also do the same").
While any GPL author isn't tied to anything (any author can relicense his own work as he wish, so he could relicense to LGPL or a less restrictive license), all derivatives (fork) cannot.
The dbus trick allow to bypass original author that don't wish relicense his work (or cannot like with forks). So it remove that restriction from the GPL, and the dev releasing its work under GPL is in fact releasing it under LGPL without knowing. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Nov 05, 2014 2:04 pm Post subject: |
|
|
| steveL wrote: |
Oh I mentioned a Google+ post a couple of times wherein Roy Marples shows how fast dhcpcd is so there's the link.
Seems to me that dhcpcd does what the "networkd" of systemd does, already, only much better, and without locking us in to a load of other crap. |
Your first mention of this was earlier, but I'm grabbing it from here as the most recent viewing...
It sounds like dhcpcd by default does it the right way, and with the "-A" option can do it the fast way. The difference is "ARP checking". Any idea how real a threat MAC spoofing is in the real world? We're generally not using hubs any more, and I would say that on large installations switches are used that won't respond in the simple/dumb way to arp-flooding of effectively turning into a hub.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Wed Nov 05, 2014 2:30 pm Post subject: |
|
|
| krinn wrote: | GrueXYZ
The idea there is put something in between GPLed software and proprietary to bypass the GPL need. |
Ahhhhh.... so it's not direct violation, it's violation "in spirit" by making sure circumstances for the violation do not occur, by decoupling the libs... Okay I understand. My confusion was around "is violating GPL". So it's not happening directly but in spirit by removing direct, obvious violation. Thanks krinn, steveL.
But... what would be the purpose of that, unless someone is planning to push (parts of) the ecosystem into proprietary zone? Perhaps devices running close-sourced proprietary code directly based on the Linux kernel, sySteMd and associated GNUserland? Omg, this basically enables GPLd software within BSD-licensed-like conditions! Ah, but wait, can't distribute the code unless.... systemd begets a software package manager which does post-distribution download and inst... OMG! The "Revisiting ...." blog post by LP! That's it!
I don't usually buy into conspiracy theories but FFS the chessboard and the way the pieces are positioned hasn't been more clear! |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Nov 05, 2014 6:23 pm Post subject: |
|
|
| GrueXYZ wrote: | | krinn wrote: | GrueXYZ
The idea there is put something in between GPLed software and proprietary to bypass the GPL need. |
Ahhhhh.... so it's not direct violation, it's violation "in spirit" by making sure circumstances for the violation do not occur, by decoupling the libs... Okay I understand. My confusion was around "is violating GPL". So it's not happening directly but in spirit by removing direct, obvious violation. |
I'd argue that it is a violation, given the above reasoning; a function-call is a function-call, and doing something deliberately stupid in technical terms to try and relabel it "RPC^W IPC" is in-fact bad-faith.
The only question a judge would have to consider, imo, is how a "practitioner" views that function-call; and based on conversation with others, to compare my own view of it, no-one views that any different to a normal function-call. That's the whole point of RPC, and indeed an embedded developer immediately stated (without even being asked) that that's why they love dbus: because they can "ignore" the GPL. Or so they think.
Sure it's a blocking call, but so are many others we use on a daily basis. And ofc if you're putting together an app that uses RPC, you'd be aware of that (eg for profiling): but your code wouldn't be written as if it were anything other than a normal function-call; again, that is the whole point of RPC.
I'm just glad the systemdiots are now on record as stating that dbus is RPC, since that speaks to the nub of the issue. Peel that onion, and you find a turd dressed up as a pearl. Good propaganda^W marketing though..
| Quote: | | But... what would be the purpose of that, unless someone is planning to push (parts of) the ecosystem into proprietary zone? |
Precisely. The distribution aspect isn't even a concern, since all you have to do is make your GPL-part depend on whatever you like; the issue is that the split-parts are designed to get round the GPL, as there simply is no technical basis for their separate existence.
And licensing one part as GPL and the other LGPL is a pretty clear indication of the purpose, as if the technical stupidity were not enough of a smoking-gun.
| Quote: | | I don't usually buy into conspiracy theories but FFS the chessboard and the way the pieces are positioned hasn't been more clear! |
Yup; whenever there's pretext and bulshytt, there's always another reason. And if you don't know what that reason is, it's money. But you can be damn sure that whoever is feeding you the line, is not going to acknowledge the real reasons, since that would be akin to revealing how the con works to the mark, before it's played-out.
Instead you'll get lots of other nonsense, that changes as the "sales-line" changes, according to what sort of "spin" is most useful, given that the last pretext has fallen and been quietly forgotten. And if anyone reminds you of it, they're just "harping."
Mostly this is based on an appeal to sheeple consumerism ("Buy now!" Don't think, just have all your buttons pushed til you make a stupid decision, and then cognitive dissonance does the rest, along with random FUD reminders to keep your brain from thinking. "C'mon we're giving you this stuff for free.. for free" even though it is based on stuff you already wrote, and merely coopts your community's hard work to push it back to you in a form that locks you in; hey that's practically de-rigeur for a modern crapitalist.. "Roll up, roll up, one born every second..") |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Nov 05, 2014 6:32 pm Post subject: |
|
|
| depontius wrote: | | steveL wrote: |
Oh I mentioned a Google+ post a couple of times wherein Roy Marples shows how fast dhcpcd is so there's the link.
Seems to me that dhcpcd does what the "networkd" of systemd does, already, only much better, and without locking us in to a load of other crap. |
It sounds like dhcpcd by default does it the right way, and with the "-A" option can do it the fast way. The difference is "ARP checking". |
Exactly: by default dhcpcd follows the standard and keeps you safer; if you want to disable the ARP checking, simply supply a flag to turn it off. Simple, easy to configure, and doesn't force you to use anything in particular to start it, exactly as it should behave.
| Quote: | | Any idea how real a threat MAC spoofing is in the real world? We're generally not using hubs any more, and I would say that on large installations switches are used that won't respond in the simple/dumb way to arp-flooding of effectively turning into a hub. |
No idea; I've always used switches since they're more efficient, and I don't like the effectively promiscuous mode of hubs. Although if I'm honest, I didn't know that affected this; as I said I'm no net-admin.
All I'd say is that systemd has deliberately removed ARP-checking, and made a big brouhaha out of how that makes your laptop come up soo quickly ("kewl, huh?"); so if you want exactly the same with dhcpcd you can have it, and ridiculously simply. Not sure how the converse would go, mind.
Dhcpcd additionally does other things related to its core functionality, and derived naturally from its impl (netlink); as described in that forum post, you don't need any other "network manager" but equally unless you tell dhcpcd to do more, it just does its job, and it doesn't enforce any dumbass dependencies; ever.
I know which one I think is both more capable, and cleaner to use. As well as which set of developers I'd trust. |
|
| Back to top |
|
|
Sulman
n00b
Joined: 15 Feb 2014
Posts: 63
|
| Posted: Wed Nov 05, 2014 8:30 pm Post subject: |
|
|
| avx wrote: | | http://www.osnews.com/story/28026/Editorial_Thoughts_on_Systemd_and_the_Freedom_to_Choose |
Oh jeepers, the comments.
I'm realising more and more that a lot of people don't fully understand that they are being sold a solution in search of a problem. |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Wed Nov 05, 2014 8:52 pm Post subject: |
|
|
| GrueXYZ wrote: |
Also, is dbus in spirit much different from a shell call? A proprietary script uses /bin/sh. It doesn't care which is it, dash, bash, as long as it is compliant to the POSIX standards, ie. expects conformity to certain API specifications. It issues a call #!/bin/sh and expects SOMETHING to comply, the parent shell interpreting that and delegating the call to appropriate binary, just like dbus would.
No? |
NO!
People keep doing this and its pissing me off. /bin/sh is not a symlink to your preferred shell! You put your preferred shell in /etc/passwd, set for each user. This is placed into SHELL so that programs can "drop you to the shell" and give you your normal shell.
/bin/sh is the bourne shell. Because bash (bourne again shell) can understand bourne files, some people started removing the bourne shell and making a symlink to bash. This is fine as is. Anything that calls /bin/sh and gets bash will work. Do NOT put #!/bin/sh at the top of your file and expect to get extensions that posix bourne does not support. #!/bin/sh explicitly calls a specific shell. Every shell has its own syntax and you are supposed to use the #! for the shell who's syntax you are using. Don't use bash syntax and tell it to call bourne!
And back to your point. In a shell script, you naming EXPLICITLY the exactly binary to interpret the code, and you have the code in full view. Its no different than executing any executable file directly. It would be similar if your script read data from stdin, including the names of shell functions, and then through an eval or a case to process it and wrote the data back. A lot of overhead, no?
I don't know if the intent is getting around the GPL though. Some people just like to overdesign things. |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Wed Nov 05, 2014 9:10 pm Post subject: |
|
|
| depontius wrote: |
It sounds like dhcpcd by default does it the right way, and with the "-A" option can do it the fast way. The difference is "ARP checking". Any idea how real a threat MAC spoofing is in the real world? We're generally not using hubs any more, and I would say that on large installations switches are used that won't respond in the simple/dumb way to arp-flooding of effectively turning into a hub. |
ARP poisoning is pretty easy. And almost all switches will fall-back into hub mode. After all, they need a MAC table to route, and there is a limit to that table. Mitm attacks are inclredibly easy. Hell Ettercap will do the most common attacks for you.
That said, I don't think -A will prevent those issues one way or the other. The normal way prevents collisions when someone statically configures an IP in a DHCP controlled IP space. The -A / systemd method is like not checking for null pointers in your code to "make it faster". |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Wed Nov 05, 2014 9:33 pm Post subject: |
|
|
| uudruid74 wrote: |
People keep doing this and its pissing me off. /bin/sh is not a symlink to your preferred shell! You put your preferred shell in /etc/passwd, set for each user. This is placed into SHELL so that programs can "drop you to the shell" and give you your normal shell. |
Uh... where did I say it was a symlink to preferred shell? As far as I know, and wikipedia agrees with me (I'm sure there's a more relevant source, but I'm too lazy to look it up now) POSIX requires a bourne compatible shell at that path, it can really be anything bourne shell compatible. Like dash for example. Or some xsh-ng thing. Or... hehe, systemd-shelld. I called it first! |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6099
Location: Dallas area
|
| Posted: Wed Nov 05, 2014 9:46 pm Post subject: |
|
|
| avx wrote: | | http://www.osnews.com/story/28026/Editorial_Thoughts_on_Systemd_and_the_Freedom_to_Choose |
you can certainly tell who the fanbois are in the comment section. Oy Vey!
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Nov 05, 2014 9:52 pm Post subject: |
|
|
| uudruid74 wrote: | | depontius wrote: |
It sounds like dhcpcd by default does it the right way, and with the "-A" option can do it the fast way. The difference is "ARP checking". Any idea how real a threat MAC spoofing is in the real world? We're generally not using hubs any more, and I would say that on large installations switches are used that won't respond in the simple/dumb way to arp-flooding of effectively turning into a hub. |
ARP poisoning is pretty easy. And almost all switches will fall-back into hub mode. After all, they need a MAC table to route, and there is a limit to that table. Mitm attacks are inclredibly easy. Hell Ettercap will do the most common attacks for you.
That said, I don't think -A will prevent those issues one way or the other. The normal way prevents collisions when someone statically configures an IP in a DHCP controlled IP space. The -A / systemd method is like not checking for null pointers in your code to "make it faster". |
I would expect that in industrial settings they don't use simple switches, and if in fact one port started ARP flooding, it would find itself taken off line. Heck, where I work they get a bit uppity if you unplug one system and plug another into the same jack, too fast. MACs are registered, though of course that can be spoofed.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6099
Location: Dallas area
|
| Posted: Wed Nov 05, 2014 10:03 pm Post subject: |
|
|
From the lkml thread about kdbus
| Quote: | Of course, if kdbus ends up being what everyone uses for D-Bus on Linux,
then there will no longer be much point in adding Linux-specific
features to dbus-daemon. |
It seems what they want is to transfer all of dbus into the kernel, warts and all.
I'm pretty sure that won't fly with very many kernel devs, nor Linus either.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Thu Nov 06, 2014 2:22 am Post subject: |
|
|
LWN: Kdbus meets linux-kernel: http://lwn.net/SubscriberLink/619068/1df53bf476960b88/
| Quote: | | In general, kdbus is meant to be a replacement for D-Bus that addresses the various issues that have come up with the latter over time. |
And here I thought dbus itself was the problem...
For me, Thunar doesn't generate thumbnails when built with USE=-dbus. Why the heck doesn't it just call tumbler directly with a path to a file, but instead sends that over dbus? Either I'm too stupid, too old or - well, just tell me.
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| 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
