The primary (and legitimately, the only) purpose of the certificate is to verify the site's Internet address. i.e. that the site you are now talking to is the one that successfully applied for that domain name or IP in the first place.
So checking for A) the lock and B) correct domain in the address bar at the same time should strongly validate in your mind that there is no MITM, even if DNS is being attacked. This is all providing that C) no cert warnings appeared. If any one of those three 'legs' is missing, then the security table falls down... you cannot trust the connection.
If CA's backing up the above process is not good enough for you, then consider contacting the site operator "out of band" such as over telephone (heck, maybe in person) and verify their certificate's fingerprint. If it matches then you can safely import their certificate into your browser and be assured of a secure connection.
The only thing more secure than the above is having the operator give you a copy of their certificate in person.
And all of the above is predicated on both yours and the site's systems not being compromised with malware or unauthorized access.
Xero seems to be one among many web-based services that will introduce issues of uptime and privacy, which for myself (and hopefully most people reading this) are frankly unacceptable.
It has online functions, will run on any desktop platform, and (unlike Quicken) its file formats are fully documented/open which will help prevent your data from being held captive by that program.
Also your sensitive data stays on your computer, not sitting on the software vendor's server waiting for god-knows-what to happen.
Having seen the trouble other programs have with importing Quicken data, I'd say we need to petition them to fully document their file formats. Otherwise, people will feel trapped and unable to migrate to Mac or Linux (WINE notwithstanding) if they want to use all of their old account data.
Quicken for Windows is a nasty tangled beast, and mainly that is because of its custom UI. You can actually see it painting the display in agonizing detail on machines 1.5GHz. Clearly they are not getting much use out of standard Microsoft libraries.
Why, then, not jump to Java as other apps are doing? Moneydance, an up-and coming program with most of Quicken's functions runs on any desktop platform because of Java. Its easily 5x as nimble as Quicken too.
FWIW, my bf uses Quicken and is moving to Linux. We have figured out how to get it running properly under WINE (just install normally, say yes to the part about installing gecko, then initiate the Quicken self-update... very important).
I'd guess that you could also use Quicken like this under Mac WINE.
I will also make a point of mentioning Kmymoney and GNUcash as alternatives.
If you compile them in a distro-specific fashion, perhaps. But it is not particularly difficult to produce a Linux binary that will work on practically any distro (for any given processor architecture, obviously).
And with that you usually end up with an app that has its own GUI toolkit built-in, is ugly as sin, gets things like cut-and-paste (and other GUI conventions) all wrong, and rather slow. I hope I don't have to remind you what a very long road it was to even get the fonts to render correctly in the available office suites.
The FOSS community has some great accomplishments, but it just hasn't internalized the concept of a stable desktop platform (a predictable user interface and set of APIs). Any group of people who had internalized it would instantly recognize that it would be meaningless for Apple, for instance, to market Darwin or XNU to end-users. Yes, yes! Darwin 'usually' implies that the rest of OS X is there too... But it still isn't accurate or tangible to users.
In short, the whole idea of promoting "Linux" to end-users is truly F{x0r.
Promoting Ubuntu is OK. Promoting Android is OK (and is a better example of a real platform than Ubuntu). IMO the desktop distros need to watch and learn from Android and OS X.
Also technically, the "operating system" is the program which interfaces with the hardware and runs all the other programs.
Bzzzt! Try again. If the target audience is non-programmers (almost everyone) then the OS must interface with more than just hardware; It must have a USER interface. Hence, a user can use the hardware via the OS. But Linux per se has no recognizable user interface that a typical user would ever care about.
Linux is pretty faceless: Like an Invisible Man that wears different clothes and masks (user interfaces) at different times. It can't readily be identified by most people, and anyone doing tech support for a "Linux compatible" application or peripheral won't be able to efficiently direct a user through the GUI as the various distro configurations will prevent it. The wildly varying "core" libraries of each distro will also create unending dependency headaches.
A full-featured platform complete with standard GUI and developer toolkit is another story. Such a Linux-based thing does exist: Google Android.
Note that Google isn't marketing their "Linux". That would be like Toyota marketing engine parts to your grandmother.
I will go a bit further and caution against raising a generation of students that view intrusion/lockdown and censorship of their own machines as normal. It's a VERY bad precedent, and I suggest converting the school's laptop program to either a computer financing assistance program, or having the students borrow what are clearly understood to be the school's laptops.
In short, AC's school district is on the wrong track unless they want to teach surveillance culture and "computer literacy" that amounts to everything under the hood being hands-off. The schools need mind their own business, i.e. monitor and defend their school computers and networks, and stay out of student's computers the way they would stay out of the engine compartments of students' cars.
IcedTea lacks decent JNLP (Webstart) support (supporting only 1.0 of the file format), thus some games and applications that use, say, v 1.5 will fail to start. JNLP is how most Java applications are started over the web now.
Except for a few major apps, I put all of my new programs into a subfolder called 'Mystuff' and use the dock or Quicksilver to launch them. Never had a problem.
The free software culture hasn't adapted well to the role of desktop OS. People expect to use a desktop system that is managed by some entity not just as an OS, but as a platform:
There will be defaults that are amenable to the expectations of the user *and* the application developer. There will be a default IDE with a comprehensive set of APIs and best practices that are promoted to the developer base (whereas LSB is mostly ignored in the FOSS world). There will be a CLEAR concept of what hardware is supported (Linux only states what CPU is supported; compatibility for anything else requires try-and-see investigations). There will be hardware for which drivers can be easily installed (whereas drivers supplied for Linux may occasionally appear, will require CLI use, and will disappear as soon as the kernel receives an automatic update).
On 'Linux' there is confusion about 'Linux' user interfaces (not just the Desktop env. question, but the defaults used from distro to distro), which makes tech support for an independent application very difficult and expensive. There is the constant moving target of 6-month release cycles (not security and bug fixes that mostly keep backward compatibility, but 'new versions' with new features and changed defaults that interact in ways that app developers can't anticipate).
There is also the really rotten expectation that most users have to limit themselves to the apps that are offered in the distro's repository. Likewise, OS distro maintainers/packagers are expected to be the first point of contact for handling bugs and many fine-grained aspects of those apps which those package maintainers are unqualified to handle. As a result, apps features keep getting regressed and fat-fingered by maintainers while app developers become more isolated from their Linux user base.
If an app developer wants to mold their dream into a reality, the roiling sea of Linux-based distros is not likely to be their first or second choice of platform. OTOH, end-users aren't likely to even be able to recognize "Linux" any more than they could tell what brand of gasoline is in a car by looking at it; yet we keep idiotically marketing "Linux" to end users (thankfully, Google does not partake in that mania with their marketing of Linux-based Android).
Here is what must be done:
Define a personal computing platform, not 'distro', distros were for coders and techs and the concept couldn't be adapted to novices).
Make sure all levels of system development (even the kernel folks) are aware of the main use cases for desktop users. Don't have use cases with your requirements? Then draft some! This is why we've had terrible video and audio architecture for over a decade.
Choose a default IDE and market the platform to developers, whose target should be something like 'LSB Desktop 4.0'. Make it clear that the platform is a good common ground for them and their target audience to interface.
The platform must have a standard way to install packages from ISVs. An RPM file format is not good enough... package names and versions must be synchronize, and there must be a built-in command to start the install.
The platform must not shy away from full desktop functionality. It must specify what happens when my software rings while the MP3 player is running and I'm in the next room. That spec must show which components in the platform fulfill that behavior. (i.e. Linux + GNU + X11 = Not specific or meaningful enough to users and app devs).
Get a trademark (not the penguin, that's for the kernel) and market/license it (for a penny, if necessary) to hardware vendors: Give them a clear path to validating and then SHOWING compatibility with the platform. I want to be able to walk into a store and see that logo next to the Windows and OSX logos on a Wifi or 3G device.
Finally, yes I know that Windows is awful. I've got an HP printer driver installed on XP, but have to add another instance of the printer to get the settings right... lo and behold, Windows can't find the driver for the 'new' equipment even through the driver is already present. Terrible!
But - Windows is relatively predictable and accessible. Those are the two main requirements for a general-purpose desktop platform.
If you look at the numbers, the majority of the files on a Linux desktop are not "small files" (by much I mean files substantially smaller than a blocksize).
That's not what most people would call 'small files'. HFS+ on OSX defines a small file as something less than 20MB; anything upto that threshold is a candidate for on-the-fly defragmentation. Personally I think thats a good value; something between a large song file and a short TV show.
As far as whether or not the defaults of ext3 are "acceptable" or not --- it's open source! You can change the defaults if you want, or a distribution can change the defaults if they want.
No.
The FOSS "eco-system" (community) of systems and app developers needs to find a way of arriving at reasonable defaults on its own. We ARE talking about the desktop here, and I'm not into making my customers suffer with a bizarrely-behaving OS the moment I'm no longer available to do custom remixes. If the users in question were back end sysadmins then it would be no problem, but introducing this dynamic onto the desktop will always fail unless your model is centrally-administered thin clients.
I suppose I could add a tuning knob to/etc/mke2fs.conf so you can change the defaults for your system.
Yes, its called 'vertical integration' - regarded with hostility in FOSS circles. Hence, a trip to the support/forum areas of even the 'user-friendliest' of distros (Ubuntu, say) looks like CLI bootcamp.
Regardless, I think it's rather silly to choose an open source filesystem based on whether you like the defaults. After all, Homo Sapiens is a thinking animal; it has the ability to think for itself, and if it doesn't care about the safety of the files stored on the filesystems (or he/she knows that it is protected in other ways, such as RAID-6 with hot sparse, PLUS regular full and incremental backups) he/she can use different filesystem tunining parameters. Or the defaults can be changed --- if you want to distribute a fork of e2fsprogs called "fast and loose with your data progs", there is absolutely nothing in the GPL which stops you from doing that.
Why would I do that?? I would simply become known in Linux tech circles as the person who "made data less secure for unsuspecting rubes". And maybe EXT is less reliable without regular fsck-ing but I don't want to find out. The fact that I have to ponder this as a technical and a political dilemma underlines the failure in the system architecture.
The situation is similar to the disaster known as Linux audio, only less acute. What user audience were they thinking of when they designed and re-re-designed the audio subsystem? As usual, it only seems to fit technically sophisticated users who rarely use sound anyway... like all those webmasters who use Windows or OSX for their groupware with audible meeting alerts, softphone, music player, etc. all able to function at once, alongside a single-purpose built test server and N production servers offsite. Its beyond cliche and endemic even at IBM.
Eh? You don't get a fsck on mount by default with ext3 unless you've exceeded either the check interval or max mount count.
Yes, you've described the default behavior of EXT3 and its unacceptable. Would YOU like to explain the concept those concepts you mentioned to my end-users?
I won't. Its needless as there are much better filesystems for the desktop.
Then that means Linux as a whole has some serious (even terminal) problems with internal politics. If an open codebase like ReiserFS can die from those politics, then so can the whole kernel.
And its not like the audio and task-switching parts of the kernel haven't been suffering. Now its filesystems too.
As it stands now, I'll tolerate a 10-second checkup at boot over a 10-15 min. fsck. And though I know how to skip the latter and what the ramifications are, my associates do not and understandably do not want to learn.
The Enigma extension for Thunderbird exists, is rather nice, and isn't setting the computer security market on fire.
Likewise, SMIME is built into modern email clients (and is dead-simple to use in Outlook Express) but is rarely used.
WE, the computer cognoscenti, the IT Crowd, have not brought our co-workers, family and other end-users over the psychological threshold that marks the transition from "password user" to "key user".
The main disincentive is that contemporary desktop operating systems do not make the key and the certificate into a tangible object such as a document, photo or mp3 file. There are no truly unified key-management "keychain" programs; keys and cert files do not get an intuitive icon and association with a keychain manager. So when regular users and power users start to grapple with signing and encryption, they become uneasy and frustrated in ways that the metal keys in their pockets or magnetic keys in their wallets do not.
Make it easy for people to actually handle keys and certs system-wide, and very many will begin using them.
The default behavior of EXT filesystems to launch a sometimes lengthy fsck while booting really throws computer novices for a loop; they get scared, or impatient or worse.
Also, I don't think the logic of using EXT3 for large partitions containing large files quite holds up: 1) deleting large files is slow, 2) when fsck strikes you are bound to have a long wait.
EXT3's forte isn't small files either. I just don't think its a very good filesystem. If EXT4 doesn't address more than storage space issues, then I'll take a pass on that as well.
XFS is still inappropriate for most hardware setups, IMO.
I think that will pretty much leave ReiserFS and JFS as my main options.
It doesn't make those attacks futile. You can detect them, sure, but if you're getting bogus information from your DNS server, that's still a denial of service (because you can't get the real address of the site).
The same DOS issue applies to DNSSEC. It is not magic and cannot overcome determined interference... it can only prevent you from using falsified data as if it were genuine.
Plus all that an adversary would need to do is watch the DNS requests as they come in to find out where people are going.
Neither technology was intended to provide anonymity for the 'who' of the connection, but SSL does hide the 'what' of our data. And though SSL was not meant for anonymity, it is the basis for anonymity in onion routing schemes like Tor, I2P and others.
Now, you can encrypt the payloads (see IPSec), but you can't encrypt the destination address.
That is what onion routing is for. I suggest you read up on the Tor project, where the destination address is indeed encrypted and can't be traced back to the client.
But anonymity isn't required in order for encryption over conventional links to add a great deal of privacy.
Because SSL and DNSSEC solve two different problems. Unless you're doing DNS-over-SSL, which means running DNS in TCP mode.
I don't think so. A primary motivation for PKI-backed SSL was to protect against any misdirection, whether at the domain-name or IP address level.
DNS over TCP isn't being suggested here. Normal DNS with a PKI-using protocol like HTTPS is what provides the protection I'm talking about. Its the scheme you and I already use whenever we make a purchase or do online banking.
In the case of HTTPS, a interfering with either DNS resolution or misrouting an IP address will cause the connection to stop with a warning. In the case of DNSSEC, interference will generate an error message that most server and client software does not understand.
With SSL/HTTPS/etc. the address is verified outside the DNS protocol. But it is still verified. Moving that verification into DNS doesn't really help unless you prefer to see most internet traffic remain unencrypted.
Slashdot Mirror
The primary (and legitimately, the only) purpose of the certificate is to verify the site's Internet address. i.e. that the site you are now talking to is the one that successfully applied for that domain name or IP in the first place.
So checking for A) the lock and B) correct domain in the address bar at the same time should strongly validate in your mind that there is no MITM, even if DNS is being attacked. This is all providing that C) no cert warnings appeared. If any one of those three 'legs' is missing, then the security table falls down... you cannot trust the connection.
If CA's backing up the above process is not good enough for you, then consider contacting the site operator "out of band" such as over telephone (heck, maybe in person) and verify their certificate's fingerprint. If it matches then you can safely import their certificate into your browser and be assured of a secure connection.
The only thing more secure than the above is having the operator give you a copy of their certificate in person.
And all of the above is predicated on both yours and the site's systems not being compromised with malware or unauthorized access.
Xero seems to be one among many web-based services that will introduce issues of uptime and privacy, which for myself (and hopefully most people reading this) are frankly unacceptable.
...and try MoneyDance.
It has online functions, will run on any desktop platform, and (unlike Quicken) its file formats are fully documented/open which will help prevent your data from being held captive by that program.
Also your sensitive data stays on your computer, not sitting on the software vendor's server waiting for god-knows-what to happen.
Having seen the trouble other programs have with importing Quicken data, I'd say we need to petition them to fully document their file formats. Otherwise, people will feel trapped and unable to migrate to Mac or Linux (WINE notwithstanding) if they want to use all of their old account data.
Quicken for Windows is a nasty tangled beast, and mainly that is because of its custom UI. You can actually see it painting the display in agonizing detail on machines 1.5GHz. Clearly they are not getting much use out of standard Microsoft libraries.
Why, then, not jump to Java as other apps are doing? Moneydance, an up-and coming program with most of Quicken's functions runs on any desktop platform because of Java. Its easily 5x as nimble as Quicken too.
FWIW, my bf uses Quicken and is moving to Linux. We have figured out how to get it running properly under WINE (just install normally, say yes to the part about installing gecko, then initiate the Quicken self-update... very important).
I'd guess that you could also use Quicken like this under Mac WINE.
I will also make a point of mentioning Kmymoney and GNUcash as alternatives.
If you compile them in a distro-specific fashion, perhaps. But it is not particularly difficult to produce a Linux binary that will work on practically any distro (for any given processor architecture, obviously).
And with that you usually end up with an app that has its own GUI toolkit built-in, is ugly as sin, gets things like cut-and-paste (and other GUI conventions) all wrong, and rather slow. I hope I don't have to remind you what a very long road it was to even get the fonts to render correctly in the available office suites.
The FOSS community has some great accomplishments, but it just hasn't internalized the concept of a stable desktop platform (a predictable user interface and set of APIs). Any group of people who had internalized it would instantly recognize that it would be meaningless for Apple, for instance, to market Darwin or XNU to end-users. Yes, yes! Darwin 'usually' implies that the rest of OS X is there too... But it still isn't accurate or tangible to users.
In short, the whole idea of promoting "Linux" to end-users is truly F{x0r.
Promoting Ubuntu is OK. Promoting Android is OK (and is a better example of a real platform than Ubuntu). IMO the desktop distros need to watch and learn from Android and OS X.
Also technically, the "operating system" is the program which interfaces with the hardware and runs all the other programs.
Bzzzt! Try again. If the target audience is non-programmers (almost everyone) then the OS must interface with more than just hardware; It must have a USER interface. Hence, a user can use the hardware via the OS. But Linux per se has no recognizable user interface that a typical user would ever care about.
Linux is pretty faceless: Like an Invisible Man that wears different clothes and masks (user interfaces) at different times. It can't readily be identified by most people, and anyone doing tech support for a "Linux compatible" application or peripheral won't be able to efficiently direct a user through the GUI as the various distro configurations will prevent it. The wildly varying "core" libraries of each distro will also create unending dependency headaches.
A full-featured platform complete with standard GUI and developer toolkit is another story. Such a Linux-based thing does exist: Google Android.
Note that Google isn't marketing their "Linux". That would be like Toyota marketing engine parts to your grandmother.
... silence
Excellent response.
I will go a bit further and caution against raising a generation of students that view intrusion/lockdown and censorship of their own machines as normal. It's a VERY bad precedent, and I suggest converting the school's laptop program to either a computer financing assistance program, or having the students borrow what are clearly understood to be the school's laptops.
In short, AC's school district is on the wrong track unless they want to teach surveillance culture and "computer literacy" that amounts to everything under the hood being hands-off. The schools need mind their own business, i.e. monitor and defend their school computers and networks, and stay out of student's computers the way they would stay out of the engine compartments of students' cars.
IcedTea lacks decent JNLP (Webstart) support (supporting only 1.0 of the file format), thus some games and applications that use, say, v 1.5 will fail to start. JNLP is how most Java applications are started over the web now.
Except for a few major apps, I put all of my new programs into a subfolder called 'Mystuff' and use the dock or Quicksilver to launch them. Never had a problem.
Samba isn't perfect but it works better for dynamic IP, has reasonable performance and generally doesn't get into locking hell.
Its also slow, is a beast to configure, and chokes on multi-gigabyte transfers... actually truncating and mangling files.
I don't think is necessarily Samba-specific. I've had much the same experiences with the genuine Windows stuff too.
In general, I've learned that tools like scp and secure rsync are more reliable.
...since DVDs etc. can be retrieved with any high-res optical scanner. You just have to fetch the software to read it.
The free software culture hasn't adapted well to the role of desktop OS. People expect to use a desktop system that is managed by some entity not just as an OS, but as a platform:
There will be defaults that are amenable to the expectations of the user *and* the application developer. There will be a default IDE with a comprehensive set of APIs and best practices that are promoted to the developer base (whereas LSB is mostly ignored in the FOSS world). There will be a CLEAR concept of what hardware is supported (Linux only states what CPU is supported; compatibility for anything else requires try-and-see investigations). There will be hardware for which drivers can be easily installed (whereas drivers supplied for Linux may occasionally appear, will require CLI use, and will disappear as soon as the kernel receives an automatic update).
On 'Linux' there is confusion about 'Linux' user interfaces (not just the Desktop env. question, but the defaults used from distro to distro), which makes tech support for an independent application very difficult and expensive. There is the constant moving target of 6-month release cycles (not security and bug fixes that mostly keep backward compatibility, but 'new versions' with new features and changed defaults that interact in ways that app developers can't anticipate).
There is also the really rotten expectation that most users have to limit themselves to the apps that are offered in the distro's repository. Likewise, OS distro maintainers/packagers are expected to be the first point of contact for handling bugs and many fine-grained aspects of those apps which those package maintainers are unqualified to handle. As a result, apps features keep getting regressed and fat-fingered by maintainers while app developers become more isolated from their Linux user base.
If an app developer wants to mold their dream into a reality, the roiling sea of Linux-based distros is not likely to be their first or second choice of platform. OTOH, end-users aren't likely to even be able to recognize "Linux" any more than they could tell what brand of gasoline is in a car by looking at it; yet we keep idiotically marketing "Linux" to end users (thankfully, Google does not partake in that mania with their marketing of Linux-based Android).
Here is what must be done:
Define a personal computing platform, not 'distro', distros were for coders and techs and the concept couldn't be adapted to novices).
Make sure all levels of system development (even the kernel folks) are aware of the main use cases for desktop users. Don't have use cases with your requirements? Then draft some! This is why we've had terrible video and audio architecture for over a decade.
Choose a default IDE and market the platform to developers, whose target should be something like 'LSB Desktop 4.0'. Make it clear that the platform is a good common ground for them and their target audience to interface.
The platform must have a standard way to install packages from ISVs. An RPM file format is not good enough... package names and versions must be synchronize, and there must be a built-in command to start the install.
The platform must not shy away from full desktop functionality. It must specify what happens when my software rings while the MP3 player is running and I'm in the next room. That spec must show which components in the platform fulfill that behavior. (i.e. Linux + GNU + X11 = Not specific or meaningful enough to users and app devs).
Get a trademark (not the penguin, that's for the kernel) and market/license it (for a penny, if necessary) to hardware vendors: Give them a clear path to validating and then SHOWING compatibility with the platform. I want to be able to walk into a store and see that logo next to the Windows and OSX logos on a Wifi or 3G device.
Finally, yes I know that Windows is awful. I've got an HP printer driver installed on XP, but have to add another instance of the printer to get the settings right... lo and behold, Windows can't find the driver for the 'new' equipment even through the driver is already present. Terrible!
But - Windows is relatively predictable and accessible. Those are the two main requirements for a general-purpose desktop platform.
...or you have to press the "Install" button in the add-on dialog while you're at an untrusted site.
The article is a bit vague, but ultimately this is just a Trojan.
If you look at the numbers, the majority of the files on a Linux desktop are not "small files" (by much I mean files substantially smaller than a blocksize).
That's not what most people would call 'small files'. HFS+ on OSX defines a small file as something less than 20MB; anything upto that threshold is a candidate for on-the-fly defragmentation. Personally I think thats a good value; something between a large song file and a short TV show.
As far as whether or not the defaults of ext3 are "acceptable" or not --- it's open source! You can change the defaults if you want, or a distribution can change the defaults if they want.
No.
The FOSS "eco-system" (community) of systems and app developers needs to find a way of arriving at reasonable defaults on its own. We ARE talking about the desktop here, and I'm not into making my customers suffer with a bizarrely-behaving OS the moment I'm no longer available to do custom remixes. If the users in question were back end sysadmins then it would be no problem, but introducing this dynamic onto the desktop will always fail unless your model is centrally-administered thin clients.
I suppose I could add a tuning knob to /etc/mke2fs.conf so you can change the defaults for your system.
Yes, its called 'vertical integration' - regarded with hostility in FOSS circles. Hence, a trip to the support/forum areas of even the 'user-friendliest' of distros (Ubuntu, say) looks like CLI bootcamp.
Regardless, I think it's rather silly to choose an open source filesystem based on whether you like the defaults. After all, Homo Sapiens is a thinking animal; it has the ability to think for itself, and if it doesn't care about the safety of the files stored on the filesystems (or he/she knows that it is protected in other ways, such as RAID-6 with hot sparse, PLUS regular full and incremental backups) he/she can use different filesystem tunining parameters. Or the defaults can be changed --- if you want to distribute a fork of e2fsprogs called "fast and loose with your data progs", there is absolutely nothing in the GPL which stops you from doing that.
Why would I do that?? I would simply become known in Linux tech circles as the person who "made data less secure for unsuspecting rubes". And maybe EXT is less reliable without regular fsck-ing but I don't want to find out. The fact that I have to ponder this as a technical and a political dilemma underlines the failure in the system architecture.
The situation is similar to the disaster known as Linux audio, only less acute. What user audience were they thinking of when they designed and re-re-designed the audio subsystem? As usual, it only seems to fit technically sophisticated users who rarely use sound anyway... like all those webmasters who use Windows or OSX for their groupware with audible meeting alerts, softphone, music player, etc. all able to function at once, alongside a single-purpose built test server and N production servers offsite. Its beyond cliche and endemic even at IBM.
It seems to be doing something to me. Reiserfs is known to go through a checkup phase when it mounts; this usually obviates the need for a fsck.
Maybe my HDs are just louder/more noticeable than yours?
Eh? You don't get a fsck on mount by default with ext3 unless you've exceeded either the check interval or max mount count.
Yes, you've described the default behavior of EXT3 and its unacceptable. Would YOU like to explain the concept those concepts you mentioned to my end-users?
I won't. Its needless as there are much better filesystems for the desktop.
But reiserFS support is dwindling...
Then that means Linux as a whole has some serious (even terminal) problems with internal politics. If an open codebase like ReiserFS can die from those politics, then so can the whole kernel.
And its not like the audio and task-switching parts of the kernel haven't been suffering. Now its filesystems too.
As it stands now, I'll tolerate a 10-second checkup at boot over a 10-15 min. fsck. And though I know how to skip the latter and what the ramifications are, my associates do not and understandably do not want to learn.
The Enigma extension for Thunderbird exists, is rather nice, and isn't setting the computer security market on fire.
Likewise, SMIME is built into modern email clients (and is dead-simple to use in Outlook Express) but is rarely used.
WE, the computer cognoscenti, the IT Crowd, have not brought our co-workers, family and other end-users over the psychological threshold that marks the transition from "password user" to "key user".
The main disincentive is that contemporary desktop operating systems do not make the key and the certificate into a tangible object such as a document, photo or mp3 file. There are no truly unified key-management "keychain" programs; keys and cert files do not get an intuitive icon and association with a keychain manager. So when regular users and power users start to grapple with signing and encryption, they become uneasy and frustrated in ways that the metal keys in their pockets or magnetic keys in their wallets do not.
Make it easy for people to actually handle keys and certs system-wide, and very many will begin using them.
The default behavior of EXT filesystems to launch a sometimes lengthy fsck while booting really throws computer novices for a loop; they get scared, or impatient or worse.
Also, I don't think the logic of using EXT3 for large partitions containing large files quite holds up: 1) deleting large files is slow, 2) when fsck strikes you are bound to have a long wait.
EXT3's forte isn't small files either. I just don't think its a very good filesystem. If EXT4 doesn't address more than storage space issues, then I'll take a pass on that as well.
XFS is still inappropriate for most hardware setups, IMO.
I think that will pretty much leave ReiserFS and JFS as my main options.
It doesn't make those attacks futile. You can detect them, sure, but if you're getting bogus information from your DNS server, that's still a denial of service (because you can't get the real address of the site).
The same DOS issue applies to DNSSEC. It is not magic and cannot overcome determined interference... it can only prevent you from using falsified data as if it were genuine.
Plus all that an adversary would need to do is watch the DNS requests as they come in to find out where people are going.
Again no different with DNSSEC, since it does not encrypt anything... it only signs/verifies. Here is a nice overview with diagram.
Neither technology was intended to provide anonymity for the 'who' of the connection, but SSL does hide the 'what' of our data. And though SSL was not meant for anonymity, it is the basis for anonymity in onion routing schemes like Tor, I2P and others.
The PKI part of SSL can be used to verify addresses, and to exchange symmetric keys that can be used with any TCP or non-TCP stream.
Now, you can encrypt the payloads (see IPSec), but you can't encrypt the destination address.
That is what onion routing is for. I suggest you read up on the Tor project, where the destination address is indeed encrypted and can't be traced back to the client.
But anonymity isn't required in order for encryption over conventional links to add a great deal of privacy.
Because SSL and DNSSEC solve two different problems. Unless you're doing DNS-over-SSL, which means running DNS in TCP mode.
I don't think so. A primary motivation for PKI-backed SSL was to protect against any misdirection, whether at the domain-name or IP address level.
DNS over TCP isn't being suggested here. Normal DNS with a PKI-using protocol like HTTPS is what provides the protection I'm talking about. Its the scheme you and I already use whenever we make a purchase or do online banking.
In the case of HTTPS, a interfering with either DNS resolution or misrouting an IP address will cause the connection to stop with a warning. In the case of DNSSEC, interference will generate an error message that most server and client software does not understand.
With SSL/HTTPS/etc. the address is verified outside the DNS protocol. But it is still verified. Moving that verification into DNS doesn't really help unless you prefer to see most internet traffic remain unencrypted.