I'm drowning in banal text, for someone clearly overpaid by the word!!!
Seriously, 3 pages of text to repeat the same points 3 or 4 times, then make two conclusions that are orthogonal to his points? Someone needs to edit this material.
This would be much more impressive if they were doing most of the innovation. They're clearly not: it's coming from the upstream Debian conmunity, which they use as a source of drivers, developments, tools, and features. This does not discount the considerable polish they provide. But that is not itself innovation.
To verify this, examine the source history of the Ubuntu kernel, of their Gnoome tool suite, and of any useful system tools such as BIND or Apache.
The effective keystroke monitoring in recent Ubuntu monitoring is a _much_ bigger problem. The desktop search result is broadcasting your searches back to the Ubuntu mother company for Amazon search results. Despite Mark's claims, this is not "putting ads in Ubuntu" it is far more than merely adware. By effectively tracking local user searches, by default, it is clearly spyware. Worse, the queries were being sent in clear text, and there was no graceful way to turn it off. Those had to be top level decisions for the new release, and they were terrible decisions.
> We are not telling Amazon what you are searching for. Your anonymity is preserved because we handle the query on your behalf. Don’t trust us? Erm, we have root
Mark's claim that "your anonymity is preserved because we handle the query" is nonsensical. Tracking cookies and the sometimes abusive tracking tools of doubleclick.net provide thorough tracking of the search queries and the results, and to automatically be doing This, along with other recent changes, has demonstrated that Mark Shuttleworth and the leadership of the Ubuntu distribution _cannot be trusted_. Having "root" access is not an excuse: it's a reason that Ubuntu should never have even tried this obvious and adware and spyware attempt.
Also note: the queries are not going to be encrypted to protect you, the user. They're going to be encrypted to make them less obvious to network monitoring and tougher to block.
Given the history of monitoring technologies embedded in telephone systems, such as the AT&T fiber optics publicized in 2005, it's an ongoing problem. (https://www.eff.org/nsa-spying) Even in the USA, the use of disasters to publicize national security risks and use the intelligence resources granted to prevent foreign threats has been repeatedly used to gather political intelligence and harass political opponents, rather than to prevent crimes or warfare. So it seems reasonable to assume it is not "singular".
One of the most important tasks when discovering an electronic intruder or monitor is to trace if they try to clean up and remove their tracks. This is as true for electronic "spy boxes" as it is for unauthorized network taps, rootkitted servers, and hacked websites. It's too bad the discoverers didn't have the resources to set up a webcam to monitor the spy box, itself, to get data on the vehicle or faces of those removing the spy box.
You can adjust that check frequency setting, 180 days is merely the default. But unless you can schedule to take the file-systems off-line, or put them in read-only mode and run an appropriate "fsck" on them before re-establishing write permission, this is actually a very good idea. There's nothing like the beginning of a disk problem being missed, or a file system corruption tied to a particular bad kernel, to leave a critical system in an unrecoverable state.
For whatever group I work with, whether my own colleages or a business partner, I do try to schedule a reboot of *everything*, and a reboot at least once a year, to make sure that backups are done and tested and all the hardware will reboot successfully when the experts are _not_ available. You might be _amazed_ at the numer of servers described as "it just works" which failed on reboot, and failover systems and redundant connections that were _not_ failing over properly and were _not_ redundant.
I'd assume there is a VPN connection with the hospital's network, for access to patient records by physicians with hospital privileges. What grounds this, or laptops assigned by the hospital, provide for penetration testing create interesting possibilities for responsibility and liability.
I've been on both sides of such security probes, professionally. A legitimate organization will be willing to identify itself and name the most obvious penetration test vectors, because they will show up in the logs of someone competent. It's also especially interesting to conduct a penetration a month _before_ any announced test, and a month or two _after_, to see what has actually been changed.
But as the target of a penetration test, you should be be _encouraged_ to report the attempts to the upstream provider or administration, and you should be notified of the test results. You don't indicate if you've spoken to anyone in hospital IT who has any actual authority or responsibility: a simple letter, _preferably on real paper with a real name of someone who can verify the letter_, identifying that such tests occur and where you can report them, can help protect you, and the hospital, from liability for other attacks that go unnoticed while the penetration test occurs.
I also urge you to review the regulations or laws on confidentiality of patient data. Penetration against secure data where the recovered data is not handled safely can be illegal, and a careful talk with the hospital's legal counsel can help set some guidelines. And this is just the situation where a paper trail, _on paper and kept offsite_, can protect you and your group from lawsuit or from a manager who tries to shift blame. This is especially true when the penetration succeeds, and a mid level manager uses it as ammunition to replace IT staff with a different "big vision" of how security works, even when the IT staff were prohibited from that manager from taking effective steps against the very vulnerabilities used by the penetration test. (I've seen this several times.)
It's not the contractors. It's the bureacrats who manage them. I've known several people in the job: they're underpaid, overworked, given stacks of conflicting policies and procedures, and practices change from particular site manager to site manager with every shift. There are places that do it very well, politely, helpfully, respecting the passengers and the needs of the elderly and children and frightened, tired people. But those careful agents and agencies tend to be at smaller airports.
Thank you, yes, I was speaking of file system corruption. And because any ongoing email management, such as deleting or even marking as read or unread the old messages, causes change in the content of the mbox file, from the message edited onward, the claim that "it's only risking messages after the point where you edit" is disingenuous. I'm afraid it's not "ignorance" speaking, it's lengthy and painful experience.
_If_ the mbox files re absolutely static, then mbox can be considered reasonably stable. But if the messages are resorted into new folders, or even worse if the oldest, earliest entries are ever deleted, then the contents of the mbox file _from that message forward_ have to be rewritten. There is no graceful way with most filesystems to simply "snip this 3095 characters content out of the middle between the start and end of this particular message". The means used can be fascinatingly clever and complex but normally involve overwriting _everything after the beginning of the removal_ with the remaining, preserved old content. And we could explore further what happens on the disk when you actually try to delete content after a certain point in a file, and how that churns the underlying filesystem itself, but it's heavily filesytem dependent.
This means that touching the early entries, and any accidents that occur, corrupts anything after those early entriees. It also means that touching those mbox files causes filesystem churn, becuase the files no longer match the old files and have distinct contents. Unless deletions or additions fo the entries somehow aligns with the old blocks, even most deduplication based filesystems will fail to optimize. And the tendency of some old mbox users to keep _everything_ in simple, large mbox "folders" which are actually single mbox files compounds the issue with backup problems tied to very, very large files, and tied to small edits of those very, very large files causing churn in the backup system.
Having an RFC for an older, simpler protocol does not make it ideal for modern use. mbox was useful when filesystems were distinctly slowed by many hundreds or thousands of files in one directory, and when the number of inodes available for your home directory and the ability to monitor or mange a mailbox in a consistent format was critical. But Maildir and various tools based on it have, correctly, replaced it. The filesystem issues are one critical reason, and the other is what Dan Bernstein talked about when he wrote Maildir: safe locking or transaction handling for multiple simultaneous client access. (See http://cr.yp.to/proto/maildir.html)
Maildir successfully follows one of the critical lessons of robust programming. If you make only small changes, you make only small mistakes, and the message handling is vastly safer from adding, deleting, or relocating small files than from merging or extracting individual messages stored in a necessarily vulnerable single archive.
_NO_. Under no circumstances use "mbox" for mail storage, or anything other than a temporary stage on the way to transferring it to something contemporary and uable such as Maildir. If you lose that one mbox file, by file system corruption or by fat finger accident or overflowing a partition or in tht eprocess of merging new email with it, you've lost _all_ your mail in that mbox. And as you read, mark, or save mail, that file is constantly churning, making backup and replication of the mail spool far more dangerous and fragile, especially when the mail directory is bulky with years or decades of active mail threads or simply undeleted email.
mbox was useful when the available inodes on a file system were limited programs benefited from using a single inode for transactions, and backups occurred on magtape, but there is simply no point to it in decasdes.
Translate it _all_ to IMAP services, in MAILDIR format if available. I've repeatedly been faced with clients, partners, and colleagues who use their email as their insitutional memory and need to migrate to a new service. There are few technologies as straightforward, and robust, as a simiple IMAP server running a light, uncluttered IMAP daemon such as "dovecot", without the complex and nunnecessary requirements of aCyrus IMAP daemon, and most _definitely_ without the complex support requirements of an Exchange, Zimbra, or other corporate grade mail service.
The primary technology difficulty of this approach is in slurping the mail from your numerous external sources and getting it into the consistent layout. Use folders, not database folders but actual directory folders to separate them. Split them by year to reduce the size of the bulkiest folders. (which MAILDIR does very well). The secondary difficulty is a robust offsite backup policy, so that a hardware or system error does not lose this personal treasure trove of data.
Re:A thousand times. (Unless online mirrors roll b
on
Too Perfect a Mirror
·
· Score: 1, Insightful
May I respectfully disagree? I've often seen such focus on what is "out of scope" used to limit cost and to limit the "turf" on which an employer or contractor needs access. But backup is _certainly_ a critical part of source control, just as security is. The ability to replicate a working source control system to other hardware or environments due to failure or corruption of the primary server is critical to any critical source tree. Calling it "out of scope" is like calling security "out of scope". By ignoring the consequences at the design stages of a source control system, very real risks are often taken without even thinking of the possible consequences, and the resources necessary to provide such critical features later can, and often do, multiply the cost of a project in unexpected ways.
A nightly mirror on low-cost hardware with snapshot capability, for example, can provide very useful fallback capability. Even hardlink based softwaer snapshots can work well.. It requires thought to configure correctly, and to schedule the mirrors and make sure they don't conflict with other high bandwidth operations such as tape backup, and to handle "churn" diskspace requirements. And I've had some very good success with partners and clients who took such modest backup tools and saved enormous cost on high-speed tape backup systems high bandwidth connections for remote mirroring facilities, or who had difficulti4es meeting very short backup windows by using the mirror, or the snapshots, to do the tape backups for archival. It does inject a phase delay into the tape backups, and recovery from tape has to be tested, but it's been extremely effective.
Several times, I've found that the problem is a political one. The backup system is often a very expensive, high performance capital cost, or some kind of proprietary "turf" of a manager who is very comfortable with and enamored of it, and they're concerned that adding this layer will make them look foolish for spending the money, or cost them their job as a proprietary owner of critical infrastructure. They already had the political battle purchasing the hardware in the first place and don't care to rehash their previous work. But it's often amazing what staging the backups this way can do for performance and user access to their backed up data. Most restoration cases are due to accidental file deletion or editing, and the users no longer need access to the tape backup system or off-site archival, and only to the snapshots which have read-only access with the same privileges as the original source material.
I'm reading the link you made, snd the original and plain BSD license _is not_ considered free or compatible with GPL. The modified BSD license, that removes the advertising clause, is considered free but dangerous precisely becuase of the kind of confusion you just experienced.
There are _no_ women apparent in the tweeted photo, among the roughly 100 attendees present. Where are you going to find the 10 easy going women, especially when your own employees are rude enough to be making that kind of joke in the audience at a professional conference?
The GPL has been already effectively tested in court, repeatedly. Unfortunately, intellectual property lawyers are scared of the GPL. I discussed it with one 8 days ago: they consider it dangerously viral. I'm trying to arrange a lunch so we can sit down and go over the details of it, so they can understand why I much prefer to use it and I can give examples of companies who pretend to be open source but drive engineer like me nuts when their commercial versions of their "open source" tools break and we can't get source code and can't have any confidence in its security models because they're commercial code is unpublished.
I've also come to loathe the Apache and BSD licenses because when I do work for other groups, I can't easily re-use the work on other projects because I've _already signed_ intellectual property licenses with a previous company under an Apache license. So my work is effectively no longer open source. Many engineers simply ignore such problems, thinking that the development they did on Apache projects is OK to bring to new projects for other companies, and treating Apache licensed development _as if_ they were GPL.
I'm sure mean "when you had AT&T since the breakup of their monopoly", not "AT&T back when they provided analog phones and had the US telephone monopoly".
Earlier in my electrical engineering experience, I actually reconnected 50 and 60 year old phones in old houses to active, analog, land-line circuits from almost any decade between 1920 and 1980, and it _all worked_, including the older phones that were wired directly to wiring jacks inside of wall plates, and lacked modern RJ-11 wiring connectors. (The 1900 era phone took some extra work.) Many, if not most, of those old phones frankly had better sound quality than the modern consumer grade phones. And because the entire setup was analog, they filtered but still carried some small amount of higher frequency signals that modern digital phones _cannot_ carry, particularly useful for sharp sounds that digital analysis and remixing smear. A "bang" or "clatter" including that of hanging up the phone, was much more clear.
There are some very real advantages of modern digital systems, such as more reliable transmission over long distances and easier central switching without mechanical relays. But the robustness of the equipment and overall quality of the equipment that AT&T was providing for consumer use was not one of the problems of older phones.
I'm afraid the title of your note is misleading. Good science, much more than good engineering, involves testing new or old theories, to find how they work in previously untested ways, or to make sure that the previous test was really valid and caught all the important factors. A good graduate school project, involves a constrained project that can be reasonably tested in a few years, that does involve something of interest to the adviser, and that with good luck can be turned into a career of related questions.
The key is to make the initial question relatively simple, so that the concept can be expanded into tests or other related fields as time and funding permits. This isn't asking the "right size" of question, it's asking a question with enough related, interesting implications but that still has relevance if only the simplest parts can be addressed. Let me take an example of something I'd love to find a good thesis for: the cost of using different sorting algorithms.
The maximum computational costs of complex sorting algorithms is well understood (and well described at Wikipedia). But the additional computational cost of maintaining registers is not factored in, especially for small or modest data sets, and the cost of comparison _itself_ between different formats, or between positive and negative numbers, is not factored in to those computational costs. Neither is the cost of a partial sort that has to be started over from scratch or the benefit of algorithms that can be used when it is partially sorted. There is _wonderful_ material for a thesis in that kind of question, and even material for almost immediate application to industry. The preliminary survey and testing work with computational models can be done within a year by someone competent, but testing it against different CPU or software environments would be even more valuable and could easily fill out the rest of a graduate program, even leading to a creer in optimization of computational algorithms.
No, the record companies will simply alter a few words in the same arguments that made the judges waste time before, enough to encourage the court to re-evaluate the suit's merits again, and again, and again. A great deal of software patent law works the same way, as does movie and record company "SLAPP" or "Strategic Lawsuits Against Public Participation". This case is nowhere near enough to help eliminate such abuses precisely because legal fees were not awarded to the victor, who is now bankrupt. This has demonstrated that such ill-founded lawsuits can achieve business goals, even when they lose.
Yes, but I'm referring to the use of geese as guard animals at US military bases. They're less expensive than dogs, and quite effective, and they *can* break your arms with their wings.
This is no longer feasible. Since they did it once, by default, and without graceful means to turn it off or putting clear labels on it, there is *nothing* that will stop them from doing it again or doing similar acts. And it's clear from his own statements about the problem that Mark Shuttleworth, as the leader of Ubuntu, does not understand what the problem is, so it's clear that security is an afterthought for him, not a critical part of what Ubuntu does.
It's like catching your wife in bed with a chicken. We don't *care* if the chicken is certified organic and free-range, it means your wife is into barnyard poultry, and it's only a matter of time until she brings home a goose that can break your arm.
It's not shortsighted, I'm afraid. It's a function of a very limited, proprietary interface to the motherboard, limits on available board space for circuit traces and connectors, limits on cost for those connectors, limits on available valid signals from existing standards such as PCI and PCI-E and SATA and SCSI and SAS, and limitations on the very small amount of "flash" storage allocated for this critical information. Extensibility is a poor second or third goal behind physical reliability, and cost. Investing in a more flexible architecture may be a theoretically useful and interesting improvement, but it's very hard to spend the design work and design time for a feature that will not guarantee a new revenue stream.
Most hardware RAID controllers can be configured as a pure passthrough. That makes them trivial to replace, but reliant on well configured software RAID or backup. Many "budget" configurations for "small office" hardware have had horrible RAID controllers, especially the "hardware RAID" controllers that actually do much of their work with your system CPU and require system resources, just to be advertised as "RAID" servers. And I'm afraid that LSI and their closely related label MegaRAID have been consistently sources of enormous risk for upgrades and instability with their newer components.
Slashdot Mirror
I'm drowning in banal text, for someone clearly overpaid by the word!!!
Seriously, 3 pages of text to repeat the same points 3 or 4 times, then make two conclusions that are orthogonal to his points? Someone needs to edit this material.
This would be much more impressive if they were doing most of the innovation. They're clearly not: it's coming from the upstream Debian conmunity, which they use as a source of drivers, developments, tools, and features. This does not discount the considerable polish they provide. But that is not itself innovation.
To verify this, examine the source history of the Ubuntu kernel, of their Gnoome tool suite, and of any useful system tools such as BIND or Apache.
>> By effectively tracking local user searches, by default, it is clearly spyware.
> You forgot the word "default". Turning it on by default was what made it spyware.
Actually, I did include the words "by default". You even quoted it.
The effective keystroke monitoring in recent Ubuntu monitoring is a _much_ bigger problem. The desktop search result is broadcasting your searches back to the Ubuntu mother company for Amazon search results. Despite Mark's claims, this is not "putting ads in Ubuntu" it is far more than merely adware. By effectively tracking local user searches, by default, it is clearly spyware. Worse, the queries were being sent in clear text, and there was no graceful way to turn it off. Those had to be top level decisions for the new release, and they were terrible decisions.
To quote Mark from his own response to this at http://www.markshuttleworth.com/archives/1182 .
> We are not telling Amazon what you are searching for. Your anonymity is preserved because we handle the query on your behalf. Don’t trust us? Erm, we have root
Mark's claim that "your anonymity is preserved because we handle the query" is nonsensical. Tracking cookies and the sometimes abusive tracking tools of doubleclick.net provide thorough tracking of the search queries and the results, and to automatically be doing This, along with other recent changes, has demonstrated that Mark Shuttleworth and the leadership of the Ubuntu distribution _cannot be trusted_. Having "root" access is not an excuse: it's a reason that Ubuntu should never have even tried this obvious and adware and spyware attempt.
Also note: the queries are not going to be encrypted to protect you, the user. They're going to be encrypted to make them less obvious to network monitoring and tougher to block.
Given the history of monitoring technologies embedded in telephone systems, such as the AT&T fiber optics publicized in 2005, it's an ongoing problem. (https://www.eff.org/nsa-spying) Even in the USA, the use of disasters to publicize national security risks and use the intelligence resources granted to prevent foreign threats has been repeatedly used to gather political intelligence and harass political opponents, rather than to prevent crimes or warfare. So it seems reasonable to assume it is not "singular".
One of the most important tasks when discovering an electronic intruder or monitor is to trace if they try to clean up and remove their tracks. This is as true for electronic "spy boxes" as it is for unauthorized network taps, rootkitted servers, and hacked websites. It's too bad the discoverers didn't have the resources to set up a webcam to monitor the spy box, itself, to get data on the vehicle or faces of those removing the spy box.
You can adjust that check frequency setting, 180 days is merely the default. But unless you can schedule to take the file-systems off-line, or put them in read-only mode and run an appropriate "fsck" on them before re-establishing write permission, this is actually a very good idea. There's nothing like the beginning of a disk problem being missed, or a file system corruption tied to a particular bad kernel, to leave a critical system in an unrecoverable state.
For whatever group I work with, whether my own colleages or a business partner, I do try to schedule a reboot of *everything*, and a reboot at least once a year, to make sure that backups are done and tested and all the hardware will reboot successfully when the experts are _not_ available. You might be _amazed_ at the numer of servers described as "it just works" which failed on reboot, and failover systems and redundant connections that were _not_ failing over properly and were _not_ redundant.
It's not random. I use it instead of asterisks for emphasis without breaking text parsing with wildcards.
I'd assume there is a VPN connection with the hospital's network, for access to patient records by physicians with hospital privileges. What grounds this, or laptops assigned by the hospital, provide for penetration testing create interesting possibilities for responsibility and liability.
I've been on both sides of such security probes, professionally. A legitimate organization will be willing to identify itself and name the most obvious penetration test vectors, because they will show up in the logs of someone competent. It's also especially interesting to conduct a penetration a month _before_ any announced test, and a month or two _after_, to see what has actually been changed.
But as the target of a penetration test, you should be be _encouraged_ to report the attempts to the upstream provider or administration, and you should be notified of the test results. You don't indicate if you've spoken to anyone in hospital IT who has any actual authority or responsibility: a simple letter, _preferably on real paper with a real name of someone who can verify the letter_, identifying that such tests occur and where you can report them, can help protect you, and the hospital, from liability for other attacks that go unnoticed while the penetration test occurs.
I also urge you to review the regulations or laws on confidentiality of patient data. Penetration against secure data where the recovered data is not handled safely can be illegal, and a careful talk with the hospital's legal counsel can help set some guidelines. And this is just the situation where a paper trail, _on paper and kept offsite_, can protect you and your group from lawsuit or from a manager who tries to shift blame. This is especially true when the penetration succeeds, and a mid level manager uses it as ammunition to replace IT staff with a different "big vision" of how security works, even when the IT staff were prohibited from that manager from taking effective steps against the very vulnerabilities used by the penetration test. (I've seen this several times.)
It's not the contractors. It's the bureacrats who manage them. I've known several people in the job: they're underpaid, overworked, given stacks of conflicting policies and procedures, and practices change from particular site manager to site manager with every shift. There are places that do it very well, politely, helpfully, respecting the passengers and the needs of the elderly and children and frightened, tired people. But those careful agents and agencies tend to be at smaller airports.
Thank you, yes, I was speaking of file system corruption. And because any ongoing email management, such as deleting or even marking as read or unread the old messages, causes change in the content of the mbox file, from the message edited onward, the claim that "it's only risking messages after the point where you edit" is disingenuous. I'm afraid it's not "ignorance" speaking, it's lengthy and painful experience.
_If_ the mbox files re absolutely static, then mbox can be considered reasonably stable. But if the messages are resorted into new folders, or even worse if the oldest, earliest entries are ever deleted, then the contents of the mbox file _from that message forward_ have to be rewritten. There is no graceful way with most filesystems to simply "snip this 3095 characters content out of the middle between the start and end of this particular message". The means used can be fascinatingly clever and complex but normally involve overwriting _everything after the beginning of the removal_ with the remaining, preserved old content. And we could explore further what happens on the disk when you actually try to delete content after a certain point in a file, and how that churns the underlying filesystem itself, but it's heavily filesytem dependent.
This means that touching the early entries, and any accidents that occur, corrupts anything after those early entriees. It also means that touching those mbox files causes filesystem churn, becuase the files no longer match the old files and have distinct contents. Unless deletions or additions fo the entries somehow aligns with the old blocks, even most deduplication based filesystems will fail to optimize. And the tendency of some old mbox users to keep _everything_ in simple, large mbox "folders" which are actually single mbox files compounds the issue with backup problems tied to very, very large files, and tied to small edits of those very, very large files causing churn in the backup system.
Having an RFC for an older, simpler protocol does not make it ideal for modern use. mbox was useful when filesystems were distinctly slowed by many hundreds or thousands of files in one directory, and when the number of inodes available for your home directory and the ability to monitor or mange a mailbox in a consistent format was critical. But Maildir and various tools based on it have, correctly, replaced it. The filesystem issues are one critical reason, and the other is what Dan Bernstein talked about when he wrote Maildir: safe locking or transaction handling for multiple simultaneous client access. (See http://cr.yp.to/proto/maildir.html)
Maildir successfully follows one of the critical lessons of robust programming. If you make only small changes, you make only small mistakes, and the message handling is vastly safer from adding, deleting, or relocating small files than from merging or extracting individual messages stored in a necessarily vulnerable single archive.
_NO_. Under no circumstances use "mbox" for mail storage, or anything other than a temporary stage on the way to transferring it to something contemporary and uable such as Maildir. If you lose that one mbox file, by file system corruption or by fat finger accident or overflowing a partition or in tht eprocess of merging new email with it, you've lost _all_ your mail in that mbox. And as you read, mark, or save mail, that file is constantly churning, making backup and replication of the mail spool far more dangerous and fragile, especially when the mail directory is bulky with years or decades of active mail threads or simply undeleted email.
mbox was useful when the available inodes on a file system were limited programs benefited from using a single inode for transactions, and backups occurred on magtape, but there is simply no point to it in decasdes.
Translate it _all_ to IMAP services, in MAILDIR format if available. I've repeatedly been faced with clients, partners, and colleagues who use their email as their insitutional memory and need to migrate to a new service. There are few technologies as straightforward, and robust, as a simiple IMAP server running a light, uncluttered IMAP daemon such as "dovecot", without the complex and nunnecessary requirements of aCyrus IMAP daemon, and most _definitely_ without the complex support requirements of an Exchange, Zimbra, or other corporate grade mail service.
The primary technology difficulty of this approach is in slurping the mail from your numerous external sources and getting it into the consistent layout. Use folders, not database folders but actual directory folders to separate them. Split them by year to reduce the size of the bulkiest folders. (which MAILDIR does very well). The secondary difficulty is a robust offsite backup policy, so that a hardware or system error does not lose this personal treasure trove of data.
May I respectfully disagree? I've often seen such focus on what is "out of scope" used to limit cost and to limit the "turf" on which an employer or contractor needs access. But backup is _certainly_ a critical part of source control, just as security is. The ability to replicate a working source control system to other hardware or environments due to failure or corruption of the primary server is critical to any critical source tree. Calling it "out of scope" is like calling security "out of scope". By ignoring the consequences at the design stages of a source control system, very real risks are often taken without even thinking of the possible consequences, and the resources necessary to provide such critical features later can, and often do, multiply the cost of a project in unexpected ways.
A nightly mirror on low-cost hardware with snapshot capability, for example, can provide very useful fallback capability. Even hardlink based softwaer snapshots can work well.. It requires thought to configure correctly, and to schedule the mirrors and make sure they don't conflict with other high bandwidth operations such as tape backup, and to handle "churn" diskspace requirements. And I've had some very good success with partners and clients who took such modest backup tools and saved enormous cost on high-speed tape backup systems high bandwidth connections for remote mirroring facilities, or who had difficulti4es meeting very short backup windows by using the mirror, or the snapshots, to do the tape backups for archival. It does inject a phase delay into the tape backups, and recovery from tape has to be tested, but it's been extremely effective.
Several times, I've found that the problem is a political one. The backup system is often a very expensive, high performance capital cost, or some kind of proprietary "turf" of a manager who is very comfortable with and enamored of it, and they're concerned that adding this layer will make them look foolish for spending the money, or cost them their job as a proprietary owner of critical infrastructure. They already had the political battle purchasing the hardware in the first place and don't care to rehash their previous work. But it's often amazing what staging the backups this way can do for performance and user access to their backed up data. Most restoration cases are due to accidental file deletion or editing, and the users no longer need access to the tape backup system or off-site archival, and only to the snapshots which have read-only access with the same privileges as the original source material.
I'm reading the link you made, snd the original and plain BSD license _is not_ considered free or compatible with GPL. The modified BSD license, that removes the advertising clause, is considered free but dangerous precisely becuase of the kind of confusion you just experienced.
There are _no_ women apparent in the tweeted photo, among the roughly 100 attendees present. Where are you going to find the 10 easy going women, especially when your own employees are rude enough to be making that kind of joke in the audience at a professional conference?
The GPL has been already effectively tested in court, repeatedly. Unfortunately, intellectual property lawyers are scared of the GPL. I discussed it with one 8 days ago: they consider it dangerously viral. I'm trying to arrange a lunch so we can sit down and go over the details of it, so they can understand why I much prefer to use it and I can give examples of companies who pretend to be open source but drive engineer like me nuts when their commercial versions of their "open source" tools break and we can't get source code and can't have any confidence in its security models because they're commercial code is unpublished.
I've also come to loathe the Apache and BSD licenses because when I do work for other groups, I can't easily re-use the work on other projects because I've _already signed_ intellectual property licenses with a previous company under an Apache license. So my work is effectively no longer open source. Many engineers simply ignore such problems, thinking that the development they did on Apache projects is OK to bring to new projects for other companies, and treating Apache licensed development _as if_ they were GPL.
I'm sure mean "when you had AT&T since the breakup of their monopoly", not "AT&T back when they provided analog phones and had the US telephone monopoly".
Earlier in my electrical engineering experience, I actually reconnected 50 and 60 year old phones in old houses to active, analog, land-line circuits from almost any decade between 1920 and 1980, and it _all worked_, including the older phones that were wired directly to wiring jacks inside of wall plates, and lacked modern RJ-11 wiring connectors. (The 1900 era phone took some extra work.) Many, if not most, of those old phones frankly had better sound quality than the modern consumer grade phones. And because the entire setup was analog, they filtered but still carried some small amount of higher frequency signals that modern digital phones _cannot_ carry, particularly useful for sharp sounds that digital analysis and remixing smear. A "bang" or "clatter" including that of hanging up the phone, was much more clear.
There are some very real advantages of modern digital systems, such as more reliable transmission over long distances and easier central switching without mechanical relays. But the robustness of the equipment and overall quality of the equipment that AT&T was providing for consumer use was not one of the problems of older phones.
I'm afraid the title of your note is misleading. Good science, much more than good engineering, involves testing new or old theories, to find how they work in previously untested ways, or to make sure that the previous test was really valid and caught all the important factors. A good graduate school project, involves a constrained project that can be reasonably tested in a few years, that does involve something of interest to the adviser, and that with good luck can be turned into a career of related questions.
The key is to make the initial question relatively simple, so that the concept can be expanded into tests or other related fields as time and funding permits. This isn't asking the "right size" of question, it's asking a question with enough related, interesting implications but that still has relevance if only the simplest parts can be addressed. Let me take an example of something I'd love to find a good thesis for: the cost of using different sorting algorithms.
The maximum computational costs of complex sorting algorithms is well understood (and well described at Wikipedia). But the additional computational cost of maintaining registers is not factored in, especially for small or modest data sets, and the cost of comparison _itself_ between different formats, or between positive and negative numbers, is not factored in to those computational costs. Neither is the cost of a partial sort that has to be started over from scratch or the benefit of algorithms that can be used when it is partially sorted. There is _wonderful_ material for a thesis in that kind of question, and even material for almost immediate application to industry. The preliminary survey and testing work with computational models can be done within a year by someone competent, but testing it against different CPU or software environments would be even more valuable and could easily fill out the rest of a graduate program, even leading to a creer in optimization of computational algorithms.
No, the record companies will simply alter a few words in the same arguments that made the judges waste time before, enough to encourage the court to re-evaluate the suit's merits again, and again, and again. A great deal of software patent law works the same way, as does movie and record company "SLAPP" or "Strategic Lawsuits Against Public Participation". This case is nowhere near enough to help eliminate such abuses precisely because legal fees were not awarded to the victor, who is now bankrupt. This has demonstrated that such ill-founded lawsuits can achieve business goals, even when they lose.
Yes, but I'm referring to the use of geese as guard animals at US military bases. They're less expensive than dogs, and quite effective, and they *can* break your arms with their wings.
http://www.time.com/time/magazine/article/0,9171,961483,00.html
This is no longer feasible. Since they did it once, by default, and without graceful means to turn it off or putting clear labels on it, there is *nothing* that will stop them from doing it again or doing similar acts. And it's clear from his own statements about the problem that Mark Shuttleworth, as the leader of Ubuntu, does not understand what the problem is, so it's clear that security is an afterthought for him, not a critical part of what Ubuntu does.
It's like catching your wife in bed with a chicken. We don't *care* if the chicken is certified organic and free-range, it means your wife is into barnyard poultry, and it's only a matter of time until she brings home a goose that can break your arm.
It's not shortsighted, I'm afraid. It's a function of a very limited, proprietary interface to the motherboard, limits on available board space for circuit traces and connectors, limits on cost for those connectors, limits on available valid signals from existing standards such as PCI and PCI-E and SATA and SCSI and SAS, and limitations on the very small amount of "flash" storage allocated for this critical information. Extensibility is a poor second or third goal behind physical reliability, and cost. Investing in a more flexible architecture may be a theoretically useful and interesting improvement, but it's very hard to spend the design work and design time for a feature that will not guarantee a new revenue stream.
Most hardware RAID controllers can be configured as a pure passthrough. That makes them trivial to replace, but reliant on well configured software RAID or backup. Many "budget" configurations for "small office" hardware have had horrible RAID controllers, especially the "hardware RAID" controllers that actually do much of their work with your system CPU and require system resources, just to be advertised as "RAID" servers. And I'm afraid that LSI and their closely related label MegaRAID have been consistently sources of enormous risk for upgrades and instability with their newer components.