Re: General Discussion about GPLness
Hm, really it is quite hard to stay calm reading your constant insults on people that have quite sure done a lot more for free software than you have. I do understand why you cannot enter a discussion with your real name, as most of your input is of zero quality - and below. Unfortunately you did not even try to understand what the true issue is all about. It is one story to modify running code that probably was never ment to be patched that way (which would involve re-engineering it). But our story is about kernel modules, something everybody is free to write and publish, with a defined and open interface for interaction. No kernel code is modified in that sense. But you fail to understand that. Hopefully others here do. I do not expect them to stand up and jump into a discussion where you are a part of. But I hope people start to think about it and realise - like I did - that this train is on the wrong track. After all I do believe that constructive interaction of software is still better than destructive building of hurdles and walls. Because in the end people are only suffering from this approach and nothing is protected. -- Regards, Stephan On Sun, 23 Feb 2020 16:24:28 + whywontyou...@waifu.club wrote: > I gave you an example of a court immediately finding that modifying a > running program is not allowed without permission. Creators of Non-gpl'd > programs don't have permission to interact with a GPL'd work by > modifying or extending it. If the principal stands for RealPlayer, it > stands for Linux. > > The GPL is a copyright license; law is the domain this is in. > > In the domain of programming: you can do whatever you want. No technical > measure is stopping you. > > In the domain of what is "right and wrong" but excluding law, since you > mentioned it and thus opened the door. Well... YHWH allows men to have > female children as brides: > >>>> The Torah explicitly allows men to marry female children, including > >>>> in cases of the rape (tahphas) of the girl child: Devarim chapter > >>>> 22, verse 28. Key words: Na'ar (child (hebrew masoretic text)), > >>>> Padia (child: padia+philos = paedophillia (greek septuagint)) Puella > >>>> (young girl (latin vulgate)) > >>>> Nachmanides points out that a child may be called na'ar from the > >>>> moment he is born. > White idiots (such as the Linux programmers like Linus Trovalds) do not: > White idiots worship white women. This is a problem for Free Software > because White idiots (like Linus Trovalds) will do /anything/ to make > money for "Muh whoite wuhman". That includes cowering in the face of > being "blackballed" from the industry if they DARE enforce their > copyrights. > > In the domain of willpower: the linux copyright holders, atleast the > programmers who are copyright holders, are NOT going to sue you for > violating the copyright license permissions. They are pieces of shit who > don't believe in "Copyleft". They believe in the BSD license, and have > effectivly made Linux a BSD-type work since they never enforce the GPL. > > OpenSourceSecurity (GRSecurity) is blatantly violating section 4 and > section 6 of the linux copyright license and the Linux copyright-owning > programmers would rather punish anyone who brings it up than sue the > violators. > > They are weak feckless people: more concerned about making money for > "Muh wuhman" than anything else. Pay them no mind. They are scumbag > idiots who won't know what they had until it's gone (it is). > > I think that covers all the topics, right? > > So, by law may you do what you suggested: No: it is a copyright > violation in the US. > Is anyTHING going to stop you: no. > Is anyONE going to try to punish you for it: no. > > Remember: linux copyright holders are either stupid white nerds (if they > were smart they would have listened to their parents and become doctors > and lawyers, and have tech as a fun hobby. Instead they are wageslaving > for "MUUH WHOITE WUUHHMAN": same as any white idiot worker) > OR corporations who like the BSD license better. > > You don't really have much to worry about. Because linux programmers are > what they are. Sheep that thought themselves lions after RMS' win vs > Cisco (that put the fear of the violating the copyright license (GPL in > that case) for awhile). > > On 2020-02-23 14:39, Stephan von Krawczynski wrote: > > Hello again, > > > > at least you are beginning to sound a bit more like being able to > > discuss > > something ;-) > > The thing about a lawyer (I learned you are) is that they judge the > > world > >
Re: General Discussion about GPLness
r; you'll just attack the messenger. > Tell me how _I_ benifit from telling YOU my name. Tell me. > Is it some sort of stupid werkin man white man bravado? > > > I have no idea why you spam rms or bruce > > with this, as the question is all about _one_ project, namely > > linux-kernel. > > You sent a message to the LKML "Hey why can't I violate the GPL? Let's > just do it!". IE: a licensing discussion. RMS and Bruce Perens, the > founder of the Free Software Movement and the Open Source Initiative are > relevant parties to the discussion. > > > > I'd suggest taking them off this topic again ... > You also suggested I reveal my identity on the internet... > > > On 2020-02-23 12:33, Stephan von Krawczynski wrote: > > Dear whoeveryouare, > > > > can you please state in a clearer form (more understandable to > > non-native > > english talkers) what your true opinion on the topic is? > > And in case you did not understand what I was saying, here is clearer > > form of > > my opinion: > > > > A kernel module with another license (be it whatsoever) is _no_ > > modification > > of the kernel, but an extension of its features. If feature-extension > > is > > against the GPL (which I seriously doubt) then I would say "go back > > onto your > > trees". Because the human race and evolution is about little else than > > feature-extension. > > > > And another thing: court is for lawyers. Whenever the lawyers take over > > something they don't (want to) understand the end is near ... > > > > How about talking with real names? I have no idea why you spam rms or > > bruce > > with this, as the question is all about _one_ project, namely > > linux-kernel. > > I'd suggest taking them off this topic again ... > > > > -- > > Regards, > > Stephan > > > > > > > > On Sun, 23 Feb 2020 11:03:56 + > > whywontyou...@waifu.club wrote: > > > >> Dear Stephan von Krawczynski; > >> > >> Universal City Studios Inc v Reimerdes, piece of shit. > >> > >> "[The court] reasoned that Ferret consumers who used the Ferret as a > >> plug-in to the Real Player altered the Real Player user interface by > >> adding the Snap search button or replacing it with the Stream box > >> search > >> engine button. The court concluded that the plaintiff raised > >> sufficently > >> serious questions going to the merits of its claims to warrant an > >> injunction pending trial" > >> > >> Want to violate the linux kernel copyright, you fucking piece of shit? > >> Yes you do. Yes modifying the running kernel with violating pieces is > >> copyright infringement, you fucking piece of shit. Yes you should be > >> sued. Just as Open Source Security (Grsecurity) should be sued for > >> their > >> violations (of section 4 and 6 of the linux kernel copyright license > >> (they're also violating the GCC copyrights too)). > >> > >> Will they be sued? Will you be sued? No: Linux copyright holders are > >> scared little wageslave worker bees. They aren't going to sue you; > >> sorry. Why are you even announcing you intent to violate the > >> copyright? > >> Why even give these dogs such intellectual deference? > >> > >> I wish OpenSourceSecurity would be sued. I wish you would be sued. But > >> linux WERKIN MAHN wage slave piece of shit idiots won't do it: I hate > >> them much more than I hate the violators. Complete Dogs. They could > >> move > >> from strenght to strenght, from victory to victory; but they're scared > >> for their "JEHRB"s. I have to say: white men are pathetic scum. If > >> Linux > >> was built by others there would rightfully be lawsuits. > >> > >> > >> > >> > Stephan von Krawczynski wrote: > >> > Hello all, > >> > > >> > you may have already heard about it or not (several times in the past), > >> > non-kernel devices run into a symbol export problem as soon as > >> > something is > >> > only exported GPL from the kernel. > >> > Currently there is a discussion regarding zfs using this call chain: > >> > > >> > vdev_bio_associate_blkg (zfs) -> blkg_tryget (kernel) -> > >> > percpu_ref_tryget > >> > (kernel) -> rcu_read_unlock (kernel) -> __rcu_read_unlock (kernel) > >> > > >> >
Re: General Discussion about GPLness
Dear whoeveryouare, can you please state in a clearer form (more understandable to non-native english talkers) what your true opinion on the topic is? And in case you did not understand what I was saying, here is clearer form of my opinion: A kernel module with another license (be it whatsoever) is _no_ modification of the kernel, but an extension of its features. If feature-extension is against the GPL (which I seriously doubt) then I would say "go back onto your trees". Because the human race and evolution is about little else than feature-extension. And another thing: court is for lawyers. Whenever the lawyers take over something they don't (want to) understand the end is near ... How about talking with real names? I have no idea why you spam rms or bruce with this, as the question is all about _one_ project, namely linux-kernel. I'd suggest taking them off this topic again ... -- Regards, Stephan On Sun, 23 Feb 2020 11:03:56 + whywontyou...@waifu.club wrote: > Dear Stephan von Krawczynski; > > Universal City Studios Inc v Reimerdes, piece of shit. > > "[The court] reasoned that Ferret consumers who used the Ferret as a > plug-in to the Real Player altered the Real Player user interface by > adding the Snap search button or replacing it with the Stream box search > engine button. The court concluded that the plaintiff raised sufficently > serious questions going to the merits of its claims to warrant an > injunction pending trial" > > Want to violate the linux kernel copyright, you fucking piece of shit? > Yes you do. Yes modifying the running kernel with violating pieces is > copyright infringement, you fucking piece of shit. Yes you should be > sued. Just as Open Source Security (Grsecurity) should be sued for their > violations (of section 4 and 6 of the linux kernel copyright license > (they're also violating the GCC copyrights too)). > > Will they be sued? Will you be sued? No: Linux copyright holders are > scared little wageslave worker bees. They aren't going to sue you; > sorry. Why are you even announcing you intent to violate the copyright? > Why even give these dogs such intellectual deference? > > I wish OpenSourceSecurity would be sued. I wish you would be sued. But > linux WERKIN MAHN wage slave piece of shit idiots won't do it: I hate > them much more than I hate the violators. Complete Dogs. They could move > from strenght to strenght, from victory to victory; but they're scared > for their "JEHRB"s. I have to say: white men are pathetic scum. If Linux > was built by others there would rightfully be lawsuits. > > > > > Stephan von Krawczynski wrote: > > Hello all, > > > > you may have already heard about it or not (several times in the past), > > non-kernel devices run into a symbol export problem as soon as > > something is > > only exported GPL from the kernel. > > Currently there is a discussion regarding zfs using this call chain: > > > > vdev_bio_associate_blkg (zfs) -> blkg_tryget (kernel) -> > > percpu_ref_tryget > > (kernel) -> rcu_read_unlock (kernel) -> __rcu_read_unlock (kernel) > > > > where __rcu_read_[lock|unlock] is a GPL symbol now used by (not GPL > > exported) > > percpu_ref_tryget. > > > > That this popped up (again) made me think a bit more general about the > > issue. > > And I do wonder if this rather ideologic problem is on the right track > > currently. Because what the kernel tries to do with the export GPL > > symbol > > stuff is to prevent any other licensed software from _using_ it in > > _runtime_. > > It does not try to prevent use/copy of the source code inside another > > non-gpl > > project. > > And I do think that this is not the intention of GPL. If it were, then > > 100% of > > all mobile phones on this planet are illegal. All of them use GPL > > software > > from non-gpl software, be it kernel modules or apps - and I see no > > difference > > in the two. The constructed difference between kernel mode software and > > user-space software is pure ideology. Because during runtime everything > > is > > just call-chained. > > Which means if you fopen() a file in user-space it of course uses GPL > > symbols > > down in the chain somewhere. The contents of the opened file are not > > heaven-sent. > > If you/we follow the current completely ideology-driven GPL strategy > > then I am > > all for completely giving up this whole project. In real world you > > simply > > cannot use such a piece of software. The success of linux during the > > last > > years (i.e. decade) is not based on
Re: Problem resolving domain
On Mon, 27 Jan 2020 16:36:42 +0100 Anand Buddhdev wrote: > On 27/01/2020 16:26, Stephan von Krawczynski wrote: > > Hi Stephan, > > > I would have expected that bind finds the domain by using the working > > nameserver and ignoring the dead one. But obviously it does not. > > Did I misconfigure something? I thought both nameservers should be > > questioned and the first working result be used, or not? > > Without knowing which domain it is, we can't even begin to guess at the > problem, because things in DNS could be broken in many different ways. > > I would advise you to reveal the problematic domain name, and you will > get help much faster. > > Regards, > Anand Hello Anand, the domain in question is "dqb.info". Please keep in mind, the domain is in no way related to me. I was just notified by access customers that we fail to deliver it. -- Regards, Stephan ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Problem resolving domain
Hello all, I ran across a question I did not really expect. I am using bind 9.14.1 as normal, standalone nameserver. When trying to resolve a certain domain I get a SERVFAIL (with nslookup). Deeper inspection of the problem shows that the domain uses 2 nameservers, where one works perfectly well, the other does not know the domain at all. I would have expected that bind finds the domain by using the working nameserver and ignoring the dead one. But obviously it does not. Did I misconfigure something? I thought both nameservers should be questioned and the first working result be used, or not? -- MfG, Stephan von Krawczynski -- ith Kommunikationstechnik GmbH Lieferanschrift : Reiterstrasse 24, D-94447 Plattling Telefon : +49 9931 9188 0 Fax : +49 9931 9188 44 Geschaeftsfuehrer: Stephan von Krawczynski Registergericht : Deggendorf HRB 1625 -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On Mon, 18 Mar 2019 12:32:56 -0700 Victoria Risk wrote: > Regarding allow-update: > [...] > Regards, > > Vicky Risk > Product Manager for BIND Thank you for this very professional statement and for noting my suggestion regarding "zone templates". Generally I would have voted for Alans' way of fixing in 9.14.0, but for now I am hoping for the best ... -- Regards, Stephan von Krawczynski ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On Mon, 18 Mar 2019 12:06:57 -0400 Bob Harold wrote: >>[...] > Thanks for the explanation, and for asking for input. > And thanks for maintaining BIND, we depend on it. > > My group manages about 3000 zones. > In my opinion, 'everything' should be inherited, to make the configuration > as simple as possible. And it should be possible to override any setting > at a lower level, for the exceptions. It would be even better if I could > 'group' zones and set configurations on the group. Repeating the same > configuration thousands of times seems like a waste. I would even set > "masters" and 'type' at the top level if I could, since 90% of my zones > come from the same hidden master. And if the file name could have a > default or a pattern, that could be set at the top also, leaving only a > list of zones names for most zones. > > If you make the change, I can live with it, but it is not my preference, > and does not seem like an improvement. > > -- > Bob Harold Thank you very much. It seems I am not alone with my way of using BIND. Exactly such a setup is the cause for my suggestion of a "zone-default" statement in another post. This would allow the grouping that you are looking for. -- Regards, Stephan von Krawczynski ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On Mon, 18 Mar 2019 11:37:50 + Tony Finch wrote: > Stephan von Krawczynski wrote: > > > > But to us it was clearly time to at least present the idea to configure > > zones based on a user-defined default zone entry. > > Catalog zones have that kind of structure: there are options at the level > of the whole catalog which individual zones can override. > > Tony. Yes, they have. But honestly while talking about issues I really don't want any dynamic changes in the basic DNS handling (besides the cert challenge). If your master dies, the setup is probably in trouble. Call me old-fashioned, but a config file is a config file. It's a lot harder to inject something in a setup not using rndc on such a fundamental scale ... -- Regards, Stephan von Krawczynski ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
Please let me re-phrase the above suggestion to:
zone-default "default1" { type master; allow-update { 127.0.0.1; }; };
zone-default "default-slave" { type slave; masters { 10.0.0.1; 10.0.0.2; }; };
zone "mytest.domain" { default1; file "a_zone_file_for_mytest.domain"; };
zone "our-slave.domain" { default-slave; file "just_some_domain.bak"; };
It seems more accurate to name a new keyword "zone-default" instead of
including the new feature into the "zone" statement. This way it is absolutely
clear that it is no real zone, but a collection of options for some zone yet
to come later on.
--
Regards,
Stephan von Krawczynski
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
Ok, first let me thank Alan et al for clearing up the initial topic and making
the problem more visible than me was able to.
Just for the papers, we are hosting some hundred domains, and of course we are
able to handle sed. We can change the config regarding this issue. But to us
it was clearly time to at least present the idea to configure zones based on a
user-defined default zone entry. This would clarify (and shorten) the config
quite a bit. Something like:
zone "default1" { type master; allow-update { 127.0.0.1; }; };
zone "default-slave" { type slave; masters { 10.0.0.1; 10.0.0.2; }; };
zone "mytest.domain" { default1; file "a_zone_file_for_mytest.domain"; };
zone "our-slave.domain" { default-slave; file "just_some_domain.bak"; };
This would allow multiple default entries and still give a trivial overview
inside the config. To me, it looks easy to implement, does not interfere with
what is there and still gives the option of defining something "semi-global".
The "all-but-one" case is trivial with such a definition option.
What do you think?
--
Regards,
Stephan von Krawczynski
--
MfG,
Stephan von Krawczynski
--
ith Kommunikationstechnik GmbH
Lieferanschrift : Reiterstrasse 24, D-94447 Plattling
Telefon : +49 9931 9188 0
Fax : +49 9931 9188 44
Geschaeftsfuehrer: Stephan von Krawczynski
Registergericht : Deggendorf HRB 1625
--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind and certbot with dns-challenge
On Sun, 17 Mar 2019 12:40:35 +0100 Reindl Harald wrote: > Am 17.03.19 um 12:13 schrieb Stephan von Krawczynski: > > So why is it, that there is no global way of defining default zone > > definitions which are only overriden by the actual zone definition? > > maybe because it brings a ton of troubles and whoever deals with more > than 5 zones has automatic config management in place anyways? If you don't want to follow the positive way (how about a nice additional feature), then please accept the negative way: someone broke the config semantics by implementing a zone based-only "allow update". This option worked globally before (too), so we can assume it is in fact broken now. Can someone please point me to the discussion about this incompatible change? > > Why is there no way to define a hosts-type-of-file with an URL-to-IP list? > > Do you really want people to define 50.000 zones to perform adblocking? > > no, just use the right tool for the task, this don't fit into the domain > concept of named and hence you have dnsmasq and rbldnsd to step into > that niche In todays' internet this is no niche any more. And the right tool means mostly "yet-another-host" because you then need at least a cascade of two, one for dnsmasq and one for bind/named. A lot of overhead for quite a simple task... > > Configs have to be reloaded every now and then, is there really no idea > > how to shorten things a bit? > > ?? Shorter config = shorter load time. The semantic change of "allow update" alone leaves every setup with 1000 domains in a situation where 999 config statments more have to be read, interpreted and configured - just to end up in the same runtime setup. It is really very obvious that this is only done by ideologists, not technical oriented people. -- Regards, Stephan von Krawczynski ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind and certbot with dns-challenge
Hello all, I am using "BIND 9.13.7 (Development Release) " on arch linux. Up to few days ago everything was fine using "certbot renew". I had "allow-update" in nameds' global section, everything worked well. Updating to the above version threw a config error that "allow-update" has no global scope and is to be used in every single zone definition. And this brought me here with one question: why is it that bind/named does not evolve to a really useable nameserver for the most use-cases _today_, but instead gets more unusable with every new release? I mean, sure you can use it perfectly, only not good if hosting hundreds or thousands domains - only this small change I just described lets your config file grow massively -, only not good if you want to implement something like blacklists, not good for an adblocker and so on. But all that would be dead easy to do, iff really wanted. So why is it, that there is no global way of defining default zone definitions which are only overriden by the actual zone definition? Why is there no way to define a hosts-type-of-file with an URL-to-IP list? Do you really want people to define 50.000 zones to perform adblocking? Configs have to be reloaded every now and then, is there really no idea how to shorten things a bit? Don't get me wrong, bind is great (ok, collapsing during runtime since last 2 updates, but ...). Nevertheless there are some things that can be enhanced quite a bit. -- Regards, Stephan von Krawczynski ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
