Re: gthread: how many cores do I have?
On 04/04/2010 03:34 PM, Pavel Machek wrote: And then the valid question is... should the api also count virtual cpus from hyperthreading (aka smt?)? BOTH should be available. If we're spinning up threads to perform some processing, then we need to count those virtual cores. But if we're starting a child program to perform some processing, then we need to know the count of real cores instead. Actually, SMT machine can execute threads from different processes at the same time; so you should use number of virtual processors for children, too. Posters you are responding to is pointing out that there is a difference between how many threads can execute simultaneously, and how many threads can expect to have full access to a machine core while they execute. The early implementations that assumed one virtual core = one physical core, would exhibit very bad performance characteristics if they tried to schedule two tasks to the same physical core on a regular basis. For example, if both are trying to do floating point operations, and the floating point units in the single physical core, the overall performance of both threads executing simultaneously can be even poorer than one thread executing tasks serially. Optimally - both counts should be available. How many tasks can I run simultaneously at near 100% CPU vs how many tasks can I run simultaneously at any % of the CPU. A task doing video encoding or anything that would monopolize much of the CPU, would probably use the first count, whereas something doing heavy I/O and quick transfers of data from one thread to the other might choose the latter count. Cheers, mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib uses wrong prefix for base-2 units
Benjamin Drung wrote: Am Mittwoch, den 03.06.2009, 23:53 +0100 schrieb Rui Tiago Cação Matos: 2009/6/3 Benjamin Drung : g_format_size_for_display uses the wrong prefixes for units that are counted in power of two. You may want to check the colour of the previous bike shed here http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00237.html I do not want to discuss if we should use base 10 or base 2. I only want to discuss to use the correct label for base 2. glib should should label 2^20 with MiB instead of MB (like Linux, GNU Core Utilities, GParted, GNOME Network, Pidgin, Deluge already do)! I don't think "correct" is the right word here. You want glib to adopt a modern standard that attempts to resolve a common ambiguity. Is it the correct approach? Correct approach implies that there is an incorrect approach. These terms have evolved over decades, and using the older ambiguous term vs the new defined-to-be-unambiguous term are both valid. One is not "less confusing" than the other until presenting the average person could identify the units a majority of the time. I highly doubt the average person would correctly and confidently tell me what the difference between K and Ki is. I'm a techie, and it throws *me* for a loop. "Correct"? Not at all. It's just one group of people trying to resolve an ambiguity by pushing an idea on everybody else. Has it been embraced? Not yet. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
Dan Winship wrote: Alexander Larsson wrote: On Mon, 2009-04-27 at 13:22 -0400, Dan Winship wrote: g_socket_finalize closes socket even if g_socket_close() is already closed, need to add an is_closed variable. We should also check this in all operations so that we don't accidentally call stuff on an fd that may have been reused by now. libsoup's solution here is to implement "close" as shutdown(fd,SHUT_RDWR), and only actually call close(fd) at finalization time. Whats the advantage here over close() and then setting some is_closed bit? Well, you don't need an is_closed bit, and you don't need to add a special check to every op. You just try to recv() or send() or whatever, and get back ENOTCONN (or whatever it is), and handle that normally just like if it had been the remote end that closed the connection. Leaving a file descriptor open has a cost. Calling I/O operations on a closed handle should give an E_PROGRAMMER_ERROR exception - not a system call errno. :-) In libsoup it's also important because it's thread-safe/non-racy. That may not be a relevant criterion for GSocket, although the source returned by g_socket_create_source() could create similar problems; you need to be certain that any such sources are destroyed before you call g_socket_close(), or else they could trigger falsely if the fd gets reused. Delaying close() until finalization makes that easy because then you can just have the source hold a ref on the socket to ensure that the fd doesn't get closed. It's a clever solution to the thread-safe issue - but it doesn't seem like a great solution. Leaving file descriptors open "in case" they happen to still have references floating around in memory that might be used, and waiting until the object is removed or program termination before closing the file descriptor is a bit hacky / non-scaleable. I'm sure it works great if the program only uses one or two file descriptors. Still, I can't think of a better solution for dealing with inherently buggy code that might accidentally use a file descriptor from another thread after it has been closed but before is_closed is set without locking the system down with mutexes which would become painful. So, it's either use up file descriptors in case of a broken caller, or don't use up file descriptors, but require the caller to be written sensibly. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
John McCutchan wrote: On Mon, Apr 27, 2009 at 8:40 AM, Havoc Pennington wrote: I don't really know much about modern processors or compilation, but my understanding is that the penalty for being wrong on G_UNLIKELY() is quite high. And as we know from the old "premature optimization" cliche it can be a bit hard to predict which codepaths get hit. For example, I can certainly imagine uses of IO or socket APIs where IO errors are hit reasonably often. The penalty for being wrong is the same as when the CPU makes a bad branch prediction. Hi John: On the penalty being the same - are you assuming or have you looked at the generated assembly? The last time I tried this out and analyzed gcc -S output, the case without using the "likely" hint generated code that still used a branch, but was mostly inline in both cases. When I switched to using a "likely" hint, it moved the entire "unlikely" block down to the bottom of the function. Yes, there is a bad branch prediction cost in both cases, but I think there is *also* a cache miss possibility in here. That is, if the case is truly unlikely - it's been moved out to the bottom into a different cache line, leaving more room in the calling cache line for the success case. Meaning - you really do want the "unlikely" case to be "unlikely" before you tell the compiler that it is "unlikely". The compiler will try to improve the speed of the expected case at the expense of the not expected case. It's good practice to avoid using hints unless you have a firm grasp on the odds of the branch being taken. Definitely. For this thread in specific - what might be unexpected today might become expected tomorrow. Using it only in specific cases where you know for certain the compiler has a chance of generating bad code (hopefully from analysis of the generated code or analysis of run time traces) is the best model. Let the compiler do its job for the rest. It can probably out-think you, and defining a block as unlikely might limit it's ability to reorder your code to best advantage. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Alexander Larsson wrote: Of course, given that POSIX allows this behaviour we should probably use the fsync hammer to make the risks for data loss less at least in some cases. But to argue that such behaviour from the filesystem is *good*. It boggles the mind. Anyway, this argument is over for me. XFS has long had problems with this but they have now changed so that rename overwrite is safe (they even verify this in their QA runs these days), ext4 will have patches for this in 2.6.30, and the btrfs maintainer said he will queue similar patches for 2.6.30. Well probably add the fsync to glib saving in the "file already exists" case in order to protect against this on other systems, but the main future linux filesystems at least are sane in their default configurations. I think we agree more than disagree on the principles. That is, fsync() is a sort of hammer, but it probably should be used to explicitly ensure that operation is safe, even on systems that do not have built-in protection for this particular sequence of operations. The part we disagree on, I think, is the best course of action. Fighting with each file system provider to provide a guarantee not listed in the spec, is going to be painful whether you are right or wrong. I somewhat liked the ReiserFS approach - although I never used it myself. I believe they allowed you to demarcate transaction boundaries and commit the whole transaction or not at all. This has less of the baggage that comes with fsync(), and makes the intent of the application clear to the file system. This even works for more complicated situations than the rename() case people are fussing over. All non-standard extensions of course. If you really feel that the current behaviour is wrong - the best approach would be to change the spec. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Stef Walter wrote: Mark Mielke wrote: I think fsync() is absolutely necessary to be explicit in this situation, because the application needs to assert that all data is written *before* using rename to perform the atomic-change-in-place effect. I think that anybody who thinks fsync() is unnecessary is failing to see the principle that fsync() exists solely for the purpose of guaranteeing this state, and that if you think fsync() should be unnecessary here, you should also think fsync() should be unnecessary anywhere else. Why have an fsync() at all? Why shouldn't all operations be synchronous by nature? Change the specification to force all I/O operations to be ordered that way no application developer will ever have to be surprised or ever call a synchronization primitive again. Right? fsync() was really broken on ext3. Now, all of a sudden it's "teh awesome FTW!!!" There's a reason people haven't been using it. It could take an obscene amount of time to complete depending on what you happened to be doing in elsewhere in the (multi-tasking, no less) OS. This depends on what your priority is. If your priority is to be absolutely certain that the file be intact on power failure - then you really have no other option. Most people have not had this requirement in the past. The rename to effect atomic-change-in-place is a scenario where you want a stronger guarantee. It's not about fsync() being "awesome" - it's about it being necessary to achieve this guarantee in a portable way - whatever the cost. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Morten Welinder wrote: This is crazy. People are actually advocating that thousands upon thousands of applications need to be changed. No. The crazy part is that people care so much at all. Nobody cared a year ago - why care today? This isn't a *new* problem in any way. The question as originally raised was whether glib/gio should do fsync() to be proper. Not whether to fix thousands of applications - whether to fix glib/gio. The answer is universally yes, even amongst the people who are calling the spec broken. According to the spec, fsync() is proper. If glib/gio wants to use rename as atomic change-in-place, and have the best chance of passing the "pull the plug" test, glib/gio should do fsync() before close() and rename(). The debate should be over. Debating about other file systems and some theoretical change to the spec is quite pointless in gtk-devel-list. At best, it's a legitimate rant. At worst, it's an ignorant rant. In any case, it's a rant. Fix glib/gio for the rename atomic change-in-place case specifically. Everybody is happy from a glib/gio perspective. If "thousands of other applications" are still broken - who cares? Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Alexander Larsson wrote: On Sat, 2009-03-14 at 13:38 -0400, Mark Mielke wrote: Should sed -i use fsync()? If it is promising atomic-change-in-place, then it certainly should. This is the same kind of reasoning that says its ok to do something because its specified by posix. If its not defined somewhere that sed -i must use fsync, is it then ok to lose users data. Its certainly per the spec, but its a pretty sucky system that I wouldn't want to use. If sed -i does NOT make strong promises about your data, and you trust sed -i with your data, then the person who lost the data is you, for choosing to use sed -i and trusting it with your data. If sed -i DOES make strong promises about your data, then it should absolutely use fsync() to explicitly confirm that the data is safe before doing the rename(). Blaming it on the file system for not guessing your intent is unreasonable. If you truly have such expectations, make sure that all of your mounts are synchronous and that you only use fully journalled file systems. You will probably have to reduce your expectations about overall system performance as a result. Personally, I've ALWAYS been wary of perl -i (same thing as sed -i). I have never read anywhere that it guarantees the safety of my data. I always do backup of the files before I start, and carefully check the results after I finish. But, that's me... Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Alexander Larsson wrote: On Sat, 2009-03-14 at 19:21 +0100, Alexander Larsson wrote: We all understand that its is per-spec to not guarantee data-before-metadata on rename, we're not stupid and able to read a manpage as well as you. But we still think its a bad idea and not a sign of robust software. Additionally, I'm not saying glib should not fsync in the rename case. We should of course follow the spec so that glib apps don't lose data on such filesystems. But that doesn't make such filesystem behaviour a good idea. Let's be clear about what you think is a bad idea. You think it's a bad idea for a file system to optimize a situation that is legal under the specification, but not well known by the application developers. You think that because it is commonly done, therefore the operation system and/or file system should guess what your intent is, and disable the optimization for this situation. Let's take this away from file systems for a second and to a similar situation. A lot of Java designers still don't know about the Java memory model, and how changes to variable in one thread may not be visible to another thread, or if visible, the changes may not be made in the same order unless synchronization primitives are used. This is the exact same situation. It's an allowance in the specification that is not well known by application developers, that requires careful use of synchronization primitives in order to function reliably and portably. fsync() is a synchronization primitive. In case people don't like Java here - similar things can happen in C, which is why compiler instructions like 'volatile' become necessary. It's a newbie mistake of sorts. Here's another one - people who don't check the return result of close()/fclose(). I bet if you look through many of the people who do close()/rename(), you'll find that a lot of them don't check the result of close() before they call rename(). I note that the glib/gio as referenced in the patch properly checks the result of fclose(). It's very common for applications to not check this. Will you also say that any file system where the last write() succeeds, but the final close() fails is somehow broken? You used the argument that if every application must do it - shouldn't the file system implement it? Well, why doesn't this apply to close()? Why stop at rename()? I'm not calling you stupid or saying you can't read a manpage. I am saying that any expectation on your part that file systems everywhere will one day universally implement your particular expectations is unreasonable, and not everybody agrees with you that the behaviour is wrong. I don't agree with you. The specification does not agree with you. I think fsync() is absolutely necessary to be explicit in this situation, because the application needs to assert that all data is written *before* using rename to perform the atomic-change-in-place effect. I think that anybody who thinks fsync() is unnecessary is failing to see the principle that fsync() exists solely for the purpose of guaranteeing this state, and that if you think fsync() should be unnecessary here, you should also think fsync() should be unnecessary anywhere else. Why have an fsync() at all? Why shouldn't all operations be synchronous by nature? Change the specification to force all I/O operations to be ordered that way no application developer will ever have to be surprised or ever call a synchronization primitive again. Right? I value asynchronous operations, and see synchronization primitives as being a necessary evil to allow for asynchronous operations to be possible. write() and close() never promise to store content to disk. rename() has nothing to do with content. The only way to guarantee the operation is safe is using fsync() before close(). Relying on the file system to guess your intent is unreasonable. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Alexander Larsson wrote: 2) such filesystems are broken Clearly the answer to 1 is yes. Anything else would be a disservice to our users data. However, that doesn't mean such filesystems aren't broken, in the sense that I would never let a filesystem like that near any of my data. For instance, any script doing sed -i s/foo/bar/ file.conf on such a filesystem risks ending up with a zero byte file.conf. (sed uses rename but doesn't fsync.) Is this what users except? Should that script be rewritten in C so it can use fsync? Should sed fsync? That kind of reasoning will lead to all apps implementing fsync-on-close manually, and we're then worse off than if the fs just guaranteed data-before-metadata-on-rename. Broken file system or not - all portable applications that require the file system to be in a particular state before continuing should use fsync(). rename() to accomplish the effect of atomic-change-in-place is exactly the sort of scenario where you want to guarantee a particular state before continuing, and it is exactly the sort of place where fsync() should be performed explicitly. This is without regard to whatever general safety is provided by the file system. It is wrong to conclude that fsync() is unnecessary. Should sed -i use fsync()? If it is promising atomic-change-in-place, then it certainly should. Also, if the user chooses a file system which makes fewer guarantees during a "pull the plug" test, they should be willing to live with their choices. In ext2 days and FAT16/32 days, the effects could be very bad. This thread has focused on the rename() case, often used to have the atomic-change-in-place effect. There are other cases that even your most favourite file system mode may not "protect" you from. Most file systems won't guarantee a write() order to disk, as I listed before. Heck, even if you write() 2 x 512-byte blocks in a row - you are not guaranteed that the first block will be written before the second. The system probably tunes for sequential writes to improve performance, but it's not a guarantee, and if you wrote the second before the first - you might find that the first still writes before the second. This is probably worse in the mmap() case where pages are dirtied. Which page will be flushed to disk first? The only way you know for sure is with barriers like fsync(). This promises that it will not proceed until the state has been sent to disk. File system journalling was introduced to improve file system recovery speed and accuracy. It was not introduced to provide the ACID guarantees associated with database systems. There is room for it to take this direction - but the expectation that is must is unrealistic. If a lot of code out there happens to be buggy (for example - close()/rename() from atomic-change-in-place), then the file system can try to work around these bugs, but I think it's wrote to say that it must. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Mark Mielke wrote: Putting fsync() on close() is a hack. Hmm - Looking at the patch, I don't see it doing fsync() on close() - I should have read from the beginning instead of reacting to the one person calling the file system semantics broken. :-) Definitely - any file system operations that *requires* file system integrity, should make use of fsync(). The "write new file and rename into place" is a good candidate, and fsync() should definitely be done here. Wishful thinking about some theoretical system which is both efficient, deployed on all systems everywhere, and does fully synchronous writes for both data and metadata is pointless. :-) Note that this doesn't matter what file system is used. Older non-journalled file systems had the same problem. The only file systems that are completely safe are the ones that do full journalling of all data. (Those also tend to be the slowest file systems or modes although some file systems may be breaking this trend...) Just please don't *always* fsync(). Only where it matters. As per the patch, I think it tries to do it where it matters and looks fine? Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Behdad Esfahbod wrote: Its well explained in the various discussions about this. Essentially, the metadata for the rename is written to disk, but the data in the file is not (yet, due to delayed allocation) and then the system crashes. On fsck we discover the file is broken (no data) and set the file size to 0. That's clearly a broken filesystem (screw standards. If it doesn't do what users expect, it's broken). Why work around it in gio? Have the filesystem guys "fix" it for whatever that means. All we need the few major distros handling it properly. There are different definitions of broken. I might consider it "broken" if my glib/gio application which writes out thousands of little files and suddenly starts taking twice as long as my Perl program. fsync() has a real measurable cost. The documentation for the file systems is usually quite clear, although people may not understand it. When a file system such as ext3 offers different journal modes, it's presumed that the user understands the effect of their choice. It the user must be absolutely safe - they should use 'journal' mode - but this may be slow, as all data is written to disk at least twice. If 'ordered' mode is used, this means they are willing to accept lesser guarantees for increased performance. The ext3 'ordered' mode works pretty well - data before metadata, and metadata updates are ordered. But - it's not perfect! What order is the data written in? Do you intend to patch glib/gio if somebody reports that glib/gio used write() to one part of a file, then another part of a file, then pulls the plug, and is able to prove to you that it is possible for the second write to finish while the first write hasn't started? Will you call it absolutely broken and demand a file system fix? The ext3 'writeback' mode provides even fewer guarantees. Meta data is ordered, data is not. The behaviour you are talking about right now seems to be 'writeback' mode (not sure - I guess ext4 is doing 'writeback' mode by default otherwise I don't understand the complaint?). Tell your users if they expect the right thing to use 'journal' mode. glib/gio cannot and should not be second guessing the file system choice of the user. Taking this argument to its extreme, you may as well run fsync() after every single I/O operations that performs a modification. This would be horrible for performance, and the user has this capability already by defining the file system as completely journalled and using synchronous writes. They don't need glib/gio to simulate this. My opinion is that glib/gio shouldn't be doing this stuff. The problem is not with glib/gio. glib/gio should offer an fsync() wrapper (not sure if it does or not - I don't use it), such that applications with special requirements such as a database application, can use fsync() at strategic points where the application wishes to make greater promises than the file system. A database file applies here. For databases specifically, fsync() on close() is not good enough. fsync() needs to be done at any point that the data needs to be consistent and written to disk before the application continues to do another write(). glib/gio cannot guess where these points are. Putting fsync() on close() is a hack. Just my opinion. :-) Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: my ongoing fantasy of garbage collected C programming
Tim Janik wrote: AFAIK, no one has tried to make boehm GC really work with glib & gtk+ programs so far. The "gc friendly" mode that glib has in general just zeros-out certain memory portions before calling free(), so GC-alike leak detectors like e.g. valgrind can do a more accurate job. Depending on how clever your GC implementation is, I'd actually expect quite some real world problems with it trying to "collect" glib memory. E.g. GLib only stores pointers into the _middle_ of fundamental GType nodes (not the node start) and with GSlice provides its own allocator that cannot be replaced with GC collection (the memory pages allocated by gslice.c:allocator_memalign are also not pointed to directly, a pointer to an admin structure at the page tail is kept instead). A conservative collector that makes no assumptions about where the pointers are (I believe this is the default Boehm GC mode?) will not have any problem with the above. I foresee limited benefit of GC for Gtk+/Glib at this time, as many of the data structures are reference counted today, and reference counting PLUS garbage collection is certainly slower than reference counting alone... :-) Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GHashTable and const
BJörn Lindqvist wrote: Yes, i'm aware of that. Const variables just seem to grow like mushrooms around const-accepting functions and those inevitably cause trouble. Inside the function with a const parameter, that parameter also only has to be passed to const parameter functions. That is another case where warnings has to be fixed with irritating casts. Why would a function taking a const parameter be calling a function with the parameter that isn't defined to take a const? It may seem like a mushroom to you - to me it seems like a mine field *not* to use const. All compile time checking has this issue - and all compile time checks provide value. Which is worse? To realize that your supposedly const function is calling a non-const and having the compiler tell you about it? Or to not realize that your supposedly read-only function is doing modifications? I prefer to use const, because I value what it provides. That it's imperfect is not a reason to avoid it. The main issue with glib, though, is history. Most of the programming world is happy with using const, so I don't buy that the glib developers are smarter in their choice not to. The choice was wrong. But, it's water under the bridge. Life goes on. The question is now whether it's worth it to change - and I suspect the answer is no. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GHashTable and const
Havoc Pennington wrote: I'm not a GTK maintainer, but one problem with this is backward compatibility. Adding const can certainly break previously-working code, especially C++ code. This was an issued once faced when people migrated from K&R C to ANSI C. Nothing wrong with having a gconst that is defined to nothing on systems that do not support it, or for compatibility. Not saying it should be done or not - but if it is done, this isn't the first time in history this compatibility issue has been faced. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GHashTable and const
Morten Welinder wrote:
"const" in C does not propagate as usefully as you would like. Therefore,
the following sniplet is not violating C rules:
struct Foo { int *x; };
int foo (const struct Foo *p) { *(p->x) = 1; }
I don't think most languages propagate a "const"-like type. However, at
least in theory, I think const would allow:
struct Foo p;
p->x = malloc(sizeof(int));
foo(p);
printf("%d\n", *(p->x));
To optimize the second p->x to be equal to a value from a register used
during the initial assignment. If called in a tight inner loop with many
iterations, the effect could be more significant.
While I cannot change p->x, I can change what
That said, it still wouldn't hurt to add const for cases like g_hash_table_size
I prefer prototypes to document intent as best as possible, even if the
language does not allow for a direct match between intent and actual
implementation. :-)
But, this is probably a waste of a thread as glib has done what glib has
done.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Paul Pogonyshev wrote: Mark Mielke wrote: If I choose to download Oracle, and connect a GPL product to Oracle *without redistribution*, there is nothing the FSF can do to stop me. They actually don't. GPL applies only if you distribute modified or unmodified result. At home (or within your company if you are an employee) you can do anything you want. Yep - exactly. And system libraries fall into this category, because it is not distributed with the product (GPL is not derived from the system libraries - they merely use it). I, the end user, am using them together. The "special exception" is stating the obvious. It's not reducing any confusion except to say "of the many uses we cannot reasonably prevent, linking to system libraries is definitely one of them." Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Mark Mielke wrote: > If I choose to download Oracle, and connect a GPL product to Oracle > *without redistribution*, there is nothing the FSF can do to stop me. I should qualify - I went down a path I thought Dominic was leading but away from the Gtk topic. The above is grey in terms of whether it applies to Gtk. It comes down to whether use of a published interface constitutes creating a derived work, and whether a license can reasonable prevent the use of one component to be used with another. Imagine you were given a brand new BWM on the condition that you cannot use anything but BWM parts in it. You take the BWM, and ignore the agreement. In a court of law, would the court system truly require you to give the BWM back? I doubt it. They would laugh at your accuser. Not all agreements are binding in a court of law. In Canada (not sure about the US), even a signature on a document is not legally binding (although it may influence the judge). This is pretty grey and goes to my previous post. Suffice it to say that nearly everyone posted thus far (probably including me) is likely to be incorrect unless by accident. Even referring to wording of the license or tables on the FSF web site that purport to declare compatibility are NOT conclusive, as these are opinions, and in the case of the FSF, they are opinions with an agenda. The GPL is not well tried in a court of law, and laws change from country to country. That said, Gtk is using the GPL license, and the FSF should be accountable for problems they create through the publishing of licenses they author. The Gtk community representatives should be active in the community that is defining the LGPL3 (or GPL3 although this may be late) to ensure that the needs of the Gtk community are fulfilled. Walking in late as a "what does this mean to me? oh oh..." is somewhat irresponsible. :-) Sorry. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Dominic Lachowicz wrote: On Tue, Mar 18, 2008 at 8:46 PM, Mark Mielke <[EMAIL PROTECTED]> wrote: Jean Bréfort wrote: > Windows API (and may be DirectX) is a special case, because you can't > write a Windows program without using it. > It's not a special case. There is certainly no reference to the Windows API in the GPL or the LGPL. The only license that matters when it comes to deciding whether or not you can link to the Windows API, is the license that Microsoft grants you for the Windows API. The GPL cannot dictate how you may or may not make use of the Windows API. I do not see a clause anywhere that states "you may never derive from, or make us of, a non-GPL or non-LGPL library." It is always the product you are deriving from, or making use There's no explicit reference to the Windows API in the GPL or LGPL, but there's an important clause in both the GPLv2.0 and LGPL2.1: "However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. " In this case, the Windows API and DirectX would be considered "normally distributed major components" of the operating system, and thus be ok to use in a L/GPL licensed work. This is open to interpretation - but the exact wording of the license does not necessarily match the legal rights a person has in terms of copyright law, and the ability for a copyright to limit the use of the product. In my opinion, the "special exception" is not part of the license, but stating the obvious. I don't believe the GPL can stop me from linking with non-GPL software, as long as I don't distribute my change as a derived work. Copyright law is about distribution rights. There are efforts to change this, such as the digital protection groups, who are trying (and have succeeded?) in making it illegal to make some uses of products, such as reverse engineering. If I choose to download Oracle, and connect a GPL product to Oracle *without redistribution*, there is nothing the FSF can do to stop me. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Jean Bréfort wrote: > Windows API (and may be DirectX) is a special case, because you can't > write a Windows program without using it. > It's not a special case. There is certainly no reference to the Windows API in the GPL or the LGPL. The only license that matters when it comes to deciding whether or not you can link to the Windows API, is the license that Microsoft grants you for the Windows API. The GPL cannot dictate how you may or may not make use of the Windows API. I do not see a clause anywhere that states "you may never derive from, or make us of, a non-GPL or non-LGPL library." It is always the product you are deriving from, or making use of, whose license defines what you are allowed to do or not allow to do. The GPL "virus" is in the form of a copyright. It prevents people from copying, which includes distribution of the product and derivations of the product. Accessing a non-GPL library is not copying of GPL code. Using the published interface of another library is not copying of GPL code. If such were the case, it would be impossible to use GPL software on anything except for a full-stack GPL system, arguably including the hardware. It would be ridiculous and impractical for everybody, including the FSF. The GPL cannot prevent you from linking a given product with another library. However, the GPL can force all products that are derived from a GPL product, to themselves be GPL products. Library use, that of linking at run time, is a grey zone in terms of whether a product is derived from the library, or merely makes use of it. Most interpretations I have read consider it a violation if a non-GPL product links to a GPL product, unless the use of the GPL library is one of at least two options, and effort is made to distance oneself from any conclusion that the product might require the use of a GPL library or that the product will function better with the GPL library. Messy. Anyways - I hope this helps. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Tommi Komulainen wrote: > IANAL and all, but here are a few points for consideration based on my > experience after being exposed to Nokia legal machinery. > > 1. Changing the wording from "version 2 or later" to "version 3 or > later" will remove the "2 or later" option. To my understanding > changing the terms of the license text counts as relicensing. > The license explicitly allows for this, though. The license allows for itself to be relicensed, providing the new license is blessed by the FSF. There would be no value to stating "version 2 or later" if it meant "version 2 only". Anybody - including you or I, may privately take a GPL v2 piece of software, change the license to GPL v3 (without even notifying the original authors), and distribute all further modifications under GPL v3 only. This clause made me uneasy when I first read it 10 to 20 years ago. The idea that if I distribute a program under GPL v2, the FSF could be taken over by somebody worse than Richard Stallman, create a new license stating anything it wishes (as long as it is called GPL v2 or later), and redistribute all my software under this new license. This is why the GPL is labeled a virus by some. I am not up-to-date on LGPL v3. What I state above is for GPL v3 only. > 2. Due to the (L)GPLv2 and v3 incompatibility everything above glib > (or gtk+) would have to be distributed under v3, which as > already noted is a problem if you have any v2 only sources in > any glib application. It would be a significant disruption for > distributors to make sure all the licenses are OK. > It is only a problem if these v2 programs require updates. If the v2 programs stick to v2 interfaces, there is no issue. > 3. Companies are vary of GPLv3. It took a long time to begin to > understand GPLv2, GPLv3 is still relatively more intimidating. > The GPL has always been scary. The people who were ever comfortable with it, probably didn't read the fine print. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
