A 'massive partition' of random data is no good for hiding a key.
A drive of say... 500GB has about 500 trillion offsets at which you can hide a key, (if the key is 256bit then the last 31 bytes are invalid starting offsets... but that is negligible).
Unfortunately 500 trillion is only a ~39 bit number, so you've just hidden a 256bit key under a 39bit protection scheme, which is well within feasibility of bruteforcing.
Or he could request firtname.lastname.com have its own set of nameserver (NS) records delegated to a DNS provider of his choosing, and have a contract drawn up.
Another option is just to forget the.com and go register the dot name
For Windows XP, C:\Windows\I386\ usually contains the installation (MS calls them 'source') files from the I386 directory of the original Windows OEM installation disc. You can use this directory to re-author an OEM disc with a little effort. Use something like WinMerge to compare this directory to a 'reference disc' (Pirate Bay) and then sort it out. Use Jelly Bean CD key finder to extract the original CD key from the registry. I've done this a handful of times and it works a treat, arguably piracy is just easier though.
Windows Vista is a doddle in comparison. Grab a copy of ABR (Activation Backup and Restore), backup your OEM activation, use any old Vista disc (Pirate Bay again) to reinstall the same edition of Vista (leaving the CD key blank during installation) and then restore activation from your backup.
I don't think there is anything illegal about the above methods.
If you want to write a non-free application based on Qt, you need to purchase a commercial license. Presumably you're making money off your application
Here you are assuming "non-free" always means non-free-gratis as well non-free-libre. The critical point for me is, noone can use Qt to write closed source freeware and, personally, I just don't see what harm it does to the development of Qt for a closed source freeware application to use it.
To apply the dual licensed/commercial model to the lemons metaphor: Trolltech see the situation as: "Hey you should either pay me for them lemons or give your lemonade away for free like I give away my lemons!" whereas I see things as "Hey, as long as you don't expect or demand an unfair amount of free lemons from me (i.e. more than anyone else), feel free to make a tidy profit selling that lemonade, and if you want to help me grow more lemons later, it would be very much appreciated, because I just enjoy growing lemons!".
I don't think Qt's *commercial* success has anything to do with it being dual licensed, and everything to do with it being a better product than GTK+ (IMHO, of course). I'm not bashing their model, it is a good one and benefits both Free Software (free-libre) and helps create an all round better GUI toolkit, it is just that idealogically, IMHO, it would be better if it also free-gratis for other people making free-gratis-ware. That said, I don't know how this would work when companies like Opera give away their desktop product (which uses Qt) but obviously make money licensing browser technologies in the mobile and game console space...
Umm...yeah except Qt is developed by a for-profit company (Trolltech). The KDE project can surely use support, but in the context of financial donations, why even mention your preferences on Qt vs GTK+?
Can anyone tell me why you would possibly want to plug CoreAVC into MPlayer and Xine or GStreamer based applications when these already have native H.264 playback?
For decoding, ffmpeg (Which has a code base used throughout a tonne of the Free Software world) already has a decent decoder, and for encoding we have x264 (Developed by the folks behind VLC)...
I know that CoreAVC claims to be super optimised, but is it really that much better? I have always assumed that they were just milking those Windows users that didn't know of ffdshow.
Maybe the rock-dwelling alien bastard driving it won't appreciate our tin-tech peppering his windshield and will take the time to just vaporise us nicely, as to allow their cargo vessel to pass effortlessly through the resulting cloud... It should be quite a sight, I can't wait to see it.
To claim my 'I told you so' moment, I place odds of this happening something between 1 in 1000 and 1 in 1017.
x86_64 is more of a cleanup to the aging x86 ISA. Not only does it future proof the architecture against big memory requirements but it also does away with ancient segmented addresses, provides more CPU registers (leading the the possibility of more specialized register operations, I assume) and generally allows people to break ABI *as a matter of course* which is great because on AMD64 arch's you can *assume* the presence of MMX, SSE, and SSE2 instruction sets. Even Microsoft, anally retentive back-compat evangelists, took the opportunity in Windows XP x64 and Windows 2003 x64 Server to introduce further kernel mode memory protections ('PatchGuard')
No x86 software, *including drivers*, should be shipping in both 64bit and 32bit binary form, all of the problems you mention with 64bit are essentially proprietary software exclusive btw, and just highlight the highly broken software ecosystem Microsoft Windows has fostered.
...on Windows are they able to ensure that the video is not redistributed.
Yep...except they aren't. Windows Media DRM can be stripped (on Windows) losslessly with 2 clicks of a mouse. It is nothing more than a waste of resources even bothering with it.
GNOME (Or more accurately GTK+, glib, Cairo and X) has got faster steadily since the GNOME 2.12 days. GTK+s UI's are just as snappy for me as Qt equivalents. I noticed significant improvements after several video/X driver updates and updates to Cairo 1.4.x (from 1.2.x).
None of the workarounds you describe will work with x64 editions of Vista SP1, or for "boot drivers" in x86. I do plan to continue develop of the driver, but I doubt I will ever be able to get it signed using anything but the test certificate from MS. Still, will find out during testing...
...which doesn't change the fact that this Slashdot news item is poorly reported and inciting a massive flame fest, which was the main target of my post.
My opinion: As others have pointed out you can load GPL'd NDIS drivers compiled to Windows DLL's with NDIS Wrapper, what the user chooses to do with it isn't covered by the GPL, provided they don't distribute non-compliant blobs with NDIS Wrapper as a package.
I bet the number of GPL'd NDIS drivers for Windows can be counted on one toe. I myself started writing an NDIS 6 driver for a chipset that has no native Vista drivers (although the NDIS 5 XP driver works on Vista x86) but have recently lost interest, despite almost completing basic functionality, because I realised I will never be able to use it under Vista x64 due to the OS's draconian driver signing policy..which cannot be disabled.
Quite frankly, my position on this has always been that the GPLv2 explicitly covers _derived_ works only, and that very obviously a Windows driver isn't a derived work of the kernel. So as far as I'm concerned, ndiswrapper may be distasteful froma technical and support angle, but not against the license.
> This particular crack has/will be defeated by SP1.
Yes this particular crack (by Paradox) has been fixed in SP1. The thing is, SP1 only blacklists some very specific 'soft mods' (Boot loader replacement designed to emulate an OEM issued BIOS SLIC table and trick Vista into accepting your machine as an OEM product). It is widely known that there are still many others out there, even ones dating from the middle of last year, that work just fine with SP1.
Slashdot Mirror
That would only be a trademark issue, not a copyright infringement.
Mirror for the thread:
http://thread.gmane.org/gmane.linux.kernel/811167/focus=811699
Thunderbird 2 is effected by this, but afaik there is no Thunderbird 3.
Is this is a death sentence for the project?
A 'massive partition' of random data is no good for hiding a key.
A drive of say... 500GB has about 500 trillion offsets at which you can hide a key, (if the key is 256bit then the last 31 bytes are invalid starting offsets... but that is negligible).
Unfortunately 500 trillion is only a ~39 bit number, so you've just hidden a 256bit key under a 39bit protection scheme, which is well within feasibility of bruteforcing.
Or he could request firtname.lastname.com have its own set of nameserver (NS) records delegated to a DNS provider of his choosing, and have a contract drawn up.
Another option is just to forget the .com and go register the dot name
For Windows XP, C:\Windows\I386\ usually contains the installation (MS calls them 'source') files from the I386 directory of the original Windows OEM installation disc. You can use this directory to re-author an OEM disc with a little effort. Use something like WinMerge to compare this directory to a 'reference disc' (Pirate Bay) and then sort it out. Use Jelly Bean CD key finder to extract the original CD key from the registry. I've done this a handful of times and it works a treat, arguably piracy is just easier though.
Windows Vista is a doddle in comparison. Grab a copy of ABR (Activation Backup and Restore), backup your OEM activation, use any old Vista disc (Pirate Bay again) to reinstall the same edition of Vista (leaving the CD key blank during installation) and then restore activation from your backup.
I don't think there is anything illegal about the above methods.
For me it is webcam/video messaging.
My webcam is supported through a shoddy out of tree kernel driver that produces unusable images with terrible picture quality.
s/you exert/your extract/
If you had actually bothered to read the article properly you would have considered that the sentence before you exert begins:
Please downmod parent.
Here you are assuming "non-free" always means non-free-gratis as well non-free-libre. The critical point for me is, noone can use Qt to write closed source freeware and, personally, I just don't see what harm it does to the development of Qt for a closed source freeware application to use it.
To apply the dual licensed/commercial model to the lemons metaphor: Trolltech see the situation as: "Hey you should either pay me for them lemons or give your lemonade away for free like I give away my lemons!" whereas I see things as "Hey, as long as you don't expect or demand an unfair amount of free lemons from me (i.e. more than anyone else), feel free to make a tidy profit selling that lemonade, and if you want to help me grow more lemons later, it would be very much appreciated, because I just enjoy growing lemons!".
I don't think Qt's *commercial* success has anything to do with it being dual licensed, and everything to do with it being a better product than GTK+ (IMHO, of course). I'm not bashing their model, it is a good one and benefits both Free Software (free-libre) and helps create an all round better GUI toolkit, it is just that idealogically, IMHO, it would be better if it also free-gratis for other people making free-gratis-ware. That said, I don't know how this would work when companies like Opera give away their desktop product (which uses Qt) but obviously make money licensing browser technologies in the mobile and game console space...
Umm...yeah except Qt is developed by a for-profit company (Trolltech). The KDE project can surely use support, but in the context of financial donations, why even mention your preferences on Qt vs GTK+?
Can anyone tell me why you would possibly want to plug CoreAVC into MPlayer and Xine or GStreamer based applications when these already have native H.264 playback?
For decoding, ffmpeg (Which has a code base used throughout a tonne of the Free Software world) already has a decent decoder, and for encoding we have x264 (Developed by the folks behind VLC)...
I know that CoreAVC claims to be super optimised, but is it really that much better? I have always assumed that they were just milking those Windows users that didn't know of ffdshow.
Java is JIT'd in a VM, this Flash exploit is essentially about busting through VM's. There is vague linkage here.
Maybe the rock-dwelling alien bastard driving it won't appreciate our tin-tech peppering his windshield and will take the time to just vaporise us nicely, as to allow their cargo vessel to pass effortlessly through the resulting cloud... It should be quite a sight, I can't wait to see it.
To claim my 'I told you so' moment, I place odds of this happening something between 1 in 1000 and 1 in 1017.
x86_64 is more of a cleanup to the aging x86 ISA. Not only does it future proof the architecture against big memory requirements but it also does away with ancient segmented addresses, provides more CPU registers (leading the the possibility of more specialized register operations, I assume) and generally allows people to break ABI *as a matter of course* which is great because on AMD64 arch's you can *assume* the presence of MMX, SSE, and SSE2 instruction sets. Even Microsoft, anally retentive back-compat evangelists, took the opportunity in Windows XP x64 and Windows 2003 x64 Server to introduce further kernel mode memory protections ('PatchGuard')
No x86 software, *including drivers*, should be shipping in both 64bit and 32bit binary form, all of the problems you mention with 64bit are essentially proprietary software exclusive btw, and just highlight the highly broken software ecosystem Microsoft Windows has fostered.
GNOME (Or more accurately GTK+, glib, Cairo and X) has got faster steadily since the GNOME 2.12 days. GTK+s UI's are just as snappy for me as Qt equivalents. I noticed significant improvements after several video/X driver updates and updates to Cairo 1.4.x (from 1.2.x).
No I am afraid that is not correct. The situation is a lot more complex as of Vista SP1:
http://thebackroomtech.wordpress.com/2007/11/05/howto-disabling-driver-signing-in-windows-vista-64-bit/
None of the workarounds you describe will work with x64 editions of Vista SP1, or for "boot drivers" in x86. I do plan to continue develop of the driver, but I doubt I will ever be able to get it signed using anything but the test certificate from MS. Still, will find out during testing...
...which doesn't change the fact that this Slashdot news item is poorly reported and inciting a massive flame fest, which was the main target of my post.
My opinion: As others have pointed out you can load GPL'd NDIS drivers compiled to Windows DLL's with NDIS Wrapper, what the user chooses to do with it isn't covered by the GPL, provided they don't distribute non-compliant blobs with NDIS Wrapper as a package.
Amusing observation.
I bet the number of GPL'd NDIS drivers for Windows can be counted on one toe. I myself started writing an NDIS 6 driver for a chipset that has no native Vista drivers (although the NDIS 5 XP driver works on Vista x86) but have recently lost interest, despite almost completing basic functionality, because I realised I will never be able to use it under Vista x64 due to the OS's draconian driver signing policy..which cannot be disabled.
This is merely how Linus goes about discussion, do we really have to keep taking posts off of the LKML and blowing them all out of proportion?
-- Linus, in this post
> This particular crack has/will be defeated by SP1.
Yes this particular crack (by Paradox) has been fixed in SP1. The thing is, SP1 only blacklists some very specific 'soft mods' (Boot loader replacement designed to emulate an OEM issued BIOS SLIC table and trick Vista into accepting your machine as an OEM product). It is widely known that there are still many others out there, even ones dating from the middle of last year, that work just fine with SP1.
That stems from everyone being to depressed by the boring flat landscape to do any work and keep services running.