Disclosure: SpiderOak is my primary contractor, I do stuff to help their infrastructure.
That said, we do versioned, encrypted, zero-knowledge backup of Linux, Mac, and Windows machines.
To mitigate on clients and servers:
in/etc/ssh/sshd_config and/etc/ssh/ssh_config and/or any ssh clients you use, add:
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha1
To verify:
ssh -v host
look for the output:
debug1: kex: server->client aes128-ctr hmac-sha1 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-sha1 zlib@openssh.com
You are particularly interested in the aesXXX-ctr segment. If that specifies a CBC mode, then you probably need to change that server's config. For the blowfish-using type, I'm uncertain of the attack's applicability to blowfish-cbc. YMMV.
For server testing, you probably want to make sure your ssh client isn't forcing the CTR mode. To test that, do
ssh -v -o Ciphers=aes256-cbc,aes192-cbc,aes128-cbc,aes256-ctr,aes192-ctr,aes128-ctr and look for similar debugging output as above.
The compiler or linker does not have to be distributed as part of the same distribution that comes with the basic OS setup to qualify as a 'major' component of the operating system in the words of the LGPL v2.1, I believe.
This seems to be the linchpin of your argument, and also your most clearly stated point that I disagree with. As in many semantic debates, what should be a minor provision in this document seems to be a big headache. I believe that 'major component', as specified in the LGPL does not need to be taken to mean 'bundled with the OS and freely available', where from your arguments you seem to prefer the inverse interpretation. Are any any authorities you could refer on this matter? We could always ask Eben Moglen, and perhaps we should.
On the existence of a 'strip' utility in development platforms: this functionality is available, in some fashion or another, in most every development platform I have seen in the last 10+ years that also features a linker. You strip an executable when it is ready for distribution and you no longer need debugging or internal symbol information available. This I think would allow you to avoid copyright infringement of commercial libraries, since you can use this to present your portion of the executable + commercial libraries as an integrated, inseprable unit. (This is doable since you can remove information needed to link outside code into the commercial library.) Is there a clear example you can provide where this would not work? Also, the GNU binutils have been ported to work with the binary formats of an awful lot of platforms. There's no reason you can't use GNU's strip with some other development platform if a strip utility or its equivalent isn't available on your platform.
If you are philosophically opposed to any use of LGPL code in your application, that's fine. Do please admit that it is that however, instead of pretending that it is technically infeasible to meet the obligations of the LGPL.
You are, in fact, able to use LGPL ('lesser'/new version) code in a commercial, closed source, application.
Here is the evidence:
Sec. 6 Paragraphs 1,2; LPGL v2.1:
This verbiage describes that you can link a LGPL library with a "work that uses the library" (i.e. your proprietary code), given that you clearly refer to the copyright of said library and its license in your program. Also described, are five actions, one of which must be undertaken with distribution of the combined work. These actions are designed to guarantee the 'unbundling' of the LGPL work from your proprietary work, such that all the rights of the LGPL granted to a user of the LGPLd code are preserved when used with your work.
Sec 6, Paragraph 3; LGPL v2.1:
Here, the requirements for distributions of an executable containing LGPL code is clarifed to indicate that you are required to include all files and data needed to recombine the LGPL library with the rest of a proprietary executable. This means, simply, that a distributor of such executable (LGPL+Proprietary code) is required to make it easy to recombine the LGPL library with their executable. With modern linkers & object management utilities (hell, even old linkers & object management can do this), all you need is a partially stripped.o or.a file.
Important note: With proper invocation of strip, all internal references from your code can be removed, leaving only external references required for linking to system libraries and the LGPL code you are required to distribute. This will make said.a/.o that you are required to distribute contain no more information than could be gained with ltrace, or strace on an executable. Note also that modern debugger & code analyzer can remove the protection that would be granted from a statically linked executable. It is more work than most vendors go through to completely reimplement their C library, so this clause of LGPL v2.1 doesn't really remove any protection you would have had anyway from static linking.
Sec 6, Paragraph 3; LGPL v2.1 (revisited):
This paragraph ALSO states that you do not need to distribute components that are distributed with major (2nd important note:this is not the same as 'core') components of the operating system, unless such a component is or is attached to the executable. This excuses you from having to distribute a complete compiler toolchain with your LGPL+Proprietary executable. Make sure to note that this also does not specify licenses/combinations under which those major components are distributed. It is enough that such components are readily available. The LGPL would be a document several times longer if it had to specify each exemption here. (compiler, binutils etc.)
Sec. 6 Paragraph 4; LGPL v2.1:
This paragraph states that the requirements of this Section may contradict with the requirements of other licensed code in your software. Most (closed-source) software licenses say that you can restribute the object code for their libraries if they are compiled into your application. For dynamically linked libraries, this is simple. For statically linked libraries, you can do your due diligence in upholding your requirements to the owner of licensed code with, once again, judicious use of strip.
I believe this covers each of your primary objections to use of the LGPL, including your claims that to meet the obligations of the LGPL would be a death setence (read: trivial reverse engineering) of your software.
It is true that the LGPL requires one to perform some contortions to distribute closed-source software that uses LGPL code, but it does not require you to open your software. The only requirement is that you preserve the rights that the LGPL grants to LGPLd code.
Does this answer your worries about the use of the LGPL?
I thought it was WMA that did the 3dB boost. I just encoded my Crystal Method stuff yesterday, and it came out crystal-clear, with the same loudness as the CDs...
Either: A. I'm going deaf B. danny256 is on crack C. Someone slipped some crack into the french toast I ate this morning.
Here's what I encode with: oggenc -q 7
Most people will say this is insane, and it probably is. I end up with.ogg files of a nominal bitrate at ~220 kbit/sec. Most people can probable be happy with -q 4 or -q 5, and end up with far smaller files as well (The Xiph people recommend -q 6 if you want lossless stereo coupling).
There is x86 emulation software available for PPC systems. This, I imagine would still be the same. (google: Connectix Virutal PC)
As for hardware, recent Apple machines have PCI slots, so any PCI compliant hardware will work in a Mac, provided there is a driver. For some cards, such as video cards, you will need a card with a Mac-enabled BIOS ROM. Other than that, it is the exact same hardware.
This is also true for Alphas, StrongARM desktops, UltraSPARC etc.
Apple computers are not the answer. When you work with Apple they force you to have total reliance on them for everything. So if it sucks, you are stuck. At my school I get tired of the Apple servers constantly crashing and kicking people off.
The easier to use argument is stupid in the school setting. A rock is easier than any computer, but it is far better to teach computers since there isn't much value in rocks.
If you are going to have computers you shouldn't waste your time teaching what is pretty. You should teach what works and what the industries are using.
Apples are not inexpensive. If they ever break down, they are very expensive to fix. Upgrade parts are not as widely avalible and are wildly expensive. Adding extra parts is pricy since everything has to be external. To add anything that takes bandwidth you have to have IEEE 1394. That is a bummer since all the less expensive devices are coming out in USB 2.0 whitch isn't even supported by the new iMac.
Apple has a way of missing technology trends and being very expensive when they do come out. Also there is a lack of midrange technologies in software.
In it's previous life, Gentoo was known as Enoch Linux. Enoch was something of an abortive mother, but it's offspring, ebuild, has been an amazingly useful enabling technology for getting a distro off the ground.
You can download everything you need to build a gentoo without net access from their download tree. I could be wrong with portage, but you could just rsync than and then tar cjvf/root/portage.tar.bz2 -C / usr/portage and you have a ready-to-build tree.
No matter what spiffy metal or compound of the week your case is cut from, if you don't have a proven mechanism for heat transference, then you just might still end up with a nice hunk of dead CPU.
Granted, I AM one of those psychos with 10 fans in their case, but that's because my disk drives would melt through without them.:)
Most of my case gets by on exactly 3 fans though. No fancy mechanics needed? Why spend $200 when $60 will still do the job?
A?: It's some manner of belief structure..note: !structure is still an instance of structure, at least to me.
A?: It's that thing the neighbors do on Sundays..
Either way, I think religion is just something that allows people to step outside of themselves, and into something (or someone) else for awhile. As for the concept of magic, or hackery, or whatever you're calling it today, I think it's what happens when one gets the courage or will to just run with it...
If you're able to become something else at will, why not? Just remember that your effort to remain what you are is what limits you..:)
Example:
Take a look at cracking, or reverseenginerring a peice of software. You end up needing to reach for strings, and often without much else to go on... How do you decide which path to take, or what code to focus on? Yeah, you could eventually just get to all of it, but do you want to spend that much time on it if you don't have to?
I may call myself an atheist, but there's still things I've seen (and done, from time to time) that science (Which is often a religion unto itself) simply does not yet explain. A religion can be an answer to those.. It's a useful tool when you know how to use it. In untrained hands however, it's an extremely sharp blade that's often wielded at yourself. Use it wisely.
Slashdot Mirror
for a first post.
(revenue = making money) ~= profit.
Disclosure: SpiderOak is my primary contractor, I do stuff to help their infrastructure. That said, we do versioned, encrypted, zero-knowledge backup of Linux, Mac, and Windows machines.
To mitigate on clients and servers: in /etc/ssh/sshd_config and /etc/ssh/ssh_config and/or any ssh clients you use, add:
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha1
To verify:
ssh -v host
look for the output:
debug1: kex: server->client aes128-ctr hmac-sha1 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-sha1 zlib@openssh.com
You are particularly interested in the aesXXX-ctr segment. If that specifies a CBC mode, then you probably need to change that server's config. For the blowfish-using type, I'm uncertain of the attack's applicability to blowfish-cbc. YMMV. For server testing, you probably want to make sure your ssh client isn't forcing the CTR mode. To test that, do
ssh -v -o Ciphers=aes256-cbc,aes192-cbc,aes128-cbc,aes256-ctr,aes192-ctr,aes128-ctr
and look for similar debugging output as above.
In current TPM hardware, it only works as well as the CPU hooks into it. If you have firewire, you can directly access the TPM's memory. oops.
Eyeballing Darl McBride
In the spirit of cryptome
C++ is capable of this style of persistence as well.
See Coldstore,
a generic object persistence system for C++.
*cough* slowaris *cough*
Sure they can build it themselves, but it has so much gathered cruft over the years that it's a big ugly behemoth.
Linux gives Sun an easy excuse to dump much of that legacy code for their newer systems, especially since Linux can run Solaris binaries.
Rootless X on OS X is still a disaster. It's still slow and ugly. Maybe that's just OS X's fault though.
The compiler or linker does not have to be distributed as part of the same distribution that comes with the basic OS setup to qualify as a 'major' component of the operating system in the words of the LGPL v2.1, I believe.
This seems to be the linchpin of your argument, and also your most clearly stated point that I disagree with. As in many semantic debates, what should be a minor provision in this document seems to be a big headache. I believe that 'major component', as specified in the LGPL does not need to be taken to mean 'bundled with the OS and freely available', where from your arguments you seem to prefer the inverse interpretation. Are any any authorities you could refer on this matter? We could always ask Eben Moglen, and perhaps we should.
On the existence of a 'strip' utility in development platforms: this functionality is available, in some fashion or another, in most every development platform I have seen in the last 10+ years that also features a linker. You strip an executable when it is ready for distribution and you no longer need debugging or internal symbol information available. This I think would allow you to avoid copyright infringement of commercial libraries, since you can use this to present your portion of the executable + commercial libraries as an integrated, inseprable unit. (This is doable since you can remove information needed to link outside code into the commercial library.) Is there a clear example you can provide where this would not work? Also, the GNU binutils have been ported to work with the binary formats of an awful lot of platforms. There's no reason you can't use GNU's strip with some other development platform if a strip utility or its equivalent isn't available on your platform.
If you are philosophically opposed to any use of LGPL code in your application, that's fine. Do please admit that it is that however, instead of pretending that it is technically infeasible to meet the obligations of the LGPL.
You are, in fact, able to use LGPL ('lesser'/new version) code in a commercial, closed source, application.
Here is the evidence:
This verbiage describes that you can link a LGPL library with a "work that uses the library" (i.e. your proprietary code), given that you clearly refer to the copyright of said library and its license in your program. Also described, are five actions, one of which must be undertaken with distribution of the combined work. These actions are designed to guarantee the 'unbundling' of the LGPL work from your proprietary work, such that all the rights of the LGPL granted to a user of the LGPLd code are preserved when used with your work.
Here, the requirements for distributions of an executable containing LGPL code is clarifed to indicate that you are required to include all files and data needed to recombine the LGPL library with the rest of a proprietary executable. This means, simply, that a distributor of such executable (LGPL+Proprietary code) is required to make it easy to recombine the LGPL library with their executable. With modern linkers & object management utilities (hell, even old linkers & object management can do this), all you need is a partially stripped .o or .a file.
This paragraph ALSO states that you do not need to distribute components that are distributed with major (2nd important note:this is not the same as 'core') components of the operating system, unless such a component is or is attached to the executable. This excuses you from having to distribute a complete compiler toolchain with your LGPL+Proprietary executable. Make sure to note that this also does not specify licenses/combinations under which those major components are distributed. It is enough that such components are readily available. The LGPL would be a document several times longer if it had to specify each exemption here. (compiler, binutils etc.)
This paragraph states that the requirements of this Section may contradict with the requirements of other licensed code in your software. Most (closed-source) software licenses say that you can restribute the object code for their libraries if they are compiled into your application. For dynamically linked libraries, this is simple. For statically linked libraries, you can do your due diligence in upholding your requirements to the owner of licensed code with, once again, judicious use of strip.
I believe this covers each of your primary objections to use of the LGPL, including your claims that to meet the obligations of the LGPL would be a death setence (read: trivial reverse engineering) of your software.
It is true that the LGPL requires one to perform some contortions to distribute closed-source software that uses LGPL code, but it does not require you to open your software. The only requirement is that you preserve the rights that the LGPL grants to LGPLd code.
Does this answer your worries about the use of the LGPL?
I thought it was WMA that did the 3dB boost. I just encoded my Crystal Method stuff yesterday, and it came out crystal-clear, with the same loudness as the CDs...
.ogg files of a nominal bitrate at ~220 kbit/sec. Most people can probable be happy with -q 4 or -q 5, and end up with far smaller files as well (The Xiph people recommend -q 6 if you want lossless stereo coupling).
Either:
A. I'm going deaf
B. danny256 is on crack
C. Someone slipped some crack into the french toast I ate this morning.
Here's what I encode with:
oggenc -q 7
Most people will say this is insane, and it probably is. I end up with
There is x86 emulation software available for PPC systems. This, I imagine would still be the same. (google: Connectix Virutal PC)
As for hardware, recent Apple machines have PCI slots, so any PCI compliant hardware will work in a Mac, provided there is a driver. For some cards, such as video cards, you will need a card with a Mac-enabled BIOS ROM. Other than that, it is the exact same hardware.
This is also true for Alphas, StrongARM desktops, UltraSPARC etc.
It just might be worth a subscription to Red Herring. I saw this in print 2 (two) months ago.
Apple computers are not the answer. When you work with Apple they force you to have total reliance on them for everything. So if it sucks, you are stuck. At my school I get tired of the Apple servers constantly crashing and kicking people off. The easier to use argument is stupid in the school setting. A rock is easier than any computer, but it is far better to teach computers since there isn't much value in rocks. If you are going to have computers you shouldn't waste your time teaching what is pretty. You should teach what works and what the industries are using. Apples are not inexpensive. If they ever break down, they are very expensive to fix. Upgrade parts are not as widely avalible and are wildly expensive. Adding extra parts is pricy since everything has to be external. To add anything that takes bandwidth you have to have IEEE 1394. That is a bummer since all the less expensive devices are coming out in USB 2.0 whitch isn't even supported by the new iMac. Apple has a way of missing technology trends and being very expensive when they do come out. Also there is a lack of midrange technologies in software.
In it's previous life, Gentoo was known as Enoch Linux. Enoch was something of an abortive mother, but it's offspring, ebuild, has been an amazingly useful enabling technology for getting a distro off the ground.
Kain
This isn't exactly what happens.
Warning: ebuild spoiler follows
In conclusion, I'm sorry, but there will be no Gentoo Effect.
Kain
You can download everything you need to build a gentoo without net access from their download tree. I could be wrong with portage, but you could just rsync than and then tar cjvf /root/portage.tar.bz2 -C / usr/portage and you have a ready-to-build tree.
Yes Johnny, it really is that simple.
According to Linus, Real Men(TM) don't need backups. :P They just get their code mirrored to FTP servers across the world.
from what I hear, n-ctf SUCKED this year...
From a friend whom was on one of the teams:
We set up some 'reflectors', using the MIRROR target of the Linux netfilter and almost got booted of the net by the judges for this unique solution.
Bleh.
Aluminium is not the answer.
:)
No matter what spiffy metal or compound of the week your case is cut from, if you don't have a proven mechanism for heat transference, then you just might still end up with a nice hunk of dead CPU.
Granted, I AM one of those psychos with 10 fans in their case, but that's because my disk drives would melt through without them.
Most of my case gets by on exactly 3 fans though. No fancy mechanics needed? Why spend $200 when $60 will still do the job?
I'm afraid I see a lot of competition dropping out of the 3D market in the near future with this event. :(
For starters, NVidia is likely to get a bit complacent with their marketshare now. :( I see their support in the future dropping at least a little.
This leave us with just a few viable ( < $400 card) vendors..
- NVidia
- ATI
- Matrox
- S3
Anyone care to correct me if I'm wrong here?On a side note, I'd be willing to pay a premium for an openly-speced, programmable graphic accellerator? Anyone else?
Either way, I think religion is just something that allows people to step outside of themselves, and into something (or someone) else for awhile. As for the concept of magic, or hackery, or whatever you're calling it today, I think it's what happens when one gets the courage or will to just run with it...
If you're able to become something else at will, why not? Just remember that your effort to remain what you are is what limits you.. :)
Example:
I may call myself an atheist, but there's still things I've seen (and done, from time to time) that science (Which is often a religion unto itself) simply does not yet explain. A religion can be an answer to those.. It's a useful tool when you know how to use it. In untrained hands however, it's an extremely sharp blade that's often wielded at yourself. Use it wisely.