So, you'll hire that teacher caught molesting their students because they say they want to help children? Microsoft has a long and sordid history of setealing intellectual property, claiming the success of open source projects they invest in and yet violating the published API's to lock out the software of the open source authors or public API publishers. This happened with Java, Kerberos, SPF, etc.
There is no reason to think they've changed policy.
The economic tradeoffs for LEO versus Lagrange point fabrication are fascinating: You're probably correct that we should keep it out of LEO, but the fuel costs of keeping spacecraft hopping into and out of Lagrange points are pretty serious until you have a permanent station with non-Terran fuel sources available.
Of weapon=-grade plutonium? Or U-235? Or the even more exotic components of thermonuclear weapons? Do you really want that stuff being handled in LEO or similar fabrication suitable orbits by NASA?
I don't: leaving such military materials in NASA's rather military hands poses the far greater risks of an arms race in space.
Your experience seriously does not match mine. I've watched the explosions happen, at close range, at least 4 times in the last 5 years, to the major corporate email servers.
Many of the issues have centered on failure, or unwillingness, to maintain mail quotas or spare space for big email bursts and the resulting debris blown across multiple user email accounts. Other issues have been live failover routines, which have twice corrupted both systems and forced restoration from what turned out to be ineffective previous backups.
And Exchange plugins are notoriously unwieldy and unreliable, as well. Forcing the users to do email backup is just begging for pain in a corporate environment. Email is one of the most critical systems to manage, and it should just work. Errors should be small and easy to address, rather than scattering across so many users. This is precisely the correct behavior I see with IMAP: if they got the message, it's marked so, and it's easy to backup and replicate to other mail servers.
I've had to clean up when someone trying to fix their PC and driver problems went and re-installed drivers from their media, when I'd I'd updated from NVidia's site, and monitors become completely unavailable on dual-display cards from the previous working display, and had it impossible to fix without dragging another monitor in with the other connector type and fixing events from the other display. It's compounded on systems with built-in displays and add-on graphics cards.
So yes, I've had real problems with NVidia's Windows drivers. And the Linux installer problems are compounded by NVidia's refusal to allow them to be published as part of an OS release and attempt to force the manual installation. This breaks package management of the OpenGL libraries for the operating system.
Maybe they work for you: I find NVidia drivers quite painful, especially for non-Windows operating sytems. And a 'third party open source driver'can't get the details of the NVidia API to work from, which means a huge amount of reverse engineering, especially of their propriatary OpenGL libraries, which are at the core of their enhanced features in non-Windows operating systems.
You're a Microsoft shop, using Outlook and Exchange. Setting up a sane retention policy on top of that is nightmarish, especially for people whose business memory is stored in email. Data security isn't just protectng yourself from lawsuit issues, it also involves protecting your users from storage failures and database corruption. Exchange is notorious for these issues, and throwing more money and hardware and failover equipment at it doesn't solve the fundamental problem of corruption of years of work in the massive, massive files used by Exchange's storage mechanism.
If this is a big issue for you, switch immediately to a sane, IMAP based system that allows individual message storage and the application of external message management systems to ease backup, recovery, and organization of the material by the users. The PST files are an incredibly nasty way to store large, diverse filesets such as email. I've seen them imperil access and recover far too often.
HTTPS presents a significant load on servers. It can easily demand 3 times the hardware and support to transfer a large, busy set of servers to HTTPS for all traffic. If it *didn't* present a noticeable load, it would be fairly useful as a normal encryption channel.
It's also awkward to proxy and manage the encryption securely, because HTTPS is very careful about checking hostnames and IP addresses to avoid people forging your site. This makes it more awkard for usrs, as their browsers complain about untrusted keys or the server owners have to invest in registering keys.
Watch out for the razor blades normally carried in that hand. This policy provides no patent protection for collaborative projects, and we've seen similar attacks with SPF. Embrace the standard, extend it with a patented and ugly add-on, then break the standard and claim all the previous users as clients of your enhanced standard while refusing to cooperate with the public codebase.
An 'advanced data storage' system sounds like a filesystem to me. The Wikipedia write-up is not bad, but makes more sense if you've heard a few schemes of encumbering filesystems with additional layers of data in the past. Unfortunately, it's usually been done quite badly and unstably.
My impression from Microsoft presentations on it was that it was XML based, and patent encumbered. Using their proprietary Microsoft's proprietary and ill-documented SQL would be no better.
They did intend to change the filesystem when designing Vista, to WinFS. WinFS turned out to stink for a lot of reasons, and seems to have quietly vanished off the product release schedule. This is a good thing: WinFS is XML based and apparently severely patent encumbered, and would mean a nightmare writing and publishing new drivers for Linux and other OS's that can comfortably read and write FAT32 and NTFS now.
I responded to your original post, included below:
> Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html [cr.yp.to] > > djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.
While djbdns is immune to this attack (good for Dan!), 'better than BIND' has to include a lot more than merely security. It has to include managability, configurability, documentation, packaging, etc. And djbdns reliance on daemontools creates an additional set of issues, including some significant security ones due to the non-root management of daemons and its frequent mishandling.
Lack of documentation, poor software packaging, and poor integration with other components created by Dan's former copyrights (which he's admittedly changed), and by Dan's refusal to follow basic system standards of user authentication, inventing his own personal unique malloc, replacing the standard system functionality with his own personal unique blend of unfriendly to manage, oddly laid out software, etc.
That's nice. I was talking about daemontools, not qmail. Now go look at that guarantee: by leaving out all the factors that Qmail has to tie to, such as NFS, authentication, denial-of-service attackets, etc., the guarantee is fairly meaningless in most environments.
The JavaScript blocker, in particular, is useful to me. I don't want to send my webpage harvested by Google or Doubleclick, I don't want stupid pop-ups, and I want to know when the page is entirely JavaScript and I won't be able to use Lynx with it. So NoScript is really my friend.
This is particulaarly true for thepiratebay.org. (OK, I virus scan and test games before buying them, I admit it.)
Because handing control of daemons to such users is often done extremely badly and with convenience over security considered paramount, and those 'users' can swamp the systems' resources. I don't want casual users allowed to propagate demons, and the resources to run them, at whim in a shared environment. I want to make them think about it.
I'm afraid that you're right about needing to squeeze. Capturing the fighting style of Rorshach versus the police is going to be very difficult, although I really enjoyed the contrast between 'heroes' and Rorschach in the comic book. And capturing the relationship between the Silk Spectre and the Comedian is begging for movie plot difficulty.
The licensing on djbdns used to be pretty unacceptable, although it's gotten much better in the last few years. The packaging and documentation of djbdns and dan's other tools are awkward at best. Dan's software deliberately violates the UNIX File System Hierarchy, the 'daemontools' package he uses to run his software is extremely dangerous in most environments because it hands off control of daemons to non-root users, and ucspi-tcp is similarly nasty to package and maintain in a server environment without personnel to dedicate to manually integrating and patching Dan's codebase.
There are compelling reasons not to get caught up in Dan Bernstein's tools. While they're often technically brilliant, it's often easier and safer to transfer their critical features to a more manageable and installable code base.
Mostly, they're economic refugees. Cuba, while gifted with beautiful weather and a surprisingly good medical system, is quite poor. Much of this is due to the US embargo, of course. Few of the boat people, today, are anyone we really want or that Castro's government has any reason to want to keep.
Slashdot Mirror
Line count has some use. You can't write new drivers or new filesystems by optimizing old code, it takes actual writing.
So, you'll hire that teacher caught molesting their students because they say they want to help children? Microsoft has a long and sordid history of setealing intellectual property, claiming the success of open source projects they invest in and yet violating the published API's to lock out the software of the open source authors or public API publishers. This happened with Java, Kerberos, SPF, etc.
There is no reason to think they've changed policy.
The economic tradeoffs for LEO versus Lagrange point fabrication are fascinating: You're probably correct that we should keep it out of LEO, but the fuel costs of keeping spacecraft hopping into and out of Lagrange points are pretty serious until you have a permanent station with non-Terran fuel sources available.
> IIRC, the woman who plays W is AB's real-life chiropractor, so of course he keeps baring his back to her. Fixed that for you.
Of weapon=-grade plutonium? Or U-235? Or the even more exotic components of thermonuclear weapons? Do you really want that stuff being handled in LEO or similar fabrication suitable orbits by NASA?
I don't: leaving such military materials in NASA's rather military hands poses the far greater risks of an arms race in space.
Your experience seriously does not match mine. I've watched the explosions happen, at close range, at least 4 times in the last 5 years, to the major corporate email servers.
Many of the issues have centered on failure, or unwillingness, to maintain mail quotas or spare space for big email bursts and the resulting debris blown across multiple user email accounts. Other issues have been live failover routines, which have twice corrupted both systems and forced restoration from what turned out to be ineffective previous backups.
And Exchange plugins are notoriously unwieldy and unreliable, as well. Forcing the users to do email backup is just begging for pain in a corporate environment. Email is one of the most critical systems to manage, and it should just work. Errors should be small and easy to address, rather than scattering across so many users. This is precisely the correct behavior I see with IMAP: if they got the message, it's marked so, and it's easy to backup and replicate to other mail servers.
I've had to clean up when someone trying to fix their PC and driver problems went and re-installed drivers from their media, when I'd I'd updated from NVidia's site, and monitors become completely unavailable on dual-display cards from the previous working display, and had it impossible to fix without dragging another monitor in with the other connector type and fixing events from the other display. It's compounded on systems with built-in displays and add-on graphics cards.
So yes, I've had real problems with NVidia's Windows drivers. And the Linux installer problems are compounded by NVidia's refusal to allow them to be published as part of an OS release and attempt to force the manual installation. This breaks package management of the OpenGL libraries for the operating system.
Maybe they work for you: I find NVidia drivers quite painful, especially for non-Windows operating sytems. And a 'third party open source driver'can't get the details of the NVidia API to work from, which means a huge amount of reverse engineering, especially of their propriatary OpenGL libraries, which are at the core of their enhanced features in non-Windows operating systems.
You're a Microsoft shop, using Outlook and Exchange. Setting up a sane retention policy on top of that is nightmarish, especially for people whose business memory is stored in email. Data security isn't just protectng yourself from lawsuit issues, it also involves protecting your users from storage failures and database corruption. Exchange is notorious for these issues, and throwing more money and hardware and failover equipment at it doesn't solve the fundamental problem of corruption of years of work in the massive, massive files used by Exchange's storage mechanism.
If this is a big issue for you, switch immediately to a sane, IMAP based system that allows individual message storage and the application of external message management systems to ease backup, recovery, and organization of the material by the users. The PST files are an incredibly nasty way to store large, diverse filesets such as email. I've seen them imperil access and recover far too often.
HTTPS presents a significant load on servers. It can easily demand 3 times the hardware and support to transfer a large, busy set of servers to HTTPS for all traffic. If it *didn't* present a noticeable load, it would be fairly useful as a normal encryption channel.
It's also awkward to proxy and manage the encryption securely, because HTTPS is very careful about checking hostnames and IP addresses to avoid people forging your site. This makes it more awkard for usrs, as their browsers complain about untrusted keys or the server owners have to invest in registering keys.
Watch out for the razor blades normally carried in that hand. This policy provides no patent protection for collaborative projects, and we've seen similar attacks with SPF. Embrace the standard, extend it with a patented and ugly add-on, then break the standard and claim all the previous users as clients of your enhanced standard while refusing to cooperate with the public codebase.
An 'advanced data storage' system sounds like a filesystem to me. The Wikipedia write-up is not bad, but makes more sense if you've heard a few schemes of encumbering filesystems with additional layers of data in the past. Unfortunately, it's usually been done quite badly and unstably.
Sadly, the Berkeley DB authors are trying to do a similar stunt with a 'provenance aware' file system. (There's a Usenix paper on it at http://www.usenix.org/event/fast05/wips/slides/seltzer.pdf).
Fortunately, since Oracle bought SleepyCat software, Berkeley DB seems to be going the way of the Atari 2600.
My impression from Microsoft presentations on it was that it was XML based, and patent encumbered. Using their proprietary Microsoft's proprietary and ill-documented SQL would be no better.
They did intend to change the filesystem when designing Vista, to WinFS. WinFS turned out to stink for a lot of reasons, and seems to have quietly vanished off the product release schedule. This is a good thing: WinFS is XML based and apparently severely patent encumbered, and would mean a nightmare writing and publishing new drivers for Linux and other OS's that can comfortably read and write FAT32 and NTFS now.
I responded to your original post, included below:
> Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html [cr.yp.to]
>
> djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.
While djbdns is immune to this attack (good for Dan!), 'better than BIND' has to include a lot more than merely security. It has to include managability, configurability, documentation, packaging, etc. And djbdns reliance on daemontools creates an additional set of issues, including some significant security ones due to the non-root management of daemons and its frequent mishandling.
Lack of documentation, poor software packaging, and poor integration with other components created by Dan's former copyrights (which he's admittedly changed), and by Dan's refusal to follow basic system standards of user authentication, inventing his own personal unique malloc, replacing the standard system functionality with his own personal unique blend of unfriendly to manage, oddly laid out software, etc.
That's nice. I was talking about daemontools, not qmail. Now go look at that guarantee: by leaving out all the factors that Qmail has to tie to, such as NFS, authentication, denial-of-service attackets, etc., the guarantee is fairly meaningless in most environments.
The JavaScript blocker, in particular, is useful to me. I don't want to send my webpage harvested by Google or Doubleclick, I don't want stupid pop-ups, and I want to know when the page is entirely JavaScript and I won't be able to use Lynx with it. So NoScript is really my friend.
This is particulaarly true for thepiratebay.org. (OK, I virus scan and test games before buying them, I admit it.)
So trimming your nose hairs is actually a health risk for London commuters? Blimey!
Because handing control of daemons to such users is often done extremely badly and with convenience over security considered paramount, and those 'users' can swamp the systems' resources. I don't want casual users allowed to propagate demons, and the resources to run them, at whim in a shared environment. I want to make them think about it.
I'm afraid that you're right about needing to squeeze. Capturing the fighting style of Rorshach versus the police is going to be very difficult, although I really enjoyed the contrast between 'heroes' and Rorschach in the comic book. And capturing the relationship between the Silk Spectre and the Comedian is begging for movie plot difficulty.
The licensing on djbdns used to be pretty unacceptable, although it's gotten much better in the last few years. The packaging and documentation of djbdns and dan's other tools are awkward at best. Dan's software deliberately violates the UNIX File System Hierarchy, the 'daemontools' package he uses to run his software is extremely dangerous in most environments because it hands off control of daemons to non-root users, and ucspi-tcp is similarly nasty to package and maintain in a server environment without personnel to dedicate to manually integrating and patching Dan's codebase.
There are compelling reasons not to get caught up in Dan Bernstein's tools. While they're often technically brilliant, it's often easier and safer to transfer their critical features to a more manageable and installable code base.
What's wrong? Doesn't your NNTP server carry alt.sex.bindage anymore?
Mostly, they're economic refugees. Cuba, while gifted with beautiful weather and a surprisingly good medical system, is quite poor. Much of this is due to the US embargo, of course. Few of the boat people, today, are anyone we really want or that Castro's government has any reason to want to keep.