The LGPL requires not only changes to the LGPL library, but also all the linkable object files used to glue it to your code base.
You can satisfy this simply by compiling the LGPL library as a dynamic library. Just like you do with the GNU C library (except that you don't distribute that).
One vendor (I work for them) has demonstrated >100 metre reach and will be happy to ship you a 10GBase-T reference design which uses well under 25 watts. Talk about "dialing back" power is absolute nonsense - the competing PHY just wasn't ready when those other NICs were hastily announced. Still, even 35 metres is a lot better than HDMI manages.
There's nothing inherently wrong with using twisted pair for this. You can run 10 gigabit Ethernet over 100 metres of twisted pair (granted, that's not in mass production yet), so why not a few gigabits of video? From my reading of the article, I think the real distance limitations on HDMI come from poor error correction and perhaps lack of self-clocking signals. And no, twisted pair Ethernet doesn't have such a high error rate that it requires many retransmissions. Retransmission is implemented at higher levels to recover from packet loss that mostly occurs at congested routers. On a single link the error correction code is adequate.
There are gender-stereotyped colours: in Britain, blue for boys, pink for girls. I think America has the same colours, and I also saw a Swedish film that referred to them. So, while I think this is just a silly fashion, it's not peculiar to America.
Well, OK, they can read-modify-write (and do, for compatibility) but it does make single block writes much more expensive than would be expected. The device driver needs to know that it should rewrite 4 Kbyte blocks. Also the partition editor and filesystem should ensure 4 Kbyte alignment. (Windows Vista does this. I fear GNU/Linux is lagging.) In the Amiga case, the drives were dumb and it was up to the driver to write entire tracks.
No, every block has to be independently writable. That's why they can't just use 4 Kbyte sectors on the disk and present them as 8 blocks through the ATA interface.
Incandescents are cheap only if you ignore the ongoing cost of power to run them. CF bulbs will typically come out ahead after a year or so even if you pay $10 for each, and you'll rarely need to replace them (unless you're in the habit of breaking light bulbs). I expect decent CF bulbs will be increasingly available in non-specialist stores anyway.
WHQL still is a pretty tough standard. But since manufacturers run the test suite on their own hardware there's nothing to stop them turning off unstable performance hacks to pass WHQL then turning them on in the shipped installer (using registry settings rather than rebuilding the driver). Based on past behaviour I can certainly imagine graphics card vendors doing that.
One of the things that amused me about the "phantom time hypothesis" is the easily contradicted supporting evidence. The change to the Gregorian calendar only required a 10-day adjustment to move Easter back to the proper date in 1582, correcting for only about 1300 years' worth of drift. But the date of Easter was fixed at the council of Nicaea in 325, so this is exactly as expected.
The summary is wrong. Most of the requests for "communications data", meaning logs of phone numbers or email addreses along with dates and times of transmission. I believe phone tapping is much rarer; unfortunately I haven't seen any figure put on that.
MS subcontracted Unix (Xenix) development work to SCO and later sold the copyrights to them. They probably had shares in SCO but never owned it outright. In any case, that was the old SCO, not SCO-which-was-Caldera.
Not only is the bandwidth on an LP fairly low to start with, but it very quickly drops as the LP is played repeatedly. The later compact types of compact cassette are better.
You are right. My point was that it was not obvious how to change language.
What would be an obvious way? (You are not allowed to assume that users already know how to do this in Word.)
I (and I use OOO on daily basis since I run Linux) needed to Google after the solution
You might have done that, but you didn't need to: the online help explains it.
- I would not guess that language settings were under "character format".
I can sort of see that they're not really formatting options.
OOO has lots of such small quirks. OOO is great overall but it surely needs some usability improvements and interface redesign.
I think you may be thrown by the fact that it's a lot like MS Office, and yet subtly different. (Is there an uncanny valley for software?) There's a tension between the the requirement that it not be too alien for MS Office users and the general wish to make a good user interface. I would prefer to give the latter a higher priority, and I hope that now that MS Office itself has finally had some quite radical user interface changes the former requirement will be less of a competitive neceessity for OpenOffice.org's commercial backers.
A per-paragraph language property is too granular. The text language can vary from sentence to sentence or even within a sentence (inline quotation). It should ideally be a per-word property, but word boundaries are themselves language-dependent.
One of the bad things about x.509 up to now is that it's all-or-nothing; the other side's identity is either completely trusted or not trusted at all.
This is because x.509 was designed for the Directory Access Protocol (x.500) which is entirely hierarchical and has no room for uncertainty or rival authorities.
Acknowledging that there is a degree to which the other side has been authenticated, and then showing this in the browser, is a step in the right direction.
This still says nothing about trustworthiness, though.
It's still unfortunate that they left the biggest weakness in the system, though. An identity is still only certified by one certifier. That's really dumb.
It's also inherent in x.509. As I implied, it's designed to have only a single root. In reality we have multiple roots, but validation of a certificate still has to lead to a single root CA. Divergence or cycles in the "trust path" will cause existing x.509 implementations to explode.
So the user then goes into their software and also sets Verisign to a low value. The user should only really trust people they have reason to trust. They probably wouldn't really delete Verisign from their list, but they'd set the trust level to very low.
I agree that this makes sense. But at present most users don't even understand the difference between the browser's security indicators (lock icon, yellow address bar, etc.) and in-page security claims (bullshit like Verified by Visa). I have no hope at all that users in general will be able to make sensible decisions about which CAs to trust.
I understand why Microsoft is willing to play along with the big CAs. I don't understand why the Mozilla, Konqueror, Safari, etc teams do.
The whole stupid system depends on global agreement as to which are the root CAs.
Every one of you who ever coded a browser to announce anything threatening about a site because a certificate was self-signed is complicit in a monumental scam
The purpose of a certificate is for a server (or less commonly a client) to "prove" that the public key it's presenting belongs to the entity that its peer intends to communicate with. If you don't know that you're using the right key, what's the value of encrypting? I agree that many CAs have weak verification processes, and since any CA can certify for any domain then the value of certificates is determined by the worst CA. However, a certificate by a known CA is still somewhat more trustworthy than a certificate by some random key about itself.
I wouldn't say Java has "strong typing". It's stronger than C, but it has some nasty flaws:
Strings and integers can be added together.
A parameter or other variable of object type (or rather pointer-to-object type) can always be null, so far as the language is concerned. This weakens the type invariants of any pointer-to-object type. Worse, it encourages the use of null as a special case whose implementation is scattered across users of the class, instead of the null object pattern.
int can be coerced to float, losing precision. There are no run-time checks against this.
There are no static or run-time checks against integer overflow.
A value of type A[] can be converted to type B[] where A is a subclass or implementer of B. However, a container-of-subclass is not a container-of-superclass unless the container types are immutable. Any attempt to assign an object of type B into an array-of-A that's pretending to be an array-of-B will result in an ArrayStoreException at run-time. The same problem applies to other container types, not to mention the pre-generic containers-of-Object.
Not that Java is particularly bad in this. Comparing with my favourite languages: C++ has problem 1 for the built-in string type (but not std::string) with weird semantics, a worse version of problem 3 (narrowing numeric conversions are all implicit), and a worse version of problem 4 (undefined behaviour on overflow); Python has no static type checking at all, so it suffers from problems 2 and 5 (though entirely dynamic type checking aka "duck typing" can be a very useful feature if you get used to it).
To elaborate: one possibility in 'Trusted Computing' is to disallow certain programs from being run.
Virus checkers have done and will continue to do that but we know it's entirely possible to work around them. AFAIK the revocation features in DRM systems do not work by black-listing applications but by removing them from a white-list. (The DRM controller generates all the keys expected to be needed in advance and includes them all in the initial white-list.) That doesn't prevent a "revoked" application from running and performing operations that don't involve the DRM system.
Now, if a DRM hole is found in a program, then Microsoft is in the position of being able to prevent mass copyright infringement by simply pushing a 'critical update' in Windows Update (what could be more critical than upholding the law?).
Exactly their response to FairUse4WM. DRM is far too important to wait for Patch Tuesday!
The X11 server was used in a late version of Desqview. Desqview could run DOS applications including Windows, and Desqview/X made them work as X clients. HP had an alternate shell for Windows, more like the later Windows Explorer than Program Manager. OS/2 could always run DOS applications. I think every DOS-based multitasking/windowing system that used 386 protected mode had some way of running ordinary DOS applications.
Debian developers in general are not "zealots". There are substantial differences of opinion among Debian developers over what licence terms Debian can accept, and what would be classified as non-free (which doesn't in itself mean we can't distribute it). The renaming of Mozilla applications is a result of some mistrust between Mozilla and Debian, which I don't really understand. Mozilla insists that modified versions of its applications can be distributed under the original trademarked names only if the source modifications have been approved by Mozilla. Debian and Ubuntu make various changes to Firefox to improve integration with other applications and to apply security fixes that were made in later versions separately from other less important changes. Ubuntu was able to gain permission to do this. Debian, for some reason, has been given an ultimatum to change the names or revert these changes. Given a choice between integration and stability or keeping the good name (but requiring our users to change it if they want to improve it), Debian and in particular the maintainers of these applications in Debian have chosen the former.
Slashdot Mirror
You can satisfy this simply by compiling the LGPL library as a dynamic library. Just like you do with the GNU C library (except that you don't distribute that).
D) Remove the battery
One vendor (I work for them) has demonstrated >100 metre reach and will be happy to ship you a 10GBase-T reference design which uses well under 25 watts. Talk about "dialing back" power is absolute nonsense - the competing PHY just wasn't ready when those other NICs were hastily announced. Still, even 35 metres is a lot better than HDMI manages.
There's nothing inherently wrong with using twisted pair for this. You can run 10 gigabit Ethernet over 100 metres of twisted pair (granted, that's not in mass production yet), so why not a few gigabits of video? From my reading of the article, I think the real distance limitations on HDMI come from poor error correction and perhaps lack of self-clocking signals. And no, twisted pair Ethernet doesn't have such a high error rate that it requires many retransmissions. Retransmission is implemented at higher levels to recover from packet loss that mostly occurs at congested routers. On a single link the error correction code is adequate.
I believe the VW Polo diesel is available in the US.
There are gender-stereotyped colours: in Britain, blue for boys, pink for girls. I think America has the same colours, and I also saw a Swedish film that referred to them. So, while I think this is just a silly fashion, it's not peculiar to America.
Well, OK, they can read-modify-write (and do, for compatibility) but it does make single block writes much more expensive than would be expected. The device driver needs to know that it should rewrite 4 Kbyte blocks. Also the partition editor and filesystem should ensure 4 Kbyte alignment. (Windows Vista does this. I fear GNU/Linux is lagging.) In the Amiga case, the drives were dumb and it was up to the driver to write entire tracks.
No, every block has to be independently writable. That's why they can't just use 4 Kbyte sectors on the disk and present them as 8 blocks through the ATA interface.
Incandescents are cheap only if you ignore the ongoing cost of power to run them. CF bulbs will typically come out ahead after a year or so even if you pay $10 for each, and you'll rarely need to replace them (unless you're in the habit of breaking light bulbs). I expect decent CF bulbs will be increasingly available in non-specialist stores anyway.
WHQL still is a pretty tough standard. But since manufacturers run the test suite on their own hardware there's nothing to stop them turning off unstable performance hacks to pass WHQL then turning them on in the shipped installer (using registry settings rather than rebuilding the driver). Based on past behaviour I can certainly imagine graphics card vendors doing that.
One of the things that amused me about the "phantom time hypothesis" is the easily contradicted supporting evidence. The change to the Gregorian calendar only required a 10-day adjustment to move Easter back to the proper date in 1582, correcting for only about 1300 years' worth of drift. But the date of Easter was fixed at the council of Nicaea in 325, so this is exactly as expected.
The summary is wrong. Most of the requests for "communications data", meaning logs of phone numbers or email addreses along with dates and times of transmission. I believe phone tapping is much rarer; unfortunately I haven't seen any figure put on that.
They are purported to have been recorded between 1989 and 2006. If I understand correctly, they were all released in the last 2-3 years.
MS subcontracted Unix (Xenix) development work to SCO and later sold the copyrights to them. They probably had shares in SCO but never owned it outright. In any case, that was the old SCO, not SCO-which-was-Caldera.
Not only is the bandwidth on an LP fairly low to start with, but it very quickly drops as the LP is played repeatedly. The later compact types of compact cassette are better.
! Best sandwiches L@@K NR not sub burger burrito !
Interesting. I would expect this to improve process startup time too - which seems like a much more important reason to make the change.
What would be an obvious way? (You are not allowed to assume that users already know how to do this in Word.)
You might have done that, but you didn't need to: the online help explains it.
I can sort of see that they're not really formatting options.
I think you may be thrown by the fact that it's a lot like MS Office, and yet subtly different. (Is there an uncanny valley for software?) There's a tension between the the requirement that it not be too alien for MS Office users and the general wish to make a good user interface. I would prefer to give the latter a higher priority, and I hope that now that MS Office itself has finally had some quite radical user interface changes the former requirement will be less of a competitive neceessity for OpenOffice.org's commercial backers.
A per-paragraph language property is too granular. The text language can vary from sentence to sentence or even within a sentence (inline quotation). It should ideally be a per-word property, but word boundaries are themselves language-dependent.
This is because x.509 was designed for the Directory Access Protocol (x.500) which is entirely hierarchical and has no room for uncertainty or rival authorities.
This still says nothing about trustworthiness, though.
It's also inherent in x.509. As I implied, it's designed to have only a single root. In reality we have multiple roots, but validation of a certificate still has to lead to a single root CA. Divergence or cycles in the "trust path" will cause existing x.509 implementations to explode.
I agree that this makes sense. But at present most users don't even understand the difference between the browser's security indicators (lock icon, yellow address bar, etc.) and in-page security claims (bullshit like Verified by Visa). I have no hope at all that users in general will be able to make sensible decisions about which CAs to trust.
The whole stupid system depends on global agreement as to which are the root CAs.
The purpose of a certificate is for a server (or less commonly a client) to "prove" that the public key it's presenting belongs to the entity that its peer intends to communicate with. If you don't know that you're using the right key, what's the value of encrypting? I agree that many CAs have weak verification processes, and since any CA can certify for any domain then the value of certificates is determined by the worst CA. However, a certificate by a known CA is still somewhat more trustworthy than a certificate by some random key about itself.
I wouldn't say Java has "strong typing". It's stronger than C, but it has some nasty flaws:
Not that Java is particularly bad in this. Comparing with my favourite languages: C++ has problem 1 for the built-in string type (but not std::string) with weird semantics, a worse version of problem 3 (narrowing numeric conversions are all implicit), and a worse version of problem 4 (undefined behaviour on overflow); Python has no static type checking at all, so it suffers from problems 2 and 5 (though entirely dynamic type checking aka "duck typing" can be a very useful feature if you get used to it).
Virus checkers have done and will continue to do that but we know it's entirely possible to work around them. AFAIK the revocation features in DRM systems do not work by black-listing applications but by removing them from a white-list. (The DRM controller generates all the keys expected to be needed in advance and includes them all in the initial white-list.) That doesn't prevent a "revoked" application from running and performing operations that don't involve the DRM system.
Exactly their response to FairUse4WM. DRM is far too important to wait for Patch Tuesday!
The X11 server was used in a late version of Desqview. Desqview could run DOS applications including Windows, and Desqview/X made them work as X clients. HP had an alternate shell for Windows, more like the later Windows Explorer than Program Manager. OS/2 could always run DOS applications. I think every DOS-based multitasking/windowing system that used 386 protected mode had some way of running ordinary DOS applications.
Debian developers in general are not "zealots". There are substantial differences of opinion among Debian developers over what licence terms Debian can accept, and what would be classified as non-free (which doesn't in itself mean we can't distribute it). The renaming of Mozilla applications is a result of some mistrust between Mozilla and Debian, which I don't really understand. Mozilla insists that modified versions of its applications can be distributed under the original trademarked names only if the source modifications have been approved by Mozilla. Debian and Ubuntu make various changes to Firefox to improve integration with other applications and to apply security fixes that were made in later versions separately from other less important changes. Ubuntu was able to gain permission to do this. Debian, for some reason, has been given an ultimatum to change the names or revert these changes. Given a choice between integration and stability or keeping the good name (but requiring our users to change it if they want to improve it), Debian and in particular the maintainers of these applications in Debian have chosen the former.