OneSwarm seems to have a lot more polish than the P2P networks I listed: In-browser previews, codec translation of media files, integration with GoogleTalk, etc.
The basic transfer functionality appears to be similar although based on the invite-only darknet idea. Personally, I do not think these darknets offer much advantage, as the other P2Ps (and also Tor) offer anonymity by maximizing the number of participating nodes... which provides resistance to authorities trying to social-engineer and recruit their way into smaller friend-based networks.
I believe TP is a simply proxy or VPN service. If TP is forced to rat on you by the government, they could conceivably do so by simply starting to log IP data.
OneSwarm is like TOR or I2P in that the needed IP information is beyond the reach of any one entity. Its temporarily distributed through the swarm just long enough to make transfers possible. You would have to own a large chunk of the machines in a swarm to be able to connect/prosecute a user with a particular file or activity.
I2P net MUTE/ Kommute/ Ants/ Dargens Alliancep2p.com Filetopia.org GNUNet Rodi Emscher...and probably more.
Some of these like I2P use bittorrent over their anonymized network (a BT client is built into I2P but you can use some others... Note that Azureus aka Vuze has I2P support built-in!)
...nor is it an operating system to most end users because the kernel + GNU toolchain do not provide services they need.
With that said, the Miro project does NOT package software for other Linux-based distros. Look at their download page for crisesakes.... The non-Ubuntu releases are put together and distributed outside of the Miro project.
And this says it all:
For Miro bugs on Mandriva, use the Mandriva bug tracker.
etc, etc.
The authors do not directly support Miro outside of Windows, OS X and Ubuntu operating systems.
Here I am alluding to Google and Apple as positive examples more than anyone else, and I'm accused of being an MS astroturfer.
If you want One Size Fits All, use Microsoft Vista and Be Happy!
The timeless mad-dog response of a cornered FOSS elitist. You can't even see when people are pointing to things non-Microsoft, as any hint of populism makes you think of the Satan from Redmond.
FWIW, I don't even own a single Windows system, you precious prat-savant.
As someone who used to download/compile kernels from kernel.org (from a browser) to add driver functionality that Debian backports wouldn't provide, I'd say thats some potent Koolaid you're serving.
Most of us here know the difference between a temporary development branch and a fork intended to be permanent, and a general release that receives patches on a regular basis.
We also know it is possible for someone like Linus to allow forking, while still being against it as a matter of preference.
Apple has 10% of the personal computing market now.
I would look to them for an example to emulate... not to Microsoft.
Unix already has a relative object reference system. The system is relative to root and user data relative to home. This hasn't changed in OS X, except there is one more wrinkle where certain packages/appdirs are registered globally with the filesystem.
As for finding system services, not a big issue on a rich and properly-defined platform. The app developer knows what "always" is or isn't included in the system... from there, they have very few "sometimes" components to discover on their own (and in a healthy platform eco-system, this issue works itself out).
Maybe I'm misunderstanding your argument but I don't think so. If a developer develops his software on Slackware or Slamd64 it will work/compile on a widerange of Linux, Unix and BSD platforms. Slackware is also LSB compliant.
Virtually every distro is a superset of the (feeble) LSB spec, so what you say isn't even close to being true.
I think the idea of rallying behind one distro is a bad idea because it will ultimately be some lowest common denominator distro that is heavily GUI based and convoluted with spaghetti code (arguably to make the distro easier for end users) etc..
This is thinking that insists computing platforms are a zero-sum compromise between easy/discoverable interfaces and advanced-user flexibility. IMHO, its an expression of techie subculture trying to shut out end users. Or, if you will, escapism.
As for the accusations of "spaghetti code" etc, I suggest you compare the Apple audio and visual frameworks to what comes with a major desktop distro (BSD or Linux). The latter don't work as claimed because the spaghetti code that has arisen around many different sets of user expectations (use cases) and multiply-duplicated efforts (each one too small to be robust) is collapsing upon itself.
Yes, this is a problem for commercial software publishers, because linux distributions are usually not binary compatible with others in terms of library dependencies.
No, it's a problem for FOSS developers, too (not that they are necessarily the best example of application developers to follow, mind you).
Windows and Mac users typically get major upgrades of Firefox and OOo (and many other FOSS apps) well in advance of their Linux-using counterparts. Care to guess why??
I'll tell you: Its because the last mile of packaging and testing has to be done by each Linux distro before a new app release is allowed into the repository. In application development circles, this is seen as giving the OS developers/managers a job for which they are very much unqualified.
Can you tell me what rpm or deb based distribution you are using that makes it so hard?
SURPRISE. I'm using Ubuntu 8.04, which is stuck with OpenOffice 2.4. I would upgrade myself, however I have a number of end-user installations I have to support and not willing to foist an Ubuntu-unsupported office suite on them (replete with the skanky print and file dialogs that make users navigate from root for every file transaction, and other integration failures).
APT only seems better than YUM/RPM because Debian does extra work to include as many different projects as possible. In the end, it does not solve the basic incompatibility that distro-culture has with personal computing.
I find it interesting that end-users are able to sense (unconsciously or otherwise) this incompatibility and generally avoid switching to, uh, "Linux".
The problem with LSB is that it is really meant only to make life easier for vendors of proprietary software.
I suggest reading the last 2 paragraphs of my first comment. I gave examples of two open source apps (Firefox and OOo) that can't devote resources to providing properly debugged and finished packages for Linux-based distros because there is no set target or proper way to do it.
We've had the disappearing radio-button problem on Firefox Linux for years now, but noone quite seems to care or coordinate enough to solve it. Likewise, Mozilla has thrown its hands up in disgust over trying to make user-installable packages.
The result is that FF on Linux is unusable by novices in many situations (radio buttons are too important)... browser self-updates can't work by definition... user updates are too hard... and if you stick with an LTS release of an OS, then your apps get left in the dust.
Ubutu had to include Firefox BETA in the initial Ubuntu 8.04 LTS release because they knew 8.04 could get stuck with an old browser for 2 years if they stayed with FF 2.x for the time being.
But they didn't do the same with OpenOffice! Now we are stuck with OOo 2.4!!!
Yay "Linux"!!! Where isn't NOT the job of developers to package and distribute their own software to end users!
Worse than that: It'll be a GUI for a toddler that has to be administered by someone with Sysadmin skills, due to lack of poor vertical integration with the rest of the OS.
We don't need yet another GUI -- We need a reference platform, from the kernel up through the GUI control panel. We need a holistic starting point that tech support departments, end-users and app developers alike can confidently work with (and build deltas from when required).
And except for Android, I know of no Linux-based platforms aimed at normal users and/or app developers.
Distros are too fluid and there are too many of them anyway. This situation makes coding-for and independently distributing PC applications very confusing.
The only things that would rectify the situation would be to create a fully-spec'd out and vertically-integrated (up through the GUI) platform like Android, or have the community get behind something like LSB Desktop. The latter does not seem to be happening though because it it being marketed to neither users nor app developers AFAIK.
Notice there was no mention of LSB in the article -- There's almost zero awareness of it.
I would like to point out that Linus is against forking the kernel, and his group essentially demands a unified kernel and toolchain (with different distros having different configurations of these pieces).
But when it comes to higher-level stuff that end-users require, they complain about one-size-fits all. Frankly, that attitude says to me that the audio and video architectures in Linux-based desktops will continue to be slipshod and wobbly (unstable performance and unstable APIs), and you can forget about widespread adoption at the consumer level until either the Torvalds mentality dissipates or an Android moves into the desktop space.
I think Torvalds & Co. are hypocrites who prefer showing off to their coder pals, users be damned. Even worse, they're foul-mouthed trolls who regularly make personal attacks on people they dislike while insisting on civility being directed towards themselves.
Linux will continue to act as repellent to ambitious application developers looking to make their mark or a buck. We'll have to be content for the forsee-able future with ham-fisted G-, K-, X- apps that are usually mere shadows of what they imitate.
Alas, even excellent software like Firefox doesn't get major UI flaws (like radio buttons always disappearing) because of this situation... Mozilla doesn't even bother packaging their apps for "Linux" anymore... you gotta unzip it to/usr and make all the correct linkages and icons yourself.
The other great FOSS app, OpenOffice.org, is fairly complex to install/upgrade even with rpm/deb packages... and proper desktop integration will be either absent or badly broken. Again, SUN/OOo would rather attempt a fit-and-finish on proper platforms like OS X and Windows than play the bitten-by-a-hundred-repository-hackers game.
Yes, choice, variety, and competition are horrible things aren't they?
Yes... the official word from projects like the Linux kernel, Gnome, KDE, etc. is that competition has nothing to do with it... Especially with respect to competing with Windows or Mac OS X.
Show me two consumer-oriented FOSS projects that are both successful and not OOo or Firefox.
The practice of generally substituting the word "Ubuntu" for "Linux" in postings, comments, stories, etc, is not only annoying, it is insulting to the many thousands of people who have contributed to Linux (GNU/Linux) and all the non-Ubuntu distributions.
Well that is too bad, because "Linux" has no UI or other features that are easily distinguish-able by end-users. Different distros are different operating systems that happen to share a kernel... Other Linux-based distros are not entitled to the marketing success or Ubuntu or any other distros.
If you want to see more of an all-for-one spirit, I suggest working toward a core desktop OS spec. that most distros will share and enforce. Until then, stop pushing "Linux" as if it were a user-oriented OS you deluded fool!
Understanding the OS innards is valuable but overrated here. It is having a platform (which Linux isn't) where the supplied APIs and UI are predictable and serve as a supportable common ground for ISVs and users.
"Linux" (or more accurately: the typical Linux-based distro) doesn't provide that support of personal computing culture. As a result, you tend to get app developers who are primarily interested in the workings of the OS, and interested in applications second or third or mainly as a way of showing-off to their hacker friends.
Another big problem is that the community wants control of driver development, but doesn't want to take responsibility when the system software doesn't fit the hardware properly and causes big problems as a result. It puts hardware developers in a backseat role when it comes to writing and especially distributing drivers. They know that an end-user will typically blame the entity that distributed the software that made their hardware run poorly... so the OEM's incentive to avoid bugs and slipshod default configurations is diminished.
Yes, there be bugs in hardware and firmware. BUT that highlights one of the value-adding properties of software: Work-arounds. The Windows and OS X ecosystems have their methods and incentives for getting workarounds applied in a timely and effective manner.
There is only one solution to these problems: Stabilize the core of "Desktop Linux" upto and including the desktop environment level, and stop trying to provide a comprehensive selection of drivers and applications-- they aren't properly a part of the OS and should be someone else's responsibility. It is the only way to make "Linux" friendly to independent hardware and application developers alike.
If you want an idea of what a proper platform (standardized UI, APIs, SDK, etc.) in FOSS looks like then Android would be a good place to start looking IMO.
if you're that paranoid, it's fairly easy to have the OS wipe all user & program data from the memory at shutdown.
IMO that is no solution. A system can be easily reset/halted before an OS has a chance to neatly shut down.
Creating "Security RAM" modules would be more effective: Equipped with a capacitor for power, they could self-wipe at the hardware level when they detect a reset signal or power interruption. Given the precarious nature of info esp. on laptops, one would think this category of RAM would have already been developed.
Its not the 'EXT3' thing he's complaining about. Programs on Linux get split up and splattered across a bunch of different directories.
End users never quite seem to know where they are going on Linux systems because of FHS the main volume is a sort of nameless slash, and not supposed to even BE in most of those top-level dirs... only/home/username.
OTOH on OSX (which otherwise is Unix) at least each mounted volume will show up in the upper-left of the Finder and under/Volumes.
1. Any self-generated cert (even self-signed) which has been directly copied from the service provider (bank, etc.) and imported into the browser.
Though this is the most secure, it is a shame that the user may receive warnings from other Firefox users who visited the site about the cert being "Invalid", undermining confidence in this most secure method of using certs.
If the certificate is imported into the browser as a trusted certificate you don't get the warning, that's the point.
The invalid warnings are for when the certificate has been sent over an untrusted connection and you have no assurance that the certificate is the correct one for the site. In this case, flashing a huge warning in the user's face is absolutely the right thing to do since at the moment, all legitimate online shops have a certificate verified by a third party.
Huge warning Yes; Incorrectly-worded warning that passes judgment on the cert before the user even wonders if it can be verified... NO.
The old behavior used a big warning without condemning the cert. Unfortunately it gave the used an option to just accept the cert and make a connect without even viewing it.
The correct change to make IMO would be to remove the "Continue" button and instead force the user to import the cert before continuing with a connection. Then the certs would be handled more like SSH keys; an attacker would have to maintain constant MITM from the user's first login in order to fool them - very unlikely.
More than that, the browser could show th SHA1 finger print in any/all cert warnings. This would encourage banks, merchants, etc. to start printing their fingerprints along with their URL on bank statements, invoices or other correspondence, facilitating a strong out-of-band verification.
The trusted third party solution we have currently is the most convenient since it's all automatic and transparent to the user. What we're recently finding is that some of these trusted third parties are not turstworthy.
I agree. But the transparency is bad in this case because the responsibility can only ever be in the user's hands; the web would have to become rigidly authoritarian otherwise. People need to be able to handle keys responsibly in the digital world as they do in the physical one. PC systems should make certs and keys more tangible to end-users, letting them grab, move, examine, collect and most importantly recognize them in a heartbeat. It should be possible to designate a flash card expressly for storing certs/keys and passwords to be carried around in one's wallet, purse or keychain.
First, this issue is about banks (for instance) verifying themselves to the client, not the other way around, so not sure how OTPs and such figure into this.
Overall, between the drama over one of Comodo's trustee CAs handing out certs without verification (for mozilla.com no less) and this MD5 attack, there is a lesson on this for Mozilla:
Trusted CAs aren't the epitome of web safety. In fact, they are LESS safe than one of those "Invalid" (to use Mozilla's ill-chosen words) self-signed certificates under some circumstances.
I put the ranking of https safety as follows:
1. Any self-generated cert (even self-signed) which has been directly copied from the service provider (bank, etc.) and imported into the browser.
Though this is the most secure, it is a shame that the user may receive warnings from other Firefox users who visited the site about the cert being "Invalid", undermining confidence in this most secure method of using certs.
2. Any self-generated cert (even self-signed) verified by SHA1 fingerprint "out of bank" (e.g. letter or phone call or even email) then imported into the browser. Unfortunately the easiest method to initiate this procedure (visit the site, verify then click on a button to import) is now somewhat broken in Firefox and will quite inappropriately undermine the user's confidence in what is otherwise a very secure cert.
3. Relying on the browser-trusted CAs. Unfortunately there now many of them which are obscure even in the tech community, and some are sloppy and incompetent.
Do you really think Joe Sixpack is smart enough to know how to do that, even if he is given step-by-step instructions?
I do.
But the real problem is that keys and certs are very crucial entities in computing, and today's desktop systems do not represent them properly to the user. A key or a cert sitting on a desktop or a flash drive just looks like a text file or nothing at all.
There needs to be a class of descriptive icons that people will come to associate with keys (which will encrypt) and certs (which will identify and/or encrypt) - along with proper associations to utilities that will handle them. As with storage devices, text documents and such there are many examples of general ways to represent objects and actions that are standard across platforms. Key/certs don't have this and is the primary reason why average users don't bother with them: Users literally have nothing recognizable to grab onto.
Beyond that, the idea of these not-like-physical-keys security objects have a private and a public part really won't be hard to grasp for most people (esp. since most users at this point have grown up with computers).
In short, proper and robust GUI representation (with animation) is required, and long overdue as today's systems are easily up to the task. For instance, have a standard "control" (class with display component) that any app can embed into its GUI, and that shows something being done to the data during encryption, decryption, signing and verification would be ideal.
Slashdot Mirror
OneSwarm seems to have a lot more polish than the P2P networks I listed: In-browser previews, codec translation of media files, integration with GoogleTalk, etc.
The basic transfer functionality appears to be similar although based on the invite-only darknet idea. Personally, I do not think these darknets offer much advantage, as the other P2Ps (and also Tor) offer anonymity by maximizing the number of participating nodes... which provides resistance to authorities trying to social-engineer and recruit their way into smaller friend-based networks.
I believe TP is a simply proxy or VPN service. If TP is forced to rat on you by the government, they could conceivably do so by simply starting to log IP data.
OneSwarm is like TOR or I2P in that the needed IP information is beyond the reach of any one entity. Its temporarily distributed through the swarm just long enough to make transfers possible. You would have to own a large chunk of the machines in a swarm to be able to connect/prosecute a user with a particular file or activity.
Try the following:
I2P net ...and probably more.
MUTE/ Kommute/ Ants/ Dargens
Alliancep2p.com
Filetopia.org
GNUNet
Rodi
Emscher
Some of these like I2P use bittorrent over their anonymized network (a BT client is built into I2P but you can use some others... Note that Azureus aka Vuze has I2P support built-in!)
Because the CLI ought to be a DRM-friendly environment!
Then again even Apple is busy removing DRM from iTMS, so perhaps the BSD folk are just wasting their time.
...the anti-TOR and other anonymous networks act.
...nor is it an operating system to most end users because the kernel + GNU toolchain do not provide services they need.
With that said, the Miro project does NOT package software for other Linux-based distros. Look at their download page for crisesakes.... The non-Ubuntu releases are put together and distributed outside of the Miro project.
And this says it all:
For Miro bugs on Mandriva, use the Mandriva bug tracker.
etc, etc.
The authors do not directly support Miro outside of Windows, OS X and Ubuntu operating systems.
Funny,
Here I am alluding to Google and Apple as positive examples more than anyone else, and I'm accused of being an MS astroturfer.
If you want One Size Fits All, use Microsoft Vista and Be Happy!
The timeless mad-dog response of a cornered FOSS elitist. You can't even see when people are pointing to things non-Microsoft, as any hint of populism makes you think of the Satan from Redmond.
FWIW, I don't even own a single Windows system, you precious prat-savant.
As someone who used to download/compile kernels from kernel.org (from a browser) to add driver functionality that Debian backports wouldn't provide, I'd say thats some potent Koolaid you're serving.
Most of us here know the difference between a temporary development branch and a fork intended to be permanent, and a general release that receives patches on a regular basis.
We also know it is possible for someone like Linus to allow forking, while still being against it as a matter of preference.
Apple has 10% of the personal computing market now.
I would look to them for an example to emulate... not to Microsoft.
Unix already has a relative object reference system. The system is relative to root and user data relative to home. This hasn't changed in OS X, except there is one more wrinkle where certain packages/appdirs are registered globally with the filesystem.
As for finding system services, not a big issue on a rich and properly-defined platform. The app developer knows what "always" is or isn't included in the system... from there, they have very few "sometimes" components to discover on their own (and in a healthy platform eco-system, this issue works itself out).
Maybe I'm misunderstanding your argument but I don't think so. If a developer develops his software on Slackware or Slamd64 it will work/compile on a widerange of Linux, Unix and BSD platforms. Slackware is also LSB compliant.
Virtually every distro is a superset of the (feeble) LSB spec, so what you say isn't even close to being true.
I think the idea of rallying behind one distro is a bad idea because it will ultimately be some lowest common denominator distro that is heavily GUI based and convoluted with spaghetti code (arguably to make the distro easier for end users) etc..
This is thinking that insists computing platforms are a zero-sum compromise between easy/discoverable interfaces and advanced-user flexibility. IMHO, its an expression of techie subculture trying to shut out end users. Or, if you will, escapism.
As for the accusations of "spaghetti code" etc, I suggest you compare the Apple audio and visual frameworks to what comes with a major desktop distro (BSD or Linux). The latter don't work as claimed because the spaghetti code that has arisen around many different sets of user expectations (use cases) and multiply-duplicated efforts (each one too small to be robust) is collapsing upon itself.
Yes, this is a problem for commercial software publishers, because linux distributions are usually not binary compatible with others in terms of library dependencies.
No, it's a problem for FOSS developers, too (not that they are necessarily the best example of application developers to follow, mind you).
Windows and Mac users typically get major upgrades of Firefox and OOo (and many other FOSS apps) well in advance of their Linux-using counterparts. Care to guess why??
I'll tell you: Its because the last mile of packaging and testing has to be done by each Linux distro before a new app release is allowed into the repository. In application development circles, this is seen as giving the OS developers/managers a job for which they are very much unqualified.
Can you tell me what rpm or deb based distribution you are using that makes it so hard?
SURPRISE. I'm using Ubuntu 8.04, which is stuck with OpenOffice 2.4. I would upgrade myself, however I have a number of end-user installations I have to support and not willing to foist an Ubuntu-unsupported office suite on them (replete with the skanky print and file dialogs that make users navigate from root for every file transaction, and other integration failures).
APT only seems better than YUM/RPM because Debian does extra work to include as many different projects as possible. In the end, it does not solve the basic incompatibility that distro-culture has with personal computing.
I find it interesting that end-users are able to sense (unconsciously or otherwise) this incompatibility and generally avoid switching to, uh, "Linux".
The problem with LSB is that it is really meant only to make life easier for vendors of proprietary software.
I suggest reading the last 2 paragraphs of my first comment. I gave examples of two open source apps (Firefox and OOo) that can't devote resources to providing properly debugged and finished packages for Linux-based distros because there is no set target or proper way to do it.
We've had the disappearing radio-button problem on Firefox Linux for years now, but noone quite seems to care or coordinate enough to solve it. Likewise, Mozilla has thrown its hands up in disgust over trying to make user-installable packages.
The result is that FF on Linux is unusable by novices in many situations (radio buttons are too important)... browser self-updates can't work by definition... user updates are too hard... and if you stick with an LTS release of an OS, then your apps get left in the dust.
Ubutu had to include Firefox BETA in the initial Ubuntu 8.04 LTS release because they knew 8.04 could get stuck with an old browser for 2 years if they stayed with FF 2.x for the time being.
But they didn't do the same with OpenOffice! Now we are stuck with OOo 2.4!!!
Yay "Linux"!!! Where isn't NOT the job of developers to package and distribute their own software to end users!
Worse than that: It'll be a GUI for a toddler that has to be administered by someone with Sysadmin skills, due to lack of poor vertical integration with the rest of the OS.
We don't need yet another GUI -- We need a reference platform, from the kernel up through the GUI control panel. We need a holistic starting point that tech support departments, end-users and app developers alike can confidently work with (and build deltas from when required).
This segregation between OS layers isn't working.
Platforms do.
And except for Android, I know of no Linux-based platforms aimed at normal users and/or app developers.
Distros are too fluid and there are too many of them anyway. This situation makes coding-for and independently distributing PC applications very confusing.
The only things that would rectify the situation would be to create a fully-spec'd out and vertically-integrated (up through the GUI) platform like Android, or have the community get behind something like LSB Desktop. The latter does not seem to be happening though because it it being marketed to neither users nor app developers AFAIK.
Notice there was no mention of LSB in the article -- There's almost zero awareness of it.
I would like to point out that Linus is against forking the kernel, and his group essentially demands a unified kernel and toolchain (with different distros having different configurations of these pieces).
But when it comes to higher-level stuff that end-users require, they complain about one-size-fits all. Frankly, that attitude says to me that the audio and video architectures in Linux-based desktops will continue to be slipshod and wobbly (unstable performance and unstable APIs), and you can forget about widespread adoption at the consumer level until either the Torvalds mentality dissipates or an Android moves into the desktop space.
I think Torvalds & Co. are hypocrites who prefer showing off to their coder pals, users be damned. Even worse, they're foul-mouthed trolls who regularly make personal attacks on people they dislike while insisting on civility being directed towards themselves.
Linux will continue to act as repellent to ambitious application developers looking to make their mark or a buck. We'll have to be content for the forsee-able future with ham-fisted G-, K-, X- apps that are usually mere shadows of what they imitate.
Alas, even excellent software like Firefox doesn't get major UI flaws (like radio buttons always disappearing) because of this situation... Mozilla doesn't even bother packaging their apps for "Linux" anymore... you gotta unzip it to /usr and make all the correct linkages and icons yourself.
The other great FOSS app, OpenOffice.org, is fairly complex to install/upgrade even with rpm/deb packages... and proper desktop integration will be either absent or badly broken. Again, SUN/OOo would rather attempt a fit-and-finish on proper platforms like OS X and Windows than play the bitten-by-a-hundred-repository-hackers game.
...how likely is it that the US will overtake the EU?
How much you wanna bet they'll be sending-up Battlestar Galactica every chance they get? With a title like "Back to Earth"...
They conduct raids without the police.
Yes, choice, variety, and competition are horrible things aren't they?
Yes... the official word from projects like the Linux kernel, Gnome, KDE, etc. is that competition has nothing to do with it... Especially with respect to competing with Windows or Mac OS X.
Show me two consumer-oriented FOSS projects that are both successful and not OOo or Firefox.
The practice of generally substituting the word "Ubuntu" for "Linux" in postings, comments, stories, etc, is not only annoying, it is insulting to the many thousands of people who have contributed to Linux (GNU/Linux) and all the non-Ubuntu distributions.
Well that is too bad, because "Linux" has no UI or other features that are easily distinguish-able by end-users. Different distros are different operating systems that happen to share a kernel... Other Linux-based distros are not entitled to the marketing success or Ubuntu or any other distros.
If you want to see more of an all-for-one spirit, I suggest working toward a core desktop OS spec. that most distros will share and enforce. Until then, stop pushing "Linux" as if it were a user-oriented OS you deluded fool!
Understanding the OS innards is valuable but overrated here. It is having a platform (which Linux isn't) where the supplied APIs and UI are predictable and serve as a supportable common ground for ISVs and users.
"Linux" (or more accurately: the typical Linux-based distro) doesn't provide that support of personal computing culture. As a result, you tend to get app developers who are primarily interested in the workings of the OS, and interested in applications second or third or mainly as a way of showing-off to their hacker friends.
Another big problem is that the community wants control of driver development, but doesn't want to take responsibility when the system software doesn't fit the hardware properly and causes big problems as a result. It puts hardware developers in a backseat role when it comes to writing and especially distributing drivers. They know that an end-user will typically blame the entity that distributed the software that made their hardware run poorly... so the OEM's incentive to avoid bugs and slipshod default configurations is diminished.
Yes, there be bugs in hardware and firmware. BUT that highlights one of the value-adding properties of software: Work-arounds. The Windows and OS X ecosystems have their methods and incentives for getting workarounds applied in a timely and effective manner.
There is only one solution to these problems: Stabilize the core of "Desktop Linux" upto and including the desktop environment level, and stop trying to provide a comprehensive selection of drivers and applications-- they aren't properly a part of the OS and should be someone else's responsibility. It is the only way to make "Linux" friendly to independent hardware and application developers alike.
If you want an idea of what a proper platform (standardized UI, APIs, SDK, etc.) in FOSS looks like then Android would be a good place to start looking IMO.
OpenOffice has Python scripting built-in. However you can't use the built-in IDE for Python; you'll need to use an external editor.
http://wiki.services.openoffice.org/wiki/Python
if you're that paranoid, it's fairly easy to have the OS wipe all user & program data from the memory at shutdown.
IMO that is no solution. A system can be easily reset/halted before an OS has a chance to neatly shut down.
Creating "Security RAM" modules would be more effective: Equipped with a capacitor for power, they could self-wipe at the hardware level when they detect a reset signal or power interruption. Given the precarious nature of info esp. on laptops, one would think this category of RAM would have already been developed.
Its not the 'EXT3' thing he's complaining about. Programs on Linux get split up and splattered across a bunch of different directories.
End users never quite seem to know where they are going on Linux systems because of FHS the main volume is a sort of nameless slash, and not supposed to even BE in most of those top-level dirs... only /home/username.
OTOH on OSX (which otherwise is Unix) at least each mounted volume will show up in the upper-left of the Finder and under /Volumes.
If the certificate is imported into the browser as a trusted certificate you don't get the warning, that's the point.
The invalid warnings are for when the certificate has been sent over an untrusted connection and you have no assurance that the certificate is the correct one for the site. In this case, flashing a huge warning in the user's face is absolutely the right thing to do since at the moment, all legitimate online shops have a certificate verified by a third party.
Huge warning Yes; Incorrectly-worded warning that passes judgment on the cert before the user even wonders if it can be verified... NO.
The old behavior used a big warning without condemning the cert. Unfortunately it gave the used an option to just accept the cert and make a connect without even viewing it.
The correct change to make IMO would be to remove the "Continue" button and instead force the user to import the cert before continuing with a connection. Then the certs would be handled more like SSH keys; an attacker would have to maintain constant MITM from the user's first login in order to fool them - very unlikely.
More than that, the browser could show th SHA1 finger print in any/all cert warnings. This would encourage banks, merchants, etc. to start printing their fingerprints along with their URL on bank statements, invoices or other correspondence, facilitating a strong out-of-band verification.
The trusted third party solution we have currently is the most convenient since it's all automatic and transparent to the user. What we're recently finding is that some of these trusted third parties are not turstworthy.
I agree. But the transparency is bad in this case because the responsibility can only ever be in the user's hands; the web would have to become rigidly authoritarian otherwise. People need to be able to handle keys responsibly in the digital world as they do in the physical one. PC systems should make certs and keys more tangible to end-users, letting them grab, move, examine, collect and most importantly recognize them in a heartbeat. It should be possible to designate a flash card expressly for storing certs/keys and passwords to be carried around in one's wallet, purse or keychain.
First, this issue is about banks (for instance) verifying themselves to the client, not the other way around, so not sure how OTPs and such figure into this.
Overall, between the drama over one of Comodo's trustee CAs handing out certs without verification (for mozilla.com no less) and this MD5 attack, there is a lesson on this for Mozilla:
Trusted CAs aren't the epitome of web safety. In fact, they are LESS safe than one of those "Invalid" (to use Mozilla's ill-chosen words) self-signed certificates under some circumstances.
I put the ranking of https safety as follows:
1. Any self-generated cert (even self-signed) which has been directly copied from the service provider (bank, etc.) and imported into the browser.
Though this is the most secure, it is a shame that the user may receive warnings from other Firefox users who visited the site about the cert being "Invalid", undermining confidence in this most secure method of using certs.
2. Any self-generated cert (even self-signed) verified by SHA1 fingerprint "out of bank" (e.g. letter or phone call or even email) then imported into the browser. Unfortunately the easiest method to initiate this procedure (visit the site, verify then click on a button to import) is now somewhat broken in Firefox and will quite inappropriately undermine the user's confidence in what is otherwise a very secure cert.
3. Relying on the browser-trusted CAs. Unfortunately there now many of them which are obscure even in the tech community, and some are sloppy and incompetent.
Do you really think Joe Sixpack is smart enough to know how to do that, even if he is given step-by-step instructions?
I do.
But the real problem is that keys and certs are very crucial entities in computing, and today's desktop systems do not represent them properly to the user. A key or a cert sitting on a desktop or a flash drive just looks like a text file or nothing at all.
There needs to be a class of descriptive icons that people will come to associate with keys (which will encrypt) and certs (which will identify and/or encrypt) - along with proper associations to utilities that will handle them. As with storage devices, text documents and such there are many examples of general ways to represent objects and actions that are standard across platforms. Key/certs don't have this and is the primary reason why average users don't bother with them: Users literally have nothing recognizable to grab onto.
Beyond that, the idea of these not-like-physical-keys security objects have a private and a public part really won't be hard to grasp for most people (esp. since most users at this point have grown up with computers).
In short, proper and robust GUI representation (with animation) is required, and long overdue as today's systems are easily up to the task. For instance, have a standard "control" (class with display component) that any app can embed into its GUI, and that shows something being done to the data during encryption, decryption, signing and verification would be ideal.