That archive contains (very old) sourcecode for bash, you can download it from gnu.org too assuming they haven't removed such old versions. You won't be able to get it compiled and running on amigaos, no idea why someone would want to mirror old non amiga sourcecode on aminet either.
It seems like kingcon merges some of the functions of a terminal with that of the shell, while unix keeps them in separate apps. From its readme, the features it provides have long been provided by x11 terminals such as konsole or gnome terminal.
Also you have to ask yourself, after you've installed kingcon to replace the console device, and various other modifications... how much of the original amigaos are you actually using?
It's unlikely anyone would want an x11 window manager that explicitly emulates the amiga desktop (and what desktop would you emulate? most amiga users tended to modify the default workbench quite heavily)... Once you take off your rose tinted glasses you will realise that while it may have a few nice features, not to mention the fact your clearly familiar and comfortable with it, it is by no means the best interface out there and also has its fair share of deficiencies. What you talked about was "stackable, push/pull windows" which several window managers can provide when configured accordingly. While i prefer this behaviour, i would not sacrifice virtual workspaces (no, "screens" provided by amigaos are not the same) among other things to use amigaos. The x11 model lets you pick and choose the best features.
X11 based systems have thousands of window managers, some of which behave exactly like you describe and there are so many possibilities you can find one which exactly suits your needs. Dynamic ram drive? Try/dev/shm on linux, or/tmp on solaris. RAD:? Modern computers don't need to reboot anywhere near as often as amigaos did, even windows is pretty stable these days so the utility of a reset resident ram drive is fairly limited. And then you have flash drives, and you can even get pcie cards with a load of ram on them for very fast storage.
King con is a shell handler (ie a terminal emulator), bash is a shell... King con is more like xterm and you can run all manner of shells in it (tho i dont believe bash was ever ported to amigaos due to the lack of fork()?)... The two are not directly comparable, and bash is far more powerful than the standard amigaos shell scripting language.
If you're running Linux, then there are several window managers which provide the behaviour you desire... I always used to run windowmaker with a focus follows mouse configuration, where only clicking on the titlebar would bring the window to the front.
The idea of buying an 800mhz (single core?) desktop in 2009 seems pretty insane... Sure there is a place for low power hardware, but only when it's cheap (eg look at raspberry pi)...
Having hardware that expensive ensures that no new users will ever take up the hobby, which means slow development, no economies of scale so the prices remain high etc...
Also if you read the article, they are doing the bare minimum to comply with the MPL... That is, they are releasing source code for any modified mozilla files, but won't be releasing any new files they create, and almost certainly won't be committing their work back to mozilla. This means their port will always lag behind, you will have to wait for binaries to be provided, and won't be able to compile it yourself let alone make any changes or improvements.
Yes, the blatant attempts at profiteering were the final nail in the coffin for the Amiga... Back when i had a (relatively highend) Amiga, in order to connect it to the internet i would have needed to buy a tcp stack, and then buy a browser, even things like ftp, irc and telnet clients had a price tag attached! Even MS and Apple don't charge extra for basic things like that.
And AmigaOS 4, not only expensive in its own right (even free niche os's have trouble gaining traction, what hope does an expensive one have?), but it's also tied to proprietary hardware that is insanely overpriced, under specced and not widely available.
Put it this way, lots of people are willing to try AROS, its a free download and will run happily on hardware that the vast majority of people already have at their disposal. It will run happily on old hardware which you may have laying around, can boot as a livecd so as not to affect your existing installation and can run inside of common virtualization software. You've nothing to lose, and anyone can try it. Contrast that with AmigaOS 4, you have to pay several hundred EUR (last i checked) for the hardware, plus an additional 100+ for the copy of AmigaOS, and then if you don't like the OS or find that it doesn't suit your needs all you have to show for it is a very slow linux box.
Safer purely due to security through obscurity... AmigaOS has virtually no security features, it doesn't even have a concept of users or of protected address space so a vulnerability in any userland application is effectively a kernel level exploit.
Latency of 100ms is terrible to anything thats not on a different continent.
Currently i have both DSL and Cable at home, and latency to my server (hosted in a DC about 20 miles away, but hosted by a completely different isp to either of the dsl/cable providers) is about 12ms on dsl and 40ms on cable... It's also the peak usage time for home broadband connections right now, and my latency on cable is considerably better off-peak. This is also tested from my laptop, which is connected via wifi.
Traceroute shows 13 hops either way (first one being my router), although on the dsl it enters the target isp at hop 10 vs 8 for the cable.
Instead of installing it, you just untar it into a dir... And when you start it, you use -profilemanager so that each instance uses its own profile. If you intentionally have multiple versions, i assume your using it for testing so there's little reason to upgrade any particular instance, only install newer versions as necessary.
If a proprietary platform is no longer supported, there is little point expending significant effort to port software to it if the os vendor is never intending to update it.
While OSX/PPC and win2k are no longer supported by their vendors, the hardware capable of running these are capable of running linux, and linux/ppc has an updated version of firefox available for it.
The source for this software is available, and there are people who port modern browsers to older proprietary platforms, but its more useful to have a modern os and browser rather than just a modern browser.
Because it's out of support, it will never get patched against any new security holes which are discovered... Because it's closed source there is little scope for patching it yourself, or having a third party provide patches... Because the system isn't very modular, it's also harder to strip it down and minimise the possible exploitation vectors...
Keeping such a system on the internet is irresponsible, wether it works or not. Not only does the owner of the system risk having everything they do on the system compromised, there is also the risk that a compromise of this system could lead to compromise of other systems (eg this box is probably behind his nat gateway, and from here other systems could be scanned, there might even be common passwords shared across systems). Then there's the rest of the internet to think about, if this system was compromised it could be used to spread spam or attack others.
The system could be upgraded to XP, at least for the next couple of years... There are also plenty of currently supported linux distributions designed specifically for lowend hardware (some are designed for considerably older hardware than this).
The hashes should be salted, but Im not sure what to make of the accusation that the network protocols send hashes for authentication. What would you rather have them send? The plaintext password?
The plaintext password, when sent over an appropriately encrypted channel would actually be a much better option for a number of reasons. By allowing the hash to be used, it effectively becomes the plaintext as you can use it for authentication, the actual plaintext becomes irrelevant since you never actually need it. Google for "pass the hash". If you acquire the hash database, then you now have _ALL_ the (plaintext equivalent) hashes ready for immediate use... Also in such a scheme every client has to implement the same hashing algorithm. This i consider a design flaw, since you are now stuck with a given hashing algorithm unless you can update ALL your clients, and this is probably the biggest reason why they still use a weak non salted algorithm (aside from the lack of salts, the algorithm is MD4 based and considerably weaker than modern algorithms used on unix systems).
If you send the plaintext, then only the server needs to know the hashing algorithm and thus can change it without breaking compatibility as new stronger algorithms become available. Although you could capture the plaintext if you controlled client or server at the time of authentication, you could still do this by capturing plaintext-equivalent hashes. There are many other ways to capture hashes, such as backups, not to mention multiple use of the same password on different systems which yields the same hash due to the lack of salting.
AD login uses a combination of Kerberos and NTLM... Kerberos allows the use of tokens for single sign on, and these tokens become invalid once a user logs out... Windows also however stores the hashes when your logged in (eg on a domain member system), so if you capture those instead then they will remain valid until the user changes their password. You can authenticate using the hash, and acquire a new kerberos token whenever you want. By contrast in a unix environment, you would typically log in using your plaintext password to acquire a kerberos token which you can use for further authentication.
The use of links in your home directory is completely separate from file and registry virtualization, the latter is to allow poorly written software which expects to write to system locations to think it has succeeded, whereas the former is just linking previous paths. Although it brings up other questions.. Why did they choose to move the location of user homedirs? There was nothing inherently bad with the previous location... And why is software hard coded like that? You don't see unix software failing because the user has/export/home/blah instead of/home/blah for their homedir.
You mention or 32/64 nodes also reminds me, 32bit software seems to be installed by default in a different location to 64bit, this also seems strange and messy.
As for removing compatibility cruft... Rosetta was always an optional install on OSX, you could choose not to install it and indeed OSX 10.7 no longer includes it at all. Similarly, 32bit libraries on 64bit linux distributions are referred to as multilib, and are optional... If you don't intend to run any 32bit applications then you can remove them (or simply choose never to have installed them at all). I'm not saying that sets of compatibility libs shouldn't be available, i'm saying they should be optional and easily removed for those of us who don't need them. Sure this *would* break old software, but some of us have no need to run old software, especially on servers which typically only serve a single purpose. Also since most linux software comes with source code, the vast majority of it can (and has been) be recompiled to work on a 64bit system.
What software did you use on ubuntu 7.10 which no longer works on a modern 64bit linux distro?
You have to acquire a copy of the private key, and then you can make your own cryptographic signatures at will... But you do absolutely require a copy of the key. You can also verify with a very high degree of certainty that a cryptographic signature was signed by a particular private key. Thus the only practical avenue for nefarious activity, is to acquire knowledge of the private key...
A signature on the other hand is totally arbitrary, anyone can make a random mark on a piece of paper and call it a signature... Even *if* a comparison is made to one stored on file, it has to be a fuzzy match because regardless of how much you try it would never be quite the same twice. I have been asked to "sign" all manner of forms recently, and they all look wildly different...
Similarly, if someone presents a piece of paper and claims you "signed" it, whats to stop you simply denying that it was you? Unless they have video footage of you actually doing it, it pretty much boils down to your word against theirs.
And how exactly is this different from any other investment opportunity or currency? A volatile investment can mean big rewards or big losses, and smaller investments are more likely to be volatile due to the ability of a smaller group to influence the market price more easily. Investments can crash and burn, currencies have also crashed and burned in the past... Investing in anything is a gamble, and with higher risk comes the potential of bigger reward. Or if you're a bank, zero risk because the taxpayer will bail you out if the investment doesn't pay off.
Well, that's a rather inefficient use... There are various services you can buy directly with bitcoins, like hosted servers, domain names etc... There are even goods you can buy online with bitcoins and have physically shipped to you.
Bitcoin is also very useful as a way of paying people in foreign countries, avoiding the high fees imposed by banks and services such as paypal.
And somehow signatures and rubber stamps are more viable than a cryptographic signature? Anyone can make a rubber stamp... Anyone can "sign" a piece of paper... It's considerably harder to fake a cryptographic signature.
You've not addressed the issues of the hashing algorithms, does this mean you accept these design flaws?
SSH can indeed be used for many things, however... What ssh really does is give you interactive shell access, the fact that you can do additional things with it is down to the inherent flexibility of being able to pipe arbitrary data over a TTY... It's more analogous to remote desktop, in that you'd only provide access to administrative users or those who you intended to have interactive access. The protocol is also pretty clearly demarcated, in that none of this functionality is available until you have completed the authentication stage, unlike many MS protocols where many functions are available with/without authentication, depending on configuration and some provide different functionality depending on wether you are authenticated or not..
32/64 issues - on linux you can choose between a 32, hybrid 32/64 or pure 64bit system as your needs dictate, with windows its necessary to have the 32bit libraries present wether you intend to use them or not, which makes it cruft.
ABI issues, on unix newer libraries are generally a superset of previous functionality, where compatibility changes the libraries are typically given a new name making it possible to have both versions installed, or not at the user's choice. Windows hides the old versions, and makes it difficult and/or impossible to remove them - thus more cruft. Also some of the older libraries have been replaced with new versions because of security related design flaws.
"File and Registry Virtualization" is a lot more than symlinks, it is more of an overlay filesystem more similar to unionfs if you're familiar with that. With the virtualization setup, different applications and/or different users will see a different "view" of the filesystem, with links the system is consistent. On the other hand it is extremely rare that links would be used for this kind of compatibility kludge.
Linking a file to multiple locations is a different use case, and is also done for efficiency rather than having multiple copies of the same file.
A closer analogy on unix, would be trapping all attempts by certain processes to access system files such as/etc/passwd, and redirecting them to another file... The only time i've seen behaviour like this on a unix system, was on a system which had a complex rootkit installed which sought to modify various system files while making it appear as if they were unchanged.
Thats a flaw in the idea of a monoculture, true redundancy has different software implementing the same basic standards... Like how the Internet is built from routers made by different vendors, cisco, juniper, software based linux/bsd devices etc. When new DoS vulnerabilities are found in one vendors kit it doesn`t take down the whole internet, because other vendors are immune.
Network protocols which allow authentication using password hashes... Said hashes using a weak non salted algorithm (not that you need to bother cracking them due to the above)...
Excessively complex network services, want to enable file sharing? You've now opened up a service port which does a lot more than file sharing... This makes it much harder to quantify the risks involved of having a particular service open, and makes it much harder to write sensible firewall rules.
The many libraries which retain multiple different code paths to deal with different api versions (apps compiled with different versions of the sdk) ie the function name called from code remains the same but depending what api version you build against it might call a different backend implementation (also causes all manner of problems when you try to compile old code using a modern compiler), sure there is much less of this in the 64bit libs, but you also have all the 32bit compatibility libs present on your system and i'm not aware of any way to uninstall them - hence more cruft since you cant have a pure 64bit system.
Dirty workarounds, how about the various hacks implemented in vista/7 which provide for a shadow registry and even shadow filesystem (known as "File and Registry Virtualization") in an attempt to retain compatibility with applications which were designed to run as a privileged admin user? If that's not a dirty workaround i don't know what is...
Many people don't reverse park because that makes it more difficult to access the rear of the car, which is especially likely to be a problem when you visit say a supermarket.
In general in car parks i will look for double ranked spaces where both sides are empty, so i can drive in forwards and drive out the other side, but if someone subsequently parks very close behind it can make it difficult to put my shopping in. I also tend to park further away from the store where its quieter, because the inconvenience of a slightly longer walk is outweighed by less effort parking.
Or such an accident might have even be caused by a backup camera, since people will rely too much on the technology and forego the physical checks around the vehicle that they might otherwise have done.
On the other hand, kids of that age should not be out on the street on their own. They should be supervised by their parents or another responsible adult. While i certainly wouldn't want to run over a small child, and like you take precautions not to, it would still ultimately be negligence on the part of the parents if it happened.
The camera will only activate when you engage reverse gear, and there's no reason it can't have its own washer jet and/or wipers like the windscreen and headlights have. Some implementations i've seen also overlay guidelines on the image to show where your car is heading based on the current position of the steering wheel.
One of the biggest problems however, is the extremely poor rear visibility in some vehicles, combined with poor seating positions. In the car i have now, i have a pretty decent view behind, but there is a triangular blind spot of anything thats below the level of the trunk and fairly close to the car... Some cars i've driven lately have a much larger trunk and a much higher rear window so that your effectively looking up in the air.
Some moreso than others... There is still huge amounts of legacy cruft and dirty workarounds and huge insecurities due to bad design, just because they removed some doesn't mean its now "fixed".
Slashdot Mirror
That archive contains (very old) sourcecode for bash, you can download it from gnu.org too assuming they haven't removed such old versions. You won't be able to get it compiled and running on amigaos, no idea why someone would want to mirror old non amiga sourcecode on aminet either.
It seems like kingcon merges some of the functions of a terminal with that of the shell, while unix keeps them in separate apps. From its readme, the features it provides have long been provided by x11 terminals such as konsole or gnome terminal.
Also you have to ask yourself, after you've installed kingcon to replace the console device, and various other modifications... how much of the original amigaos are you actually using?
It's unlikely anyone would want an x11 window manager that explicitly emulates the amiga desktop (and what desktop would you emulate? most amiga users tended to modify the default workbench quite heavily)... Once you take off your rose tinted glasses you will realise that while it may have a few nice features, not to mention the fact your clearly familiar and comfortable with it, it is by no means the best interface out there and also has its fair share of deficiencies.
What you talked about was "stackable, push/pull windows" which several window managers can provide when configured accordingly. While i prefer this behaviour, i would not sacrifice virtual workspaces (no, "screens" provided by amigaos are not the same) among other things to use amigaos. The x11 model lets you pick and choose the best features.
X11 based systems have thousands of window managers, some of which behave exactly like you describe and there are so many possibilities you can find one which exactly suits your needs. /dev/shm on linux, or /tmp on solaris.
Dynamic ram drive? Try
RAD:? Modern computers don't need to reboot anywhere near as often as amigaos did, even windows is pretty stable these days so the utility of a reset resident ram drive is fairly limited. And then you have flash drives, and you can even get pcie cards with a load of ram on them for very fast storage.
King con is a shell handler (ie a terminal emulator), bash is a shell... King con is more like xterm and you can run all manner of shells in it (tho i dont believe bash was ever ported to amigaos due to the lack of fork()?)... The two are not directly comparable, and bash is far more powerful than the standard amigaos shell scripting language.
If you're running Linux, then there are several window managers which provide the behaviour you desire... I always used to run windowmaker with a focus follows mouse configuration, where only clicking on the titlebar would bring the window to the front.
The idea of buying an 800mhz (single core?) desktop in 2009 seems pretty insane... Sure there is a place for low power hardware, but only when it's cheap (eg look at raspberry pi)...
Having hardware that expensive ensures that no new users will ever take up the hobby, which means slow development, no economies of scale so the prices remain high etc...
Also if you read the article, they are doing the bare minimum to comply with the MPL... That is, they are releasing source code for any modified mozilla files, but won't be releasing any new files they create, and almost certainly won't be committing their work back to mozilla.
This means their port will always lag behind, you will have to wait for binaries to be provided, and won't be able to compile it yourself let alone make any changes or improvements.
Yes, the blatant attempts at profiteering were the final nail in the coffin for the Amiga...
Back when i had a (relatively highend) Amiga, in order to connect it to the internet i would have needed to buy a tcp stack, and then buy a browser, even things like ftp, irc and telnet clients had a price tag attached! Even MS and Apple don't charge extra for basic things like that.
And AmigaOS 4, not only expensive in its own right (even free niche os's have trouble gaining traction, what hope does an expensive one have?), but it's also tied to proprietary hardware that is insanely overpriced, under specced and not widely available.
Put it this way, lots of people are willing to try AROS, its a free download and will run happily on hardware that the vast majority of people already have at their disposal. It will run happily on old hardware which you may have laying around, can boot as a livecd so as not to affect your existing installation and can run inside of common virtualization software. You've nothing to lose, and anyone can try it.
Contrast that with AmigaOS 4, you have to pay several hundred EUR (last i checked) for the hardware, plus an additional 100+ for the copy of AmigaOS, and then if you don't like the OS or find that it doesn't suit your needs all you have to show for it is a very slow linux box.
Safer purely due to security through obscurity... AmigaOS has virtually no security features, it doesn't even have a concept of users or of protected address space so a vulnerability in any userland application is effectively a kernel level exploit.
Latency of 100ms is terrible to anything thats not on a different continent.
Currently i have both DSL and Cable at home, and latency to my server (hosted in a DC about 20 miles away, but hosted by a completely different isp to either of the dsl/cable providers) is about 12ms on dsl and 40ms on cable... It's also the peak usage time for home broadband connections right now, and my latency on cable is considerably better off-peak.
This is also tested from my laptop, which is connected via wifi.
Traceroute shows 13 hops either way (first one being my router), although on the dsl it enters the target isp at hop 10 vs 8 for the cable.
You can have multiple versions coexist...
Instead of installing it, you just untar it into a dir... And when you start it, you use -profilemanager so that each instance uses its own profile.
If you intentionally have multiple versions, i assume your using it for testing so there's little reason to upgrade any particular instance, only install newer versions as necessary.
If a proprietary platform is no longer supported, there is little point expending significant effort to port software to it if the os vendor is never intending to update it.
While OSX/PPC and win2k are no longer supported by their vendors, the hardware capable of running these are capable of running linux, and linux/ppc has an updated version of firefox available for it.
The source for this software is available, and there are people who port modern browsers to older proprietary platforms, but its more useful to have a modern os and browser rather than just a modern browser.
You can still run firefox 10 on ppc linux... osx for ppc is deprecated, 2 versions behind the current release.
Because it's out of support, it will never get patched against any new security holes which are discovered...
Because it's closed source there is little scope for patching it yourself, or having a third party provide patches...
Because the system isn't very modular, it's also harder to strip it down and minimise the possible exploitation vectors...
Keeping such a system on the internet is irresponsible, wether it works or not. Not only does the owner of the system risk having everything they do on the system compromised, there is also the risk that a compromise of this system could lead to compromise of other systems (eg this box is probably behind his nat gateway, and from here other systems could be scanned, there might even be common passwords shared across systems). Then there's the rest of the internet to think about, if this system was compromised it could be used to spread spam or attack others.
The system could be upgraded to XP, at least for the next couple of years...
There are also plenty of currently supported linux distributions designed specifically for lowend hardware (some are designed for considerably older hardware than this).
Doesn't matter, the bitcoins are tied to the private key, not any individual... The private key could change hands.
The hashes should be salted, but Im not sure what to make of the accusation that the network protocols send hashes for authentication. What would you rather have them send? The plaintext password?
The plaintext password, when sent over an appropriately encrypted channel would actually be a much better option for a number of reasons.
By allowing the hash to be used, it effectively becomes the plaintext as you can use it for authentication, the actual plaintext becomes irrelevant since you never actually need it. Google for "pass the hash".
If you acquire the hash database, then you now have _ALL_ the (plaintext equivalent) hashes ready for immediate use... Also in such a scheme every client has to implement the same hashing algorithm. This i consider a design flaw, since you are now stuck with a given hashing algorithm unless you can update ALL your clients, and this is probably the biggest reason why they still use a weak non salted algorithm (aside from the lack of salts, the algorithm is MD4 based and considerably weaker than modern algorithms used on unix systems).
If you send the plaintext, then only the server needs to know the hashing algorithm and thus can change it without breaking compatibility as new stronger algorithms become available. Although you could capture the plaintext if you controlled client or server at the time of authentication, you could still do this by capturing plaintext-equivalent hashes. There are many other ways to capture hashes, such as backups, not to mention multiple use of the same password on different systems which yields the same hash due to the lack of salting.
AD login uses a combination of Kerberos and NTLM... Kerberos allows the use of tokens for single sign on, and these tokens become invalid once a user logs out... Windows also however stores the hashes when your logged in (eg on a domain member system), so if you capture those instead then they will remain valid until the user changes their password. You can authenticate using the hash, and acquire a new kerberos token whenever you want. By contrast in a unix environment, you would typically log in using your plaintext password to acquire a kerberos token which you can use for further authentication.
The use of links in your home directory is completely separate from file and registry virtualization, the latter is to allow poorly written software which expects to write to system locations to think it has succeeded, whereas the former is just linking previous paths. Although it brings up other questions.. /export/home/blah instead of /home/blah for their homedir.
Why did they choose to move the location of user homedirs? There was nothing inherently bad with the previous location...
And why is software hard coded like that? You don't see unix software failing because the user has
You mention or 32/64 nodes also reminds me, 32bit software seems to be installed by default in a different location to 64bit, this also seems strange and messy.
As for removing compatibility cruft...
Rosetta was always an optional install on OSX, you could choose not to install it and indeed OSX 10.7 no longer includes it at all.
Similarly, 32bit libraries on 64bit linux distributions are referred to as multilib, and are optional... If you don't intend to run any 32bit applications then you can remove them (or simply choose never to have installed them at all).
I'm not saying that sets of compatibility libs shouldn't be available, i'm saying they should be optional and easily removed for those of us who don't need them.
Sure this *would* break old software, but some of us have no need to run old software, especially on servers which typically only serve a single purpose. Also since most linux software comes with source code, the vast majority of it can (and has been) be recompiled to work on a 64bit system.
What software did you use on ubuntu 7.10 which no longer works on a modern 64bit linux distro?
I still use "x
You have to acquire a copy of the private key, and then you can make your own cryptographic signatures at will... But you do absolutely require a copy of the key. You can also verify with a very high degree of certainty that a cryptographic signature was signed by a particular private key. Thus the only practical avenue for nefarious activity, is to acquire knowledge of the private key...
A signature on the other hand is totally arbitrary, anyone can make a random mark on a piece of paper and call it a signature... Even *if* a comparison is made to one stored on file, it has to be a fuzzy match because regardless of how much you try it would never be quite the same twice.
I have been asked to "sign" all manner of forms recently, and they all look wildly different...
Similarly, if someone presents a piece of paper and claims you "signed" it, whats to stop you simply denying that it was you? Unless they have video footage of you actually doing it, it pretty much boils down to your word against theirs.
And how exactly is this different from any other investment opportunity or currency?
A volatile investment can mean big rewards or big losses, and smaller investments are more likely to be volatile due to the ability of a smaller group to influence the market price more easily.
Investments can crash and burn, currencies have also crashed and burned in the past... Investing in anything is a gamble, and with higher risk comes the potential of bigger reward. Or if you're a bank, zero risk because the taxpayer will bail you out if the investment doesn't pay off.
ZWD doesn't fluctuate, it's been on a pretty consistent downward plummet for years.
Well, that's a rather inefficient use...
There are various services you can buy directly with bitcoins, like hosted servers, domain names etc... There are even goods you can buy online with bitcoins and have physically shipped to you.
Bitcoin is also very useful as a way of paying people in foreign countries, avoiding the high fees imposed by banks and services such as paypal.
And somehow signatures and rubber stamps are more viable than a cryptographic signature?
Anyone can make a rubber stamp...
Anyone can "sign" a piece of paper...
It's considerably harder to fake a cryptographic signature.
You've not addressed the issues of the hashing algorithms, does this mean you accept these design flaws?
SSH can indeed be used for many things, however... What ssh really does is give you interactive shell access, the fact that you can do additional things with it is down to the inherent flexibility of being able to pipe arbitrary data over a TTY... It's more analogous to remote desktop, in that you'd only provide access to administrative users or those who you intended to have interactive access.
The protocol is also pretty clearly demarcated, in that none of this functionality is available until you have completed the authentication stage, unlike many MS protocols where many functions are available with/without authentication, depending on configuration and some provide different functionality depending on wether you are authenticated or not..
32/64 issues - on linux you can choose between a 32, hybrid 32/64 or pure 64bit system as your needs dictate, with windows its necessary to have the 32bit libraries present wether you intend to use them or not, which makes it cruft.
ABI issues, on unix newer libraries are generally a superset of previous functionality, where compatibility changes the libraries are typically given a new name making it possible to have both versions installed, or not at the user's choice. Windows hides the old versions, and makes it difficult and/or impossible to remove them - thus more cruft. Also some of the older libraries have been replaced with new versions because of security related design flaws.
"File and Registry Virtualization" is a lot more than symlinks, it is more of an overlay filesystem more similar to unionfs if you're familiar with that.
With the virtualization setup, different applications and/or different users will see a different "view" of the filesystem, with links the system is consistent. On the other hand it is extremely rare that links would be used for this kind of compatibility kludge.
Linking a file to multiple locations is a different use case, and is also done for efficiency rather than having multiple copies of the same file.
A closer analogy on unix, would be trapping all attempts by certain processes to access system files such as /etc/passwd, and redirecting them to another file... The only time i've seen behaviour like this on a unix system, was on a system which had a complex rootkit installed which sought to modify various system files while making it appear as if they were unchanged.
Thats a flaw in the idea of a monoculture, true redundancy has different software implementing the same basic standards...
Like how the Internet is built from routers made by different vendors, cisco, juniper, software based linux/bsd devices etc. When new DoS vulnerabilities are found in one vendors kit it doesn`t take down the whole internet, because other vendors are immune.
Network protocols which allow authentication using password hashes...
Said hashes using a weak non salted algorithm (not that you need to bother cracking them due to the above)...
Excessively complex network services, want to enable file sharing? You've now opened up a service port which does a lot more than file sharing... This makes it much harder to quantify the risks involved of having a particular service open, and makes it much harder to write sensible firewall rules.
The many libraries which retain multiple different code paths to deal with different api versions (apps compiled with different versions of the sdk) ie the function name called from code remains the same but depending what api version you build against it might call a different backend implementation (also causes all manner of problems when you try to compile old code using a modern compiler), sure there is much less of this in the 64bit libs, but you also have all the 32bit compatibility libs present on your system and i'm not aware of any way to uninstall them - hence more cruft since you cant have a pure 64bit system.
Dirty workarounds, how about the various hacks implemented in vista/7 which provide for a shadow registry and even shadow filesystem (known as "File and Registry Virtualization") in an attempt to retain compatibility with applications which were designed to run as a privileged admin user? If that's not a dirty workaround i don't know what is...
Many people don't reverse park because that makes it more difficult to access the rear of the car, which is especially likely to be a problem when you visit say a supermarket.
In general in car parks i will look for double ranked spaces where both sides are empty, so i can drive in forwards and drive out the other side, but if someone subsequently parks very close behind it can make it difficult to put my shopping in. I also tend to park further away from the store where its quieter, because the inconvenience of a slightly longer walk is outweighed by less effort parking.
Or such an accident might have even be caused by a backup camera, since people will rely too much on the technology and forego the physical checks around the vehicle that they might otherwise have done.
On the other hand, kids of that age should not be out on the street on their own. They should be supervised by their parents or another responsible adult. While i certainly wouldn't want to run over a small child, and like you take precautions not to, it would still ultimately be negligence on the part of the parents if it happened.
The camera will only activate when you engage reverse gear, and there's no reason it can't have its own washer jet and/or wipers like the windscreen and headlights have. Some implementations i've seen also overlay guidelines on the image to show where your car is heading based on the current position of the steering wheel.
One of the biggest problems however, is the extremely poor rear visibility in some vehicles, combined with poor seating positions. In the car i have now, i have a pretty decent view behind, but there is a triangular blind spot of anything thats below the level of the trunk and fairly close to the car... Some cars i've driven lately have a much larger trunk and a much higher rear window so that your effectively looking up in the air.
Some moreso than others...
There is still huge amounts of legacy cruft and dirty workarounds and huge insecurities due to bad design, just because they removed some doesn't mean its now "fixed".