Which is why Phroggy is asking if that detail would have been omitted if the lady was tall. Is it really that hard to keep up with a thread for 30 seconds?
Very well, since you clearly have legal expertise I won't dismiss your ideas, but take care not to confuse patent law with copyright law. Perhaps there's a good reason there's no such general patent license.
I don't think your litmus test is reasonable. Because of the "big 3" video vendors signed on, virtually all modern Linux desktops will end up with OpenCL supported, and in the case of Intel and perhaps AMD, with open source drivers. nVidia will hold out open sourcing, but not many people will care because the performance will be good anyway.
Having an independent implementation here is not important, and not at all useful, given that you'd be independent for the sake of it, rather than letting the vendor write you an open source driver!
It's really funny you should say that and not recognize what the GPLv3 does in this area. It still hinges on a company actually distributing GPLv3 code, after which they cannot assert patent claims against the users they just gave the code.
It also helps null the Novell-Microsoft deal by making any GPLv3 software Novell or Microsoft distribute perfectly free to use by any other distribution as well. The partnership can't use the work of FOSS developers against them any more.
I think the point is to prosecute those who create the depictions, not the characters themselves. I suspect the sentence for drawing a comic of a rape is milder than the sentence for committing a similar rape, but if it's handled at all like copyright violation is today, maybe comic authors get the death sentence. On that note, most of Japan will have to be extradicted.
Is there a solution to the Linux guest disk IO slowdown on FreeBSD qemu? kqemu or not, I can't get a usable Linux guest. Even a minimal Debian install takes almost an hour, as opposed to 5 minutes in KVM on Linux. This bug has been reported for over a year, and it's believed to be a qemu bug, but the same version on Linux is unaffected or already fixed.
You probably don't need to create your own refcounting scheme now that Boost shared_ptr is being folded into the official standard. It uses atomic instructions (or optionally, plain old integer) and custom deleters, so it can cover virtually any use-case, or be easily adapted to your own.
You can partly solve cyclic references using weak references. As long as you have some top-level entry into the cycle, that can be the strong reference, and the pure cycle can be a weak reference, and you're pretty much set.
He means that if you need to do a bunch of serial tasks on a number of inputs (say, decode/filter/encode a bunch of videos), you can have the decoder, filter and encoder all running in parallel on different streams of videos. However in general it's just easier to run N parallel streams where N is at least as much as the core count. Pipelining has its uses but my example isn't one of them.
Those chips are about as intelligent as a rubber band. There's currently just no way to implement sane wear filesystem-independent wear levelling in a tiny chip like that. In fact, ignoring the hints of the filesystem in general is a terrible approach, since the filesystem knows best how it can safely move its data around, and a flash-optimized file system is well worth using.
It's kind of scary that even otherwise technically capable users still don't know you can permanently and reliably move the My Documents directory without any third party extensions, and yes, have it come up correctly in file dialogs and user32 calls.
Also, hard link doesn't mean what you think it means. A hard link can only add a reference to a file within the same volume. If it's across volumes, it's a soft link.
Actually what do you use for VMing on a FreeBSD host? I thought the only thing that worked was un-accelerated qemu. KVM is barely usable, Xen dom0 and VirtualBox aren't even betas. I'd use FreeBSD for a lot more hosts if it at least supported kvm properly, and that project is nowhere near done.
Are you just trying to prove a point? This is just sad. Everyone informed in the matter knows that this is how it should be done, based on real bug reports and real testing, by the authors and maintainers of the platform itself, as well as the industry at large. Just accept it and move on. What you're saying is far from demonstrably true, it's been regularly demonstrated false.
I could understand your resistance if this was some huge change, but all you are required to do is move work from the constructor to run(), and in fact you can even do this as a wrapper in main, assuming your entry class already implements Runnable:
public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
public void run() {
new BrokenApp().run();
}
}); }
This kind of fix is not optional, it's just as important as any other thread synchronization. Yes it might not break often in your particular test setup, but incorrect usage has been known to fail on a variety of platforms, so why risk it?
I think you just can't read. Just a couple of paragraphs down in the blog, you get the updated rule which Sun now universally follow, and every maintained application is expected to follow as well. It solves real problems on real platforms, including Sun's own Solaris. Your theory can't disprove their practice.
I have lots of my own anecdotal evidence of seemingly simple Swing GUIs (and even JOGL GUIs with a heavyweight AWT components) having non-deterministic bugs when the event loop is not used correctly, even just for initialisation. So I adhere to the rule and I have no further bugs, and I advise all friends and colleagues to do the same, and they report their bugs are fixed too. It can't be any more convincing than that.
My apologies, I meant invokeLater. Otherwise my point stands and I'm sure it's worth fixing all your code, since it's unlikely this is the only time you've made this mistake.
I don't know if you're just being ironic, but your Java code isn't even correct with respect to AWT/Swing threading semantics. You're supposed to create Swing objects only in the AWT event loop thread, using EventQueue.runLater() or one of its wrappers. I guess you're using Thread.sleep() later to get around the threading bugs you just created, but since your code is uncommented it's hard to tell.
ext4 doesn't really exist yet, and it's definitely not up to the level of ZFS. It's pretty much just a minor revision on ext3, which is admittedly generations behind. btrfs may compete with ZFS, but only in a few years when it's actually ready.
If you're doing any math on 64 bit integers, suddenly 64 bit mode is orders of magnitude faster because it's not hacking together the results from individual 32-bit operations. This can make a substantial difference for some applications, and a great case study is AES.
"Work with the vendors on a standardized interface for common features, then require those features to be implemented."
That's the spot-on description of what OpenGL has been from day one. There's a whole certification process to ensure compliance. That's why it's available on all platforms, all video cards, and even some software renderers. DirectX is available only on Windows and supported only by select vendors who could pony up for the development cost. You call that standardised?
The fact is, OpenGL is used on modern X.Org desktops to provide a much richer 3D workspace than Vista or OSX, using open source or even proprietary drivers. That validates the standard and implementations then and there. The proof of the pudding is in the eating, not in Microsoft propaganda.
I have no idea what you're talking about. I have never had trouble installing plugins. I run more languages and features through Eclipse than NetBeans has in all of its core and plugins combined, simply because the community is so much larger and more effective.
Whatever theoretical advantage NetBeans has because of its single-source packaging is completely irrelevant if it just doesn't support features you need, or an entire popular language like Python (only through plugins, so it's back on equal footing with Eclipse, only the NetBeans plugin is, as usual, much worse). There's just no point arguing about the supposed superiority of a platform for use-cases it doesn't even support anyway.
The point is that the variety of open distributions give you the choice between mature and immature. Debian has long been an extremely reliable distribution and I hope it stays that way. There's no point in Debian existing if its releases are buggy like Ubuntu's. They should take as much time as they need to get it stable, because that's what Debian is for in the first place.
Why not fire it up in a VM and see? Even Ubuntu uses Debian's installer as its "Alternate" installer, the preferred method for power users. It's a pretty good product now.
And I agree, the old installer sucked. Especially dselect. Argh.
All of those features, and many more, are available in Eclipse directly or through extensions. Take another look. Well, unless you're so happy you don't see any possibility of switching back anyway.
Slashdot Mirror
Which is why Phroggy is asking if that detail would have been omitted if the lady was tall. Is it really that hard to keep up with a thread for 30 seconds?
Very well, since you clearly have legal expertise I won't dismiss your ideas, but take care not to confuse patent law with copyright law. Perhaps there's a good reason there's no such general patent license.
I don't think your litmus test is reasonable. Because of the "big 3" video vendors signed on, virtually all modern Linux desktops will end up with OpenCL supported, and in the case of Intel and perhaps AMD, with open source drivers. nVidia will hold out open sourcing, but not many people will care because the performance will be good anyway.
Having an independent implementation here is not important, and not at all useful, given that you'd be independent for the sake of it, rather than letting the vendor write you an open source driver!
It's really funny you should say that and not recognize what the GPLv3 does in this area. It still hinges on a company actually distributing GPLv3 code, after which they cannot assert patent claims against the users they just gave the code.
It also helps null the Novell-Microsoft deal by making any GPLv3 software Novell or Microsoft distribute perfectly free to use by any other distribution as well. The partnership can't use the work of FOSS developers against them any more.
I think the point is to prosecute those who create the depictions, not the characters themselves. I suspect the sentence for drawing a comic of a rape is milder than the sentence for committing a similar rape, but if it's handled at all like copyright violation is today, maybe comic authors get the death sentence. On that note, most of Japan will have to be extradicted.
Australians all let us rejoice, for bhfaighfear young and free..
Just doesn't have the same ring to it.
It was the US that gave Japan its economic stimulus decades ago. It seems kind of ironic having to apply the same strategy to itself just to catch up.
Is there a solution to the Linux guest disk IO slowdown on FreeBSD qemu? kqemu or not, I can't get a usable Linux guest. Even a minimal Debian install takes almost an hour, as opposed to 5 minutes in KVM on Linux. This bug has been reported for over a year, and it's believed to be a qemu bug, but the same version on Linux is unaffected or already fixed.
You probably don't need to create your own refcounting scheme now that Boost shared_ptr is being folded into the official standard. It uses atomic instructions (or optionally, plain old integer) and custom deleters, so it can cover virtually any use-case, or be easily adapted to your own.
You can partly solve cyclic references using weak references. As long as you have some top-level entry into the cycle, that can be the strong reference, and the pure cycle can be a weak reference, and you're pretty much set.
He means that if you need to do a bunch of serial tasks on a number of inputs (say, decode/filter/encode a bunch of videos), you can have the decoder, filter and encoder all running in parallel on different streams of videos. However in general it's just easier to run N parallel streams where N is at least as much as the core count. Pipelining has its uses but my example isn't one of them.
Those chips are about as intelligent as a rubber band. There's currently just no way to implement sane wear filesystem-independent wear levelling in a tiny chip like that. In fact, ignoring the hints of the filesystem in general is a terrible approach, since the filesystem knows best how it can safely move its data around, and a flash-optimized file system is well worth using.
It's kind of scary that even otherwise technically capable users still don't know you can permanently and reliably move the My Documents directory without any third party extensions, and yes, have it come up correctly in file dialogs and user32 calls.
Also, hard link doesn't mean what you think it means. A hard link can only add a reference to a file within the same volume. If it's across volumes, it's a soft link.
Actually what do you use for VMing on a FreeBSD host? I thought the only thing that worked was un-accelerated qemu. KVM is barely usable, Xen dom0 and VirtualBox aren't even betas. I'd use FreeBSD for a lot more hosts if it at least supported kvm properly, and that project is nowhere near done.
Are you just trying to prove a point? This is just sad. Everyone informed in the matter knows that this is how it should be done, based on real bug reports and real testing, by the authors and maintainers of the platform itself, as well as the industry at large. Just accept it and move on. What you're saying is far from demonstrably true, it's been regularly demonstrated false.
I could understand your resistance if this was some huge change, but all you are required to do is move work from the constructor to run(), and in fact you can even do this as a wrapper in main, assuming your entry class already implements Runnable:
public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
public void run() {
new BrokenApp().run();
}
});
}
This kind of fix is not optional, it's just as important as any other thread synchronization. Yes it might not break often in your particular test setup, but incorrect usage has been known to fail on a variety of platforms, so why risk it?
I think you just can't read. Just a couple of paragraphs down in the blog, you get the updated rule which Sun now universally follow, and every maintained application is expected to follow as well. It solves real problems on real platforms, including Sun's own Solaris. Your theory can't disprove their practice.
I have lots of my own anecdotal evidence of seemingly simple Swing GUIs (and even JOGL GUIs with a heavyweight AWT components) having non-deterministic bugs when the event loop is not used correctly, even just for initialisation. So I adhere to the rule and I have no further bugs, and I advise all friends and colleagues to do the same, and they report their bugs are fixed too. It can't be any more convincing than that.
My apologies, I meant invokeLater. Otherwise my point stands and I'm sure it's worth fixing all your code, since it's unlikely this is the only time you've made this mistake.
I don't know if you're just being ironic, but your Java code isn't even correct with respect to AWT/Swing threading semantics. You're supposed to create Swing objects only in the AWT event loop thread, using EventQueue.runLater() or one of its wrappers. I guess you're using Thread.sleep() later to get around the threading bugs you just created, but since your code is uncommented it's hard to tell.
ext4 doesn't really exist yet, and it's definitely not up to the level of ZFS. It's pretty much just a minor revision on ext3, which is admittedly generations behind. btrfs may compete with ZFS, but only in a few years when it's actually ready.
If you're doing any math on 64 bit integers, suddenly 64 bit mode is orders of magnitude faster because it's not hacking together the results from individual 32-bit operations. This can make a substantial difference for some applications, and a great case study is AES.
I think you have it all backwards.
"Work with the vendors on a standardized interface for common features, then require those features to be implemented."
That's the spot-on description of what OpenGL has been from day one. There's a whole certification process to ensure compliance. That's why it's available on all platforms, all video cards, and even some software renderers. DirectX is available only on Windows and supported only by select vendors who could pony up for the development cost. You call that standardised?
The fact is, OpenGL is used on modern X.Org desktops to provide a much richer 3D workspace than Vista or OSX, using open source or even proprietary drivers. That validates the standard and implementations then and there. The proof of the pudding is in the eating, not in Microsoft propaganda.
I have no idea what you're talking about. I have never had trouble installing plugins. I run more languages and features through Eclipse than NetBeans has in all of its core and plugins combined, simply because the community is so much larger and more effective.
Whatever theoretical advantage NetBeans has because of its single-source packaging is completely irrelevant if it just doesn't support features you need, or an entire popular language like Python (only through plugins, so it's back on equal footing with Eclipse, only the NetBeans plugin is, as usual, much worse). There's just no point arguing about the supposed superiority of a platform for use-cases it doesn't even support anyway.
You mean OpenGL? I hear it worked for the rest of the industry.
The point is that the variety of open distributions give you the choice between mature and immature. Debian has long been an extremely reliable distribution and I hope it stays that way. There's no point in Debian existing if its releases are buggy like Ubuntu's. They should take as much time as they need to get it stable, because that's what Debian is for in the first place.
Why not fire it up in a VM and see? Even Ubuntu uses Debian's installer as its "Alternate" installer, the preferred method for power users. It's a pretty good product now.
And I agree, the old installer sucked. Especially dselect. Argh.
All of those features, and many more, are available in Eclipse directly or through extensions. Take another look. Well, unless you're so happy you don't see any possibility of switching back anyway.