I have a Thinkpad T500, with the "switchable" ATI/Intel graphics. Under Vista, it's fine, using either ATI or Intel card. I get about 5 hours runtime off the 9-cell battery pack.
Under Linux, X uses the Intel card by default (presumably because of lower PCI bus ID), but seemingly keeps the ATI card clocking at full speed. Not only does it get much hotter than when running Vista, but the battery life drops to about 2.5 hours or less.
My solution - go into the BIOS and switch off the "switchable" graphics, just using the Intel card under Linux. Battery life soars to about the same 5 hours as when running Vista, and temperate drops back substantially too. I don't really do anything presently that warrants the high performance ATI display.
It appears that X just isn't ready for switchable graphics (or most modern ATI cards, for that matter).
Actually, all half-duplex ethernet, regardless of physical media, even up to 100 Mbps (Gig-E doesn't support half-duplex), uses CSMA/CD
And any system that uses a "contention" based method to determine who can transmit, will be prone to jitter, due to the randomness of when a device wants to transmit. This includes 802.11, which uses CSMA/CA (collision advoidance, not collision detect like ethernet).
Most wireless technology that has to guarantee specific latency to multiple clients uses some sort of static TDMA or TDD
WiMax / 802.16e does support QOS (and dynamic TDMA), including realtime polling service for VoIP applications. Perhaps the telco was just using Best Effort configuration.
I used to deploy a lot outdoor wireless gear from Proxim (and previously Orinoco). Most of their gear either used a proprietary MAC in the same band as 802.11 (ie, 2.4 GHz ISM band), or some completely proprietary concoction, such as some of their circular-polarised gear in the 5 GHz ISM band.
Orinoco were one of the first companies to solve 802.11's "hidden node" problem, where peers could be NLOS (and thus unable to hear when other TX'ed), by using a polling system, controlled by a master node that could see all peers. A standard 802.11 would have performed very badly in such a scenario, due to frequent collisions. This proprietary system was essentially TDMA, and ensured relatively consistent latency (apart from dropped frames due to RF noise).
Proxim Tsunami MP gear used a strict TDMA system to ensure that peers could only TX when they were given permission to. The base stations had a 60 degree beam width, and to get 360 degree coverage, you simply put six of them together in a pod, on alternate channels. They used GPS time signals to sync all units in the pod, ensuring that all of them had synchronised TX slots - they'd all transmit at the exactly the same time, then go into RX mode at the same time.
They also had a similar system called a QuickBridge, which could run at up to 54 Mbps aggregate bandwidth - and unlike 802.11g, this did actually have a throughput of 54 Mbps, not 20 Mbps (which is the best I ever saw from 802.1g). It used a TDD system, as it was only two units in a configuration. Using some simple traffic shaping, we successfully blasted a 2 meg voice circuit across it, had terminal server traffic running (even fancy screensavers within the terminal session to stress it out a bit), while copying large files in BOTH directions across it. All performed perfectly, and voice was crystal clear. Ok, the traffic shaping was partially responsible, since it policed bandwidth and prioritised the voip - but the main thing to take note of, is that TDD/TDMA systems can have heavy traffic in both directions without causing massive amounts of retransmits.
1. Cisco routers might not be as fast at moving ip6 as ip4, but right now ip4 is a much bigger market. Once ip6 starts to take off, I think you'll see considerable investment poured into improving the performance of ip6. Part of the problem is that ip6 allows for header extensions, which makes it harder to design ASICs that can do wire-speed routing. If you designed an ip6 router that didn't support header extensions, you could probably make it move packets as fast as an ip4 router.
2. I think the expectations of ip6 addresses is that they'll be used further afield than just planet Earth, so expressing the number of addresses per square metre of Earth's surface is perhaps not a valid argument (although I'm not sure how TCP is going to cope with 30 minute RTT to some probe on its way Mars).
3. Last time I checked, ethernet MAC addresses were 48 bits, not 56 bits.
4. Don't forget that some things, like IPSEC, have been made a standard requirement in ip6. Previously with ip4, you had to use ESP (about 36 bytes packet overhead) inside an IP packet. And if you were using NAT-T, then you can also throw in a bunch of extra overhead for your NAT-T UDP encapsulation. Ip6 would solve that (supposedly).
Ok, so let's say a document containing copyrighted information on a proprietary protocol ends up on the intertubes. Yes, it's copyrighted and you can't legally reproduce that code (without licensing the code). But Samba, for example, are _already_ reverse engineering copyrighted code.
Could you say for certain that Samba didn't have a sneaky peak at this copyrighted document floating around the net?
If such a term was in the licence, it would open up a legal can of worms for projects such as Samba, Scalix etc, that are already doing quite a good job of reverse engineering Microsoft's closed protocols.
What if some of these specifications were leaked into the public domain by a company that bought a licence - how could you then prove or disprove whether Samba had reverse engineered protocols under their own steam, or seen some of the leaked specifications, mysteriously fast tracking certain features they'd been slaving over?
H20 is already the result of combusting hydrogen and oxygen. Energy is given off during the combustion, and the new molecule forms at a more stable state. If you liken it to burning wood, water is essentially the "ash" left after the fire has gone out. Do you think ash has a lot of energy in it?
To extract H2 from H20 (using electrolysis) takes energy - more energy than you'll reap when you burn the H2 again (unless you're using "free" energy like solar power to do the cracking).
One of the major hurdles of hydrogen fuel is that there is no cost-effective way of producing it yet, which is no surprise, since it is very rare to find it on Earth in elemental form. Sure, hydrogen is the most abundant element in the universe, but Earth's atmosphere is only about 1ppm hydrogen.
So, by putting one of these heat-to-electricity chips on the motherboard next to the Pentium 4, surely the net energy consumption of such a system would be near zero?
I run a home mail server, and have pretty much always used Spamhaus sbl+xbl. In addition to that I run Spamassassin. Lately I've noticed more and more spam of the image-variety, coming from dynamic IP addresses for cable and DSL. Spamassassin is ineffective against this type of spam, so I decided to try dul.dnsbl.sorbs.net. That same day I enabled it, my mail server rejected 1200 inbound connection attempts as a result. That's a lot less work for Spamassassin to do!
There is no legitimate reason for a dynamic IP address to connect directly to my mail server, unless it is somebody else who runs a home mail server on a cable/DSL IP. In the that case, if they're smart enough to run their own home mail server, they should be smart enough to configure smtp transport maps to direct mail to my domain via their ISP's mail server. I've already had to do this myself, as I discovered that certain.de domains no longer accept mail from IP addresses listed as "dynamic" (I'm on a static IP, but it's from a dynamic IP range).
If all ISPs followed suit and blocked incoming SMTP from dynamic IP addresses (other than their own), spam would be dramatically reduced. I'm not talking about open relays - I'm basically saying that ISP mail servers should only accept mail from static IP, genuine ISP or corporate mail servers, even when the target recipient is a domain they host. This would pretty much make bot nets useless to the spammers, and force them to revert to running their own mail servers, or trying to compromise other legitimate servers.
It wouldn't eliminate the problem, but would severely reduce the number places we have to fight spam.
The fastest we've ever gotten a machine to spit data out the line was with a 10 gig ethernet card, with a TOE in it, and that rate was 1.2 gigabit/second. The bus could handle 7.6 gigabit max, but we got nowhere near that due to the framing involved. We were just piping/dev/random over a netcat connection and into/dev/null, too. Couldn't figure out how to do anything faster. Any ideas? Cause we were stumped.
It's possible you only had enough entropy to generate 1.2Gbps of data from/dev/random. You could try sourcing data from/dev/zero. Although it will be a very repetitive pattern of bits, I don't think that should affect the outcome. Or just source data from a bigass file, but this will be tainted by the speed of your hard disks.
Also, think about whether you're interested in measuring TCP throughput, UDP throughput (which I'd expect to be a litte higher), or raw Ethernet throughput (which will be as close to the theoretical limit of the card as possible).
Running something like SCSI over TCP/IP does seem like quite a lot of overhead, but when you look closer, TCP/IP is handling a lot of things that AoE will have to implement at the application layer - things like reliable delivery, and ensuring correct sequencing of packets.
Some people will wonder why we need the ability to route such a protocol (like yeah, as if we're going to run iSCSI over a WAN link). How about inter-VLAN routing though? It's probably in the same building, and on a gigabit LAN, but it's a different IP subnet, so it needs to be routed.... ok, you're gonna need a kickass L3 switch to avoid being a bottleneck, but...
Of course, implementing iSCSI in software and using a standard NIC & driver will clearly be a bit sluggish. Use a NIC with a TCP offload engine and things get a bit faster. Use an actual iSCSI NIC and you're then doing about as much in hardware as you can.
Then there's iSCSI over IPv6, which is supposedly faster to process the IP header of, than IPv4.
So yes, AoE certainly would be a leaner protocol than iSCSI, but by the time you add checksums, reliable delivery, sequencing, and routing (with only a MAC address??), you've probably reinvented TCP/IP.
So who's going to be the first to come up with AoI (ATA over IPX), AoD (ATA over DECnet), and AoA (ATA over Appletalk)?
We get PMs when SNMP reports high utilization on a switch. From there, we open the switch's graphs and determine who is doing what. If a user's port is screaming, we disconnect them and go over to see what's up.
In a graphic design house, or anywhere that routinely works on large files, that's going to inconvenience and maybe even infuriate a lot of people. A large file copy is going to make a port "scream", that is, up until you disconnect it. Do you strap on a bulletproof vest and riot helmet before confronting the user of that port?
You should possibly consider taking a look at Cisco NAC.
Or they password the ZIP and include the pass in the email. If you allow it, it will be exploited.
So you quarantine anything that is not scannable. I'd rather do that, than make email virtually useless by blocking all attachments outright. Unless your job title is BOFH, that's just gonna piss people off, and some of those people may be the ones who write your paychecks.
I did some work for a company a while back that blocked everything not in the US. Users would get blocked from everything that didn't end in a.com/net/org.
The domain TLD has nothing to do with the geographic location of a server. It might have been a rough guide, once upon a time. Anyway, I was thinking more along the lines of whitelisting sites you trust, regardless whether they're US, German, Chinese... sites that your users have a legitimate reason to connect to.
ICMP entails quite a bit more than just ping. If the PC is unable to receive "network/host/protocol/port unreachable", they'll just sit there stupidly until the connection times out. "TTL expired" and "needs fragment" are also fairly important.
I think that if you run the protocols on nonstandard ports and close those on your external firewall, you should be OK. Admins need a remote desktop app to troubleshoot. Nothing is more useless than having a user describe a problem. If they can show you the prob, it can be cleared quickly.
If you run services on nonstandard ports, you're only going to stop the dumbest of hackers. Anyone with a clue will portscan your box, to see what's open. From there, it's relatively easy to identify the protocol bound to a particular port. Security through obscurity is not really security. As for blocking ports on a firewall, of course, that is standard practice. But often the threat these days is within an organisation. Most LAN's have very little network security, once inside the perimeter. Crunchy on the outside, soft and chewy on the inside.
I agree however, it's useful to be able to take remote control of a user's desktop. Citrix has such a feature built in, called "shadowing a session". Of course, that's in a Citrix environment, not an XP desktop environment.
And no one should be getting ZIPs, RARs, EXEs, and the like. The smart ones begin renaming the extension.
Even open source mail scanning gateways such as Amavisd-new support banned filename extensions. Couple that with ClamAV, and scan all attachments not yet banned, including recursive scanning of compressed archives, and you get quite a bit of security for very little cost. I've seen this solution fare better than commercial ones, which failed because the virus was a ZIP inside a ZIP.
Images can link to external servers and be used to verify good IP and e-mail addresses.
True... which is why most email clients these days do not display images (and thus invoke the HTTP connection to retrieve that invisible 1px image) by default. This kind of thing can also be prevented by having a web proxy that only allows access to whitelisted sites.
Still, you have to give users read/write to their group folders.
Yes you do, there is no way around that. All you can do is give people access to the minimum amount possible. Beyond that, backups are really your only safety net.
That install would come with a VMWare player image of the user's standard install with full admin rights to the user. The VMWare image would be for special dev tools or just for those times when a user "has to have admin".
I can't see how making the user suffer the performance overhead of VMware is a security measure. If this is an attempt to provide a quick way to re-image a workstation after a user has bollocksed it up, why not just use a hard drive imaging tool?
The desktop should include a firewall. Only 80 and 443 should be open for outgoing.
So, no SMB/CIFS/NFS to allow them to actually work with their data on the SAN/NAS? No DNS so they can actually resolve the address of the SAN? No ICMP so that the host actually has a clue when it tries to connect to something that is unreachable?
Incoming should have RDP or VNC open for admins to get in.
Don't forget hackers...
On the e-mail side. Attachments should not be allowed.
That would destroy the reason most people use email these days. Can you imagine how effectively a salesperson or manager is going to be able to do their job, if they can't easily send markting material such as PDF's or PPT's to customers?
HTML e-mail would be allowed, but images would be stripped.
Why? What makes an image any more of a threat to security than a rich-text email (especially when read with certain well known mail clients... *cough* Outlook *cough*) ?
Have good backups and at least try to keep a virus on the user's desktop from raping your SAN/NAS.
That usually comes down to implementing sensible file/directory permissions, and the challenging task of educating users to actually save stuff in the right place.
I could make the most secure airline in the world. But no one would ever want to fly completely naked and cuffed to their seats.
I don't see how your sexual kinks play a role in this discussion.
Why would terrorists or criminals be compelled to obey this particular law, while they're breaking others? This is just plain stupid. Even if all the businesses caved in and submitted their keys, does the UK government really they're going to get emails along the lines of:
"Hi, I represent the West London cell of Al Qaeda. In accordance with the new encryption laws, please find attached all our private keys. Thank you, and have a nice day!"
Unless you propose some method of tracking (relatively) nearby aircraft, so as to aim a reasonably directional antenna at them, you're going to have to use a horribly inefficient omnidirectional antenna.
Also, bear in mind that once outside of ATC zones (ie, in the middle of oceans), about the only long distance communication that works is HF SSB (and in theory, lower frequencies too). The bandwidth of these HF channels used by aircraft is less than the VHF they use for communication when over land, and you'd need to allocate big chunks of international spectrum to get the required bandwidth for implementing what would essentially a be mesh network.
Replacement of the existing HF voice communication system with satellites are underway, so I guess they figured that's the optimal way.
If Connexion used lower altitude, polar-orbiting satellites, this would obviously reduce latency, but would require tracking of those satellites, and some kind of handover system whenever a satellite went below the horizon.
It might have XGL eye candy, but it's running an outdated version of GNOME. Is SUSE still favouring their KDE heritage? It was Novell that sort of pushed GNOME upon SUSE when they bought them.
Debian GNU/kFreeBSD is still in its infancy, and doesn't get a lot of attention (yet), so it's understandably not as advanced as Debian GNU/Linux. I didn't say I preferred Debian GNU/kFreeBSD over FreeBSD, and at this point in time, if I was actually intending to run a FreeBSD kernel, I'd run FreeBSD.
The point I was trying to get across is that Debian GNU/Linux is a reminder that it's the GNU OS, with a Linux kernel. Likewise Debian GNU/kFreeBSD is the GNU OS, with a FreeBSD kernel. Rather than build an entire OS (-distribution) exclusively around one kernel, it's evidence that the kernel can simply be one single component of that OS (in this case, provided that the kernel is UNIX-like).
I think this is important because, what if Linux just so happens to not be the greatest kernel ever? Or, what if HURD/L4/whatever just so happens to one day be useable?
Wouldn't it be a shame to throw away all that hard work invested in Debian's package repositories?
This is why projects like Debian's kFreeBSD are important - so that if the Linux kernel does run amok completely (or at least degenerate significantly), we can continue using various Linux ~distributions~ - just with a different engine room.
When most people think "Linux", they're usually thinking of all the commonly associated open source software bundled as a distribution. If you can swap out the kernel but keep the same GUI, the same traditional *nix shells and CLI tools they're used to - will people really care that much?
OTOH, maybe it's time Linux looked at going microkernel. Maintaining a monolithic kernel that just keeps getting bigger and bigger can't be an easy task. At least a microkernel would allow a degree of separation between the kernel proper, and the various hardware drivers, networking stacks, filesystems etc.
I probably should have read TFA. I got the impression from the Slashdot summary that the RIAA had detected filesharing traffic coming from universities' internet gateways.
That said, I really have to question how much jurisdiction the RIAA should be allowed to have on a private network. Surely it's up the universities themselves to decide what traffic they do/don't allow within the confines of their own LAN.
Slashdot Mirror
Okay, so the obvious first question is - how do you get on the trams? Do they stop?
No, you must board the tram from a moving bus, which docks with said moving tram.
How do you board the moving bus? There is a supply of skateboards at each "bus stop" (which technically becomes a misnomer).
Not only that, but "bacterias" is an interesting new take on a word that is already plural...
One bacterium, many bacteria.
Is it time to start teaching Latin again in schools?
I have a Thinkpad T500, with the "switchable" ATI/Intel graphics. Under Vista, it's fine, using either ATI or Intel card. I get about 5 hours runtime off the 9-cell battery pack.
Under Linux, X uses the Intel card by default (presumably because of lower PCI bus ID), but seemingly keeps the ATI card clocking at full speed. Not only does it get much hotter than when running Vista, but the battery life drops to about 2.5 hours or less.
My solution - go into the BIOS and switch off the "switchable" graphics, just using the Intel card under Linux. Battery life soars to about the same 5 hours as when running Vista, and temperate drops back substantially too. I don't really do anything presently that warrants the high performance ATI display.
It appears that X just isn't ready for switchable graphics (or most modern ATI cards, for that matter).
When the network is broken, and you're paying a CCIE $200/hour to fix it, are you really going to stand around and ask them how their weekend was?
Actually, all half-duplex ethernet, regardless of physical media, even up to 100 Mbps (Gig-E doesn't support half-duplex), uses CSMA/CD
And any system that uses a "contention" based method to determine who can transmit, will be prone to jitter, due to the randomness of when a device wants to transmit. This includes 802.11, which uses CSMA/CA (collision advoidance, not collision detect like ethernet).
Most wireless technology that has to guarantee specific latency to multiple clients uses some sort of static TDMA or TDD
WiMax / 802.16e does support QOS (and dynamic TDMA), including realtime polling service for VoIP applications. Perhaps the telco was just using Best Effort configuration.
I used to deploy a lot outdoor wireless gear from Proxim (and previously Orinoco). Most of their gear either used a proprietary MAC in the same band as 802.11 (ie, 2.4 GHz ISM band), or some completely proprietary concoction, such as some of their circular-polarised gear in the 5 GHz ISM band.
Orinoco were one of the first companies to solve 802.11's "hidden node" problem, where peers could be NLOS (and thus unable to hear when other TX'ed), by using a polling system, controlled by a master node that could see all peers. A standard 802.11 would have performed very badly in such a scenario, due to frequent collisions. This proprietary system was essentially TDMA, and ensured relatively consistent latency (apart from dropped frames due to RF noise).
Proxim Tsunami MP gear used a strict TDMA system to ensure that peers could only TX when they were given permission to. The base stations had a 60 degree beam width, and to get 360 degree coverage, you simply put six of them together in a pod, on alternate channels. They used GPS time signals to sync all units in the pod, ensuring that all of them had synchronised TX slots - they'd all transmit at the exactly the same time, then go into RX mode at the same time.
They also had a similar system called a QuickBridge, which could run at up to 54 Mbps aggregate bandwidth - and unlike 802.11g, this did actually have a throughput of 54 Mbps, not 20 Mbps (which is the best I ever saw from 802.1g). It used a TDD system, as it was only two units in a configuration. Using some simple traffic shaping, we successfully blasted a 2 meg voice circuit across it, had terminal server traffic running (even fancy screensavers within the terminal session to stress it out a bit), while copying large files in BOTH directions across it. All performed perfectly, and voice was crystal clear. Ok, the traffic shaping was partially responsible, since it policed bandwidth and prioritised the voip - but the main thing to take note of, is that TDD/TDMA systems can have heavy traffic in both directions without causing massive amounts of retransmits.
1. Cisco routers might not be as fast at moving ip6 as ip4, but right now ip4 is a much bigger market. Once ip6 starts to take off, I think you'll see considerable investment poured into improving the performance of ip6. Part of the problem is that ip6 allows for header extensions, which makes it harder to design ASICs that can do wire-speed routing. If you designed an ip6 router that didn't support header extensions, you could probably make it move packets as fast as an ip4 router.
2. I think the expectations of ip6 addresses is that they'll be used further afield than just planet Earth, so expressing the number of addresses per square metre of Earth's surface is perhaps not a valid argument (although I'm not sure how TCP is going to cope with 30 minute RTT to some probe on its way Mars).
3. Last time I checked, ethernet MAC addresses were 48 bits, not 56 bits.
4. Don't forget that some things, like IPSEC, have been made a standard requirement in ip6. Previously with ip4, you had to use ESP (about 36 bytes packet overhead) inside an IP packet. And if you were using NAT-T, then you can also throw in a bunch of extra overhead for your NAT-T UDP encapsulation. Ip6 would solve that (supposedly).
...DPD stands for Dead Peer Detection.
Coincidence? I think not...
Ok, so let's say a document containing copyrighted information on a proprietary protocol ends up on the intertubes. Yes, it's copyrighted and you can't legally reproduce that code (without licensing the code). But Samba, for example, are _already_ reverse engineering copyrighted code.
Could you say for certain that Samba didn't have a sneaky peak at this copyrighted document floating around the net?
If such a term was in the licence, it would open up a legal can of worms for projects such as Samba, Scalix etc, that are already doing quite a good job of reverse engineering Microsoft's closed protocols.
What if some of these specifications were leaked into the public domain by a company that bought a licence - how could you then prove or disprove whether Samba had reverse engineered protocols under their own steam, or seen some of the leaked specifications, mysteriously fast tracking certain features they'd been slaving over?
It could be SCO vs Linux all over again.
H20 is already the result of combusting hydrogen and oxygen. Energy is given off during the combustion, and the new molecule forms at a more stable state. If you liken it to burning wood, water is essentially the "ash" left after the fire has gone out. Do you think ash has a lot of energy in it?
To extract H2 from H20 (using electrolysis) takes energy - more energy than you'll reap when you burn the H2 again (unless you're using "free" energy like solar power to do the cracking).
One of the major hurdles of hydrogen fuel is that there is no cost-effective way of producing it yet, which is no surprise, since it is very rare to find it on Earth in elemental form. Sure, hydrogen is the most abundant element in the universe, but Earth's atmosphere is only about 1ppm hydrogen.
So, by putting one of these heat-to-electricity chips on the motherboard next to the Pentium 4, surely the net energy consumption of such a system would be near zero?
I run a home mail server, and have pretty much always used Spamhaus sbl+xbl. In addition to that I run Spamassassin. Lately I've noticed more and more spam of the image-variety, coming from dynamic IP addresses for cable and DSL. Spamassassin is ineffective against this type of spam, so I decided to try dul.dnsbl.sorbs.net. That same day I enabled it, my mail server rejected 1200 inbound connection attempts as a result. That's a lot less work for Spamassassin to do!
.de domains no longer accept mail from IP addresses listed as "dynamic" (I'm on a static IP, but it's from a dynamic IP range).
There is no legitimate reason for a dynamic IP address to connect directly to my mail server, unless it is somebody else who runs a home mail server on a cable/DSL IP. In the that case, if they're smart enough to run their own home mail server, they should be smart enough to configure smtp transport maps to direct mail to my domain via their ISP's mail server. I've already had to do this myself, as I discovered that certain
If all ISPs followed suit and blocked incoming SMTP from dynamic IP addresses (other than their own), spam would be dramatically reduced. I'm not talking about open relays - I'm basically saying that ISP mail servers should only accept mail from static IP, genuine ISP or corporate mail servers, even when the target recipient is a domain they host. This would pretty much make bot nets useless to the spammers, and force them to revert to running their own mail servers, or trying to compromise other legitimate servers.
It wouldn't eliminate the problem, but would severely reduce the number places we have to fight spam.
The fastest we've ever gotten a machine to spit data out the line was with a 10 gig ethernet card, with a TOE in it, and that rate was 1.2 gigabit/second. The bus could handle 7.6 gigabit max, but we got nowhere near that due to the framing involved. We were just piping /dev/random over a netcat connection and into /dev/null, too. Couldn't figure out how to do anything faster. Any ideas? Cause we were stumped.
/dev/random. You could try sourcing data from /dev/zero. Although it will be a very repetitive pattern of bits, I don't think that should affect the outcome. Or just source data from a bigass file, but this will be tainted by the speed of your hard disks.
It's possible you only had enough entropy to generate 1.2Gbps of data from
Also, think about whether you're interested in measuring TCP throughput, UDP throughput (which I'd expect to be a litte higher), or raw Ethernet throughput (which will be as close to the theoretical limit of the card as possible).
Running something like SCSI over TCP/IP does seem like quite a lot of overhead, but when you look closer, TCP/IP is handling a lot of things that AoE will have to implement at the application layer - things like reliable delivery, and ensuring correct sequencing of packets.
Some people will wonder why we need the ability to route such a protocol (like yeah, as if we're going to run iSCSI over a WAN link). How about inter-VLAN routing though? It's probably in the same building, and on a gigabit LAN, but it's a different IP subnet, so it needs to be routed.... ok, you're gonna need a kickass L3 switch to avoid being a bottleneck, but...
Of course, implementing iSCSI in software and using a standard NIC & driver will clearly be a bit sluggish. Use a NIC with a TCP offload engine and things get a bit faster. Use an actual iSCSI NIC and you're then doing about as much in hardware as you can.
Then there's iSCSI over IPv6, which is supposedly faster to process the IP header of, than IPv4.
So yes, AoE certainly would be a leaner protocol than iSCSI, but by the time you add checksums, reliable delivery, sequencing, and routing (with only a MAC address??), you've probably reinvented TCP/IP.
So who's going to be the first to come up with AoI (ATA over IPX), AoD (ATA over DECnet), and AoA (ATA over Appletalk)?
We get PMs when SNMP reports high utilization on a switch. From there, we open the switch's graphs and determine who is doing what. If a user's port is screaming, we disconnect them and go over to see what's up.
.com/net/org.
In a graphic design house, or anywhere that routinely works on large files, that's going to inconvenience and maybe even infuriate a lot of people. A large file copy is going to make a port "scream", that is, up until you disconnect it. Do you strap on a bulletproof vest and riot helmet before confronting the user of that port?
You should possibly consider taking a look at Cisco NAC.
Or they password the ZIP and include the pass in the email. If you allow it, it will be exploited.
So you quarantine anything that is not scannable. I'd rather do that, than make email virtually useless by blocking all attachments outright. Unless your job title is BOFH, that's just gonna piss people off, and some of those people may be the ones who write your paychecks.
I did some work for a company a while back that blocked everything not in the US. Users would get blocked from everything that didn't end in a
The domain TLD has nothing to do with the geographic location of a server. It might have been a rough guide, once upon a time. Anyway, I was thinking more along the lines of whitelisting sites you trust, regardless whether they're US, German, Chinese... sites that your users have a legitimate reason to connect to.
But ICMP? Users don't usually need to ping.
ICMP entails quite a bit more than just ping. If the PC is unable to receive "network/host/protocol/port unreachable", they'll just sit there stupidly until the connection times out. "TTL expired" and "needs fragment" are also fairly important.
I think that if you run the protocols on nonstandard ports and close those on your external firewall, you should be OK. Admins need a remote desktop app to troubleshoot. Nothing is more useless than having a user describe a problem. If they can show you the prob, it can be cleared quickly.
If you run services on nonstandard ports, you're only going to stop the dumbest of hackers. Anyone with a clue will portscan your box, to see what's open. From there, it's relatively easy to identify the protocol bound to a particular port. Security through obscurity is not really security. As for blocking ports on a firewall, of course, that is standard practice. But often the threat these days is within an organisation. Most LAN's have very little network security, once inside the perimeter. Crunchy on the outside, soft and chewy on the inside.
I agree however, it's useful to be able to take remote control of a user's desktop. Citrix has such a feature built in, called "shadowing a session". Of course, that's in a Citrix environment, not an XP desktop environment.
And no one should be getting ZIPs, RARs, EXEs, and the like. The smart ones begin renaming the extension.
Even open source mail scanning gateways such as Amavisd-new support banned filename extensions. Couple that with ClamAV, and scan all attachments not yet banned, including recursive scanning of compressed archives, and you get quite a bit of security for very little cost. I've seen this solution fare better than commercial ones, which failed because the virus was a ZIP inside a ZIP.
Images can link to external servers and be used to verify good IP and e-mail addresses.
True... which is why most email clients these days do not display images (and thus invoke the HTTP connection to retrieve that invisible 1px image) by default. This kind of thing can also be prevented by having a web proxy that only allows access to whitelisted sites.
Still, you have to give users read/write to their group folders.
Yes you do, there is no way around that. All you can do is give people access to the minimum amount possible. Beyond that, backups are really your only safety net.
... to turn the engine off?
or, be prompted with dialogs along the lines of "Applying the brakes will cause temporary loss of your vehicle's speed. Are you sure, Y/N?"
That install would come with a VMWare player image of the user's standard install with full admin rights to the user. The VMWare image would be for special dev tools or just for those times when a user "has to have admin".
I can't see how making the user suffer the performance overhead of VMware is a security measure. If this is an attempt to provide a quick way to re-image a workstation after a user has bollocksed it up, why not just use a hard drive imaging tool?
The desktop should include a firewall. Only 80 and 443 should be open for outgoing.
So, no SMB/CIFS/NFS to allow them to actually work with their data on the SAN/NAS? No DNS so they can actually resolve the address of the SAN? No ICMP so that the host actually has a clue when it tries to connect to something that is unreachable?
Incoming should have RDP or VNC open for admins to get in.
Don't forget hackers...
On the e-mail side. Attachments should not be allowed.
That would destroy the reason most people use email these days. Can you imagine how effectively a salesperson or manager is going to be able to do their job, if they can't easily send markting material such as PDF's or PPT's to customers?
HTML e-mail would be allowed, but images would be stripped.
Why? What makes an image any more of a threat to security than a rich-text email (especially when read with certain well known mail clients... *cough* Outlook *cough*) ?
Have good backups and at least try to keep a virus on the user's desktop from raping your SAN/NAS.
That usually comes down to implementing sensible file/directory permissions, and the challenging task of educating users to actually save stuff in the right place.
I could make the most secure airline in the world. But no one would ever want to fly completely naked and cuffed to their seats.
I don't see how your sexual kinks play a role in this discussion.
Why would terrorists or criminals be compelled to obey this particular law, while they're breaking others? This is just plain stupid. Even if all the businesses caved in and submitted their keys, does the UK government really they're going to get emails along the lines of:
"Hi, I represent the West London cell of Al Qaeda. In accordance with the new encryption laws, please find attached all our private keys. Thank you, and have a nice day!"
Laws only work on honest people.
Unless you propose some method of tracking (relatively) nearby aircraft, so as to aim a reasonably directional antenna at them, you're going to have to use a horribly inefficient omnidirectional antenna.
Also, bear in mind that once outside of ATC zones (ie, in the middle of oceans), about the only long distance communication that works is HF SSB (and in theory, lower frequencies too). The bandwidth of these HF channels used by aircraft is less than the VHF they use for communication when over land, and you'd need to allocate big chunks of international spectrum to get the required bandwidth for implementing what would essentially a be mesh network.
Replacement of the existing HF voice communication system with satellites are underway, so I guess they figured that's the optimal way.
If Connexion used lower altitude, polar-orbiting satellites, this would obviously reduce latency, but would require tracking of those satellites, and some kind of handover system whenever a satellite went below the horizon.
It might have XGL eye candy, but it's running an outdated version of GNOME. Is SUSE still favouring their KDE heritage? It was Novell that sort of pushed GNOME upon SUSE when they bought them.
Debian GNU/kFreeBSD is still in its infancy, and doesn't get a lot of attention (yet), so it's understandably not as advanced as Debian GNU/Linux. I didn't say I preferred Debian GNU/kFreeBSD over FreeBSD, and at this point in time, if I was actually intending to run a FreeBSD kernel, I'd run FreeBSD.
The point I was trying to get across is that Debian GNU/Linux is a reminder that it's the GNU OS, with a Linux kernel. Likewise Debian GNU/kFreeBSD is the GNU OS, with a FreeBSD kernel. Rather than build an entire OS (-distribution) exclusively around one kernel, it's evidence that the kernel can simply be one single component of that OS (in this case, provided that the kernel is UNIX-like).
I think this is important because, what if Linux just so happens to not be the greatest kernel ever? Or, what if HURD/L4/whatever just so happens to one day be useable?
Wouldn't it be a shame to throw away all that hard work invested in Debian's package repositories?
This is why projects like Debian's kFreeBSD are important - so that if the Linux kernel does run amok completely (or at least degenerate significantly), we can continue using various Linux ~distributions~ - just with a different engine room.
When most people think "Linux", they're usually thinking of all the commonly associated open source software bundled as a distribution. If you can swap out the kernel but keep the same GUI, the same traditional *nix shells and CLI tools they're used to - will people really care that much?
OTOH, maybe it's time Linux looked at going microkernel. Maintaining a monolithic kernel that just keeps getting bigger and bigger can't be an easy task. At least a microkernel would allow a degree of separation between the kernel proper, and the various hardware drivers, networking stacks, filesystems etc.
I probably should have read TFA. I got the impression from the Slashdot summary that the RIAA had detected filesharing traffic coming from universities' internet gateways.
That said, I really have to question how much jurisdiction the RIAA should be allowed to have on a private network. Surely it's up the universities themselves to decide what traffic they do/don't allow within the confines of their own LAN.