There is no way that the code that decides how to display the icon for the attachement should be seperated from the code that decides how to "execute" it and thus will display different things.
The code _should_ be separated. Attachment type is identified by its MIME Content-Type, that's enough.
Not a bug, but a nice feature, would be to have any executable attachment pop up a dialog
Recently, we had a problem with connecting from an external private NAT'ted LAN to company private network, using MS VPN.
Both the client and VPN server are in private address space. VPN server is exposed to internet with dedicated public IP address - through a Linux NAT box.
So traffic goes through NAT router, internet, and another NAT router.
Connection gets established, but any further communication is impossible - because client local network is 192.168.1/24 (same as remote), and all traffic destined to remote network gets "intercepted" by routing process, and directed to LAN:/
Actually I don't know if it's a flaw in MS VPN system or network design problem. But having thousands of LANs with identcal IP addressing may be sometimes confusing - and such problems may occure more and more often. So "random" address classes could help, and RFC is right (again)
Intel 486 running at 100 Mhz. Just think how long it would take to compile the kernel on that system.
Recently I "experienced" compiling 2.2.19 kernel on Intel 486 DX 100 with 16MB RAM. It takes about 4.5 hours - that's about 700 times slower.
Slashdot Mirror
True, true...
Let's hope that any person actually analysing the devx.com hit statistics will detect such a peak and properly recognize it as a Web flamebait.
The code _should_ be separated.
Attachment type is identified by its MIME Content-Type, that's enough.
Come on, the dialog would be buggy too.
Maybe you're right.
:/
Recently, we had a problem with connecting from an external private NAT'ted LAN to company private network, using MS VPN.
Both the client and VPN server are in private address space.
VPN server is exposed to internet with dedicated public IP address - through a Linux NAT box.
So traffic goes through NAT router, internet, and another NAT router.
Connection gets established, but any further communication is impossible - because client local network is 192.168.1/24 (same as remote), and all traffic destined to remote network gets "intercepted" by routing process, and directed to LAN
Actually I don't know if it's a flaw in MS VPN system or network design problem. But having thousands of LANs with identcal IP addressing may be sometimes confusing - and such problems may occure more and more often. So "random" address classes could help, and RFC is right (again)
MUD is NOT Role Playing (IMO)
It lacks serious player interaction.
Intel 486 running at 100 Mhz. Just think how long it would take to compile the kernel on that system.
Recently I "experienced" compiling 2.2.19 kernel on Intel 486 DX 100 with 16MB RAM. It takes about 4.5 hours - that's about 700 times slower.