So AirControl "doesn't play well with other network monitoring software" (which one, and why?), and MikroTik "isn't built for what [you] need" (what's that?) - other than that, you don't give us any idea what you really expect. What are your requirements?
Suggestions out of the blue: OpenWRT with quagga/zebra, hostapd, radius, olsrd, b.a.t.m.a.n. etc. etc, or you might want to have a look at Vyatta (no affiliation).
Hot tablespace-based backups, combined with write-ahead log backups, as seen in Oracle since version 8 (or even 7?) This is an extremely nice feature when you have large databases and no chance for regular scheduled downtime and still want backups, both complete and incremental ones. Compared to the export-based feature of PostgreSQL, it would put way less load onto the server, because tablespace-based and WAL-based backup bypasses the SQL engine, so it is copying a (for example) 200 GB files vs. 200 GB query-based export
Better and more integrated replication. There are a number of independent projects that want to create replication add-ons, like pgreplication and the older, more academic Postgres-R, but that's not really production quality so far. According to some consultant that is working tightly with PostgreSQL and the developers, they are working on it, but he was really hedging when asked about advanced features and was theorizing how practically impossible and/or expensive multi-master realtime replication would be... An optional feature for many users, granted, but still something you might want for scaling beyond certain limits.
Said that, PostgreSQL is a really great thing, and being FOSS, I could of course always go ahead and add the named features....)
1. You mentioned that the air intake for the computer room was adjacent to the so-called "rendering portion" in your slaughterhouse, excusez moi, abattoir. Why did nobody notice and take care for this in advance, long before the computers started absorbing the smell? If computers start smelling that badly, the actual smell in that room's air must have been totally abhorrent and somebody could have noticed.
Otherwise, if people didn't notice or noticed and didn't care, everybody seems to have gotten used to that smell, it's a slaughterhouse anyway, so they should cope with the smell in the shiny offices now as well.
2. Many comments suggest disassembling the computers, thoroughly soaking each and every part with ethanol, propanol, baking powder or other substance, optionally covering sensitive parts with duct tape in advance. Then have it drying, reassemble and try if the smell is gone, and I guess the same people would suggest doing it again if the first run didn't completely remove the smell.
Excuse me? How many boxen are we talking? What is somebody supposed to earn per hour who is doing this? How does it compare to the value of the computers (or new computers), and is this economical at all? How much is one of this boxen you are talking about? Doesn't your industrial meat processing company make some money so that you can get a few new boxen? How many computers does a slaughterhouse need, provided you aren't somehow dedicated to SETI@abattoir?
While I think reusing gear is a good thing in general (for both economical and environmental reasons) I guess this particular case might not be of much economical value. Given that your business involves such nice products as bone meal, I would assume that environmental considerations are limited mostly to rotten smell in your whitecollar slaughterhouse offices.
Maybe you should instead put these computers up in the production and rendering facilities themselves, where smell doesn't matter, together with some webcams, so your customers can watch your work and thus develop a more affecious relationship to you as a company.
Say I wanted to upgrade from fedora core 2 to fedora core 3, I could just download an upgrade iso at a fraction of the size etc.
As somebody pointed out before in this article, there is rsync which minimizes transmitted data using some xdelta-like algorithm. This is not really new, and some sites offer anonymous rsync downloads for exact this reason.
(Rumours were that some people actually use rsync in the following way to get the latest Debian ISOs from a collection of old, already downlod packages: They cat'ed all their packages together to one huge binary file and then ran rsync against the remote ISO image and that local file. Since most data was already in that file, only transmission of a few megabytes of new data and some data arranging had to happen....)
Here I uttered a few quick&dirty thoughts (which most certainly somebody else has had before, as usual) on how rsync could help in mass patching, don't know if they are worth reading for you....)
Yes, rsync is very convenient for sync'ing systems and saving bandwidth. When applying this to large-scale xdelta patch distribution, how about having a client-server scenario which works as follows:
Have the client read the package database and send the package inventory to the server
Have the server create a representation of all the packages involved in the client's installation, as some kind of 'virtual filesystem shnapshot'
Have the server (virtually) apply the updates to the virtual image, getting an up-to-date image, and creating the xdelta between both
Have the server send that delta and the client apply it, with some automagical final updates to the local package database on the client side
While implementing this is nothing for the faint of heart and would suggest some huge resources on the server side at first sight, it would make xdelta updates possible, while taking care of all the different package combinations on all the possible systems to update.
Now, would SuSE/Novell, RedHat or whoever please hire me in order to do this?;)
Many, maybe you want to check out my former post on this and follow the links mentioned...
Re:If only USB adapters were supported...
on
Linux Unwired
·
· Score: 1
There are loads of 802.11b USB adapters that are supported by Linux. Check out the AT76c503a BerliOS driver project or the original ATMEL driver project, where you will find a list of supported WLAN USB dongles with the well-supported Atmel chipset. Otherwise, the Prism2 drivers support a number of WLAN USB devices, too. 802.11b USB WLAN devices should be available for around 20-30 Euros (approx. 25-35USD) each in some shop close to you...
Unfortunately, your WG121 is not among those, but the Linux Prism GT driver project at least mentions it (although with a pretty disturbing "unknown status" and a "success rate" close to 90%, which seems kinda oxymoronous), so maybe it's worth a try. Atheros chipsets are supported by the MadWifi project, too...
Having read on secure multicast before, I wonder which implementation actually provide complete multicast support? I checked KAME, and they don't seem to, neither does the infamous FreeS/WAN or it's follow ups, and I guess the IP filtering problem with MS's stuff isn't the only problem, since their are no secure multicast extension implemented AFAIK.
Maybe you don't consider these as proper, so I would really like to know which IP implementations support secure multicast via IPSec, including group key management etc.
To my knowledge, the secure multicast concepts and potential implementations haven't left the research labs (except Secure Spread which I mentioned in another post and isn't based on IPSec).
I would be glad to be wrong and it would be nice if you could provide us with some implementation links....)
Sometimes I wonder why people cannot come up with the same Google results and other information that needs just a couple of minutes and a few braincells to research, especially when it seems part of their jobs to do so.
Anyway, this is an interesting question and problem, and I had to research this topic a few months ago myself, and came up with the Secure Multicast IETF that is dealing with reserach and secure multicast standards. One of the bigger research platform seems to be Secure Spread, a framework derived from the Spread Toolkit for reliable muticast. These are good places to start with the problem of secure multicast I think, although Secure Spread seems not to be under heavy development since 2002.
Since the original poster mostly talked about means to provide secure authentication and/or key distribution (dongle and smart-cards), I would like to point out that the main problem of secure multicast is rather providing
a secure way of authentication and authorization of clients trying to join a multicast group
a secure way to distribute shared keys for members of the same multicast group
a secure way to re-key shared keys for all members of a multicast group
a way of stopping access to the multicast data for specific members of a multicast group that should be rejected further data access (due to administrative decision) while maintaining the rest of the multicast group members and functionality
Neither IPSec, the number one secure IP protocol, provides for that, nor do IGMP or multicast routing protocols which are used for multicast group management. If you manage to solve this, the actual problem of distributing and managing account data to customers will be a bliss. (Oh, and since you involved the/. community in this problem, I expect you to provide your solution as free software, or at least open source, to the public....)
I had to deal with VoIP and video conferencing over WLAN for a couple of months, and everything said here is correct:
Yes, it can work perfectly under certain circumstances, and then...
right in the middle of a nice VoIP session everything goes havoc, maybe because somebody else associated with the AP from quite far away thus making the whole AP performance flakey.
It can work out when you are lucky, or/and when you do it under pretty optimal circumstances. But it's also true that the 802.11 world lacks any practical implemented QoS measures so far, and that APs are behaving astonishingly instable and unperformant under certain circumstances, especially when they have to deal with constant data streams, like during VoIP phone calls. Collision avoidance schemes, frame retransmission, bad signal, this can all cause VoIP to go down the toilet in a wink of an eye.
I also have plaid with Skype in Wifi environments with questionable reliability and quality, and it worked amazingly well...
What is the conclusion of this? It's neither a "Sure it's ready for broad VoIP use, because it worked for me", neither is it "I failed,thus it's not ready." It just means that it can work, but isn't reliable, while there have improvements to be made to get it more thrustworthy for real world use.
Anyway, reliability of 802.11 gear is not the only obstacle that keeps us from efficiently using VoIP as a POTS or mobile phone alternative. I haven't come across any metropolitan (or other) area where there is enough and effordable WLAN coverage to really use VoIP, and as a simple DECT phone (aka wireless home phone connected to POTS), this is more like a geeky toy than a real application.
Thanks for the rant, Bill. PPTP, esp. when MS-compatible, is way less secure than IPSec. Today, the biggest problem with PPTP is the connection between password strength and encryption strenght (see Schneier's analysis on PPTPv2 for details), and as soon as this problem is worked-around (see for example the Designfragen discussion for some CS department WLAN, if you can read German), PPTP is 'middle secure'.
What makes PPTP a tempting VPN protocol is it's availibility among different plattforms. Although some plattforms offer built-in IPSec support, these implementations often differ in certain details which harms interoperability a lot. We have extensions like XAUTH, L2TP, DHCP-over-IPSec, not to mention the many different options to be configured, and even the new Mac OS X Panther release does strange things with it's IPSec-L2TP implementation. Yes, you get beer-free VPN IPSec clients in case you buy expensive iron, Cisco for example, but for many this is too much money...
PPTP is for poor man's VPN only, but if this is enough security for your setting (and you can increase this through tight password policies), you will have instant VPN access from all kinds of common plattforms, free and not free ones...
IPSec is great, but seldomly available and/or not trivially deployable. PPTP is less secure, but it's out there... Life isn't always that simple.
Re-reading the documents available on the noiptun site, it seems that you need some kind of IP-addressable machine that works as a proxy to reach the actual noiptun'ed box bearing no IP address, in case you want to connect from outside the same network segment (speaking of layer 2 here), because ARP will not be routed... If I understood this correct, this in fact is nothing a permanent arp'ing machine couldn't do, maybe it would feel a bit less convenient when using arp -s proxies, though. Which is not the fault of noiptun itself...
Then, if I can connect to a machine using arp -s (maybe throught some alike proxy), I can use whatever protocol I want, including SSL, SSH etc.
I don't want to diss the noiptun people, every idea being made reality has some value for somebody, and I guess this will be of some use for hidden snort users... But in fact, I am not as excited as some others among the/. croud, because it just does not feel as rocket-science-ish for me as the headline suggests...
Uhmm... I might be wrong, but what about using the arp command option -s to permanently attach an ARP address to some (made up) IP address? In effect, this allows for reaching that host without specific IP address as well...
What does noiptun add in functionality to this, what have I missed?
How is this stuff that matters? Or news for nerds? Boring cereals... Or is it that coffee-flavoured stuff was forbidden so far in the U.S. or forced in brown bags and north-american-centric slashdot has discovered a new liberty in marketing coffee-ish stuff...
And elsewhere on/. people are concerned about blinkenlights not being important enough.... *sigh*
As a sysadmin and partial developer, I have come across a number of different species: Compentent co-sysadmin and incompetent ones, and incompetent ones that behave like the infamous BOfH. But I also met completely ignorant developers who do not have the slightest clue about system security, stability, maintainable software, and for the worst, collaboration with coworkers and responsible behavior in a systems environment. I don't want to see them manage the systems, either, dealing with their software on the systems operated by me is often depressing enough.
Yes, there is absolutely no need to be semifascist when it comes to systems control if you have people, including developers, using resources responsibly. But for admins, believing in the Good User/Developer(tm) that always knows how to behave is a daydream. There are both kinds of developers, nice and competent and dorks, too, and you don't want the dorks to harm the often business-critical servers you are in charge of.
Moreover, blaming the sysadmin for systems being overloaded by too long backups is easy, having the cheap management to invest in more capable gear might be not so easy, from my experiences. That oh-so-badly managed db server almost crashing under its load might work more smoothly if either the software and data design had been done more carefully, or if the CTO wouldnt have chosen the cheapest server without talking to the admins in the first place. And restrictive firewalling rules which keep the dear user or developer from using Gnutella might be seen as evil, but it might as well keep these ugly RIAA Cease&Desist letters from being sent to the CEO again....
The article describes a developer-admin relationship that is pretty similar to a bad user-admin-relationship. Apart from dealing with villain admins, work quality and efficency can be improved significantly through communication and understand each others needs and expectations.
And BTW, I wonder if outsourcing administration is mostly done due to bad quality of in-house admins, but rather to save money. This often reflects how poorly admin work is respected and valued through management, even the professional and good work, maybe because good admin work happens mostly behind the scenes. I know a lot of small companies that suffered badly from outsourcing administrational issues, mostly because the admin(s) who "obviously did not do so much during their work time, so we might outsource their service anyway" now were missing in the critical situations when you absolutely want a dedicated admin who knows his/her environment well.
Now, will case modders with transparent cases have to face a new optical tempest problem (beware, PDF link!)? (People being able to sniff potentially critical data through analyzing LED blinking, that is...)
NiHM accus are fine for everything I ever used, at least when you need AA or AAA types. They offer the same voltage, last long, are cheap, don't have that memory effect, and not to forget, they are nice to the environment!.
The only reason to occasionally use batteries is when you really don't have any accus handy as on journeys, and you can get some at the next kiosk of something. Otherwise (and this means 'usually'): accus! (This might be a redundant, but still, why would anybody use evil throw-away batteries on a regular basis today?! Mind the children...
The most practical alternative at the present time appears to be use of a magnetic stripe card in addition to the password, similar to the authentication process for an ATM.
What you refer to is known as multi factor authentication, IIRC. I agree that deploying authentication using the "need to have" and "need to know" dualism is way more secure than simple password authentication in principle. Besides that, the Kinko incident suffers from the problem that a public terminal cannot be trusted, and it wouldn't be more trustworthy by adding a magnetic card reader, since that card reader again is under control of the untrusted terminal.
The equivalent to key loggers in using card readers is card loggers. There is no big difference between logging confidential key strokes and confidential digital data while being read by the computer, so I think this does not add to the security of public terminals at all.
What probably would help is
One Time Passwords that by design don't allow for password stealing and reusage, or
some device that work like the infamous SecurID cards, which basically take the one time password burden from the user and put it into a small smart device that generates and/or remembers them for you
Both techniques still don't help against Woman-in-the-Middle or hijacking attacks, because they still have to trust the terminal device to transmit the authentication data in a manner the user intended it to.
This brings me to the question: Can anybody think up a way to use inherently untrustworthy public terminals in a trusted matter? How can you make the terminal transport sensitive data in a secured way? Any ideas?
The most promising answer to this problem to the paranoid (read: "sensible") roaming internet user seems to bring your own network-enabled devices, and find a way to connect them to the Net, for example through public WLAN hotspots. Then you can choose your own method to secure the data path, knowing that the end device is trustworthy because it is under your control (provided you run software and hardware that in fact can be considered trustworthy, for some profound reason, but that is another story I guess....)
I wonder which of these categories this story is supposed to belong to... None, IMHO. In some part of the world, you are allowed to drive kinky golf carts now on real(tm) roads... Whoa!
What's the next/. article? Government in Portugal allowing ice-cream vendors to wear leather underwear?
I have got my SDF public shell access at lonestar about two years ago, and I love it! It's (almost, because they required people to send in a buck to show they seriously want to use it and don't create lots of fake accounts) free, they have nice services, rely mostly on their users' affection and willingness to donate money or equipment to them, and you can upgrade for some money to use more features... I hope they will manage to migrate to their new hoster...
What puzzles me is that NWLink seemd to have disconnected SDF because they fell preyto some DDoS'ing, they were not actively involved in some (D)DoS towards other sites, at least that's how I read the announcement!
Consequently, this DDoS might have been one of the most successful one reported, since it not only hogged their connection and thus technically Dos'sed them for a while, but this led to some organizational DoS carried out by NWLink!
How can they dare blaming the victim? And how can they dare putting all the consequences (that is, disconnection) onto the victim as well? Is this legal? Is this good practice? And: Does it help stop the DDoS towards SDF? Okay, the target host(s) is/are down, but the packets might rush to the dangling patch cable end anyway, crossing NWLink's infrastructure...
All in all: Thanks to the DDoS people attacking a nice and free public service!:( (Not that I am some DDoS fan of any kind, but aren't there much more promising targets out there, both in terms of
popularity, evilness and challenging huge trunks? Or did some script kiddies just got their shell accounts revoked, and now they felt like stomping their virtual feet? I hope you have learnt to deal better with your frustration by the age of 12...)
And big thanks to NWLink for dealing with a customer's problem in a great and professional way by supporting a DDos through fully shutting down services!
-- "Where do you wanna go today / Somewhere you could never take me" -- Chumbawamba
In order to contribute to mutual understanding: I don't belive (although - as most of the times - i might be wrong) that it's mostly about costs. Sending an SMS for me primarily has the same reason as choosing an email over a letter or a phone call: Its handy, you don't have to disturb the recipient, but she can receive the msessage when convenient, and concerning appointment dates and times, you don't have to take notes, but can store an SMS in the cell phone.
Maybe that's the SMS culture you refer to... You miss a lot of fun with emoticon smileys.)... And BTW, the learning curve isn't quite that steep also;)
Slashdot Mirror
So AirControl "doesn't play well with other network monitoring software" (which one, and why?), and MikroTik "isn't built for what [you] need" (what's that?) - other than that, you don't give us any idea what you really expect. What are your requirements? Suggestions out of the blue: OpenWRT with quagga/zebra, hostapd, radius, olsrd, b.a.t.m.a.n. etc. etc, or you might want to have a look at Vyatta (no affiliation).
... and it would really really rock!
Said that, PostgreSQL is a really great thing, and being FOSS, I could of course always go ahead and add the named features... .)
1. You mentioned that the air intake for the computer room was adjacent to the so-called "rendering portion" in your slaughterhouse, excusez moi, abattoir. Why did nobody notice and take care for this in advance, long before the computers started absorbing the smell? If computers start smelling that badly, the actual smell in that room's air must have been totally abhorrent and somebody could have noticed.
Otherwise, if people didn't notice or noticed and didn't care, everybody seems to have gotten used to that smell, it's a slaughterhouse anyway, so they should cope with the smell in the shiny offices now as well.
2. Many comments suggest disassembling the computers, thoroughly soaking each and every part with ethanol, propanol, baking powder or other substance, optionally covering sensitive parts with duct tape in advance. Then have it drying, reassemble and try if the smell is gone, and I guess the same people would suggest doing it again if the first run didn't completely remove the smell.
Excuse me? How many boxen are we talking? What is somebody supposed to earn per hour who is doing this? How does it compare to the value of the computers (or new computers), and is this economical at all? How much is one of this boxen you are talking about? Doesn't your industrial meat processing company make some money so that you can get a few new boxen? How many computers does a slaughterhouse need, provided you aren't somehow dedicated to SETI@abattoir?
While I think reusing gear is a good thing in general (for both economical and environmental reasons) I guess this particular case might not be of much economical value. Given that your business involves such nice products as bone meal, I would assume that environmental considerations are limited mostly to rotten smell in your whitecollar slaughterhouse offices.
Maybe you should instead put these computers up in the production and rendering facilities themselves, where smell doesn't matter, together with some webcams, so your customers can watch your work and thus develop a more affecious relationship to you as a company.
--
I expect troll mods for this opinion.
As somebody pointed out before in this article, there is rsync which minimizes transmitted data using some xdelta-like algorithm. This is not really new, and some sites offer anonymous rsync downloads for exact this reason.
(Rumours were that some people actually use rsync in the following way to get the latest Debian ISOs from a collection of old, already downlod packages: They cat'ed all their packages together to one huge binary file and then ran rsync against the remote ISO image and that local file. Since most data was already in that file, only transmission of a few megabytes of new data and some data arranging had to happen....)
Here I uttered a few quick&dirty thoughts (which most certainly somebody else has had before, as usual) on how rsync could help in mass patching, don't know if they are worth reading for you... .)
While implementing this is nothing for the faint of heart and would suggest some huge resources on the server side at first sight, it would make xdelta updates possible, while taking care of all the different package combinations on all the possible systems to update.
Now, would SuSE/Novell, RedHat or whoever please hire me in order to do this? ;)
Any comments?
Many, maybe you want to check out my former post on this and follow the links mentioned...
Unfortunately, your WG121 is not among those, but the Linux Prism GT driver project at least mentions it (although with a pretty disturbing "unknown status" and a "success rate" close to 90%, which seems kinda oxymoronous), so maybe it's worth a try. Atheros chipsets are supported by the MadWifi project, too...
Maybe you don't consider these as proper, so I would really like to know which IP implementations support secure multicast via IPSec, including group key management etc.
To my knowledge, the secure multicast concepts and potential implementations haven't left the research labs (except Secure Spread which I mentioned in another post and isn't based on IPSec).
I would be glad to be wrong and it would be nice if you could provide us with some implementation links... .)
Anyway, this is an interesting question and problem, and I had to research this topic a few months ago myself, and came up with the Secure Multicast IETF that is dealing with reserach and secure multicast standards. One of the bigger research platform seems to be Secure Spread, a framework derived from the Spread Toolkit for reliable muticast. These are good places to start with the problem of secure multicast I think, although Secure Spread seems not to be under heavy development since 2002.
Since the original poster mostly talked about means to provide secure authentication and/or key distribution (dongle and smart-cards), I would like to point out that the main problem of secure multicast is rather providing
Neither IPSec, the number one secure IP protocol, provides for that, nor do IGMP or multicast routing protocols which are used for multicast group management. If you manage to solve this, the actual problem of distributing and managing account data to customers will be a bliss. (Oh, and since you involved the /. community in this problem, I expect you to provide your solution as free software, or at least open source, to the public... .)
I had to deal with VoIP and video conferencing over WLAN for a couple of months, and everything said here is correct:
It can work out when you are lucky, or/and when you do it under pretty optimal circumstances. But it's also true that the 802.11 world lacks any practical implemented QoS measures so far, and that APs are behaving astonishingly instable and unperformant under certain circumstances, especially when they have to deal with constant data streams, like during VoIP phone calls. Collision avoidance schemes, frame retransmission, bad signal, this can all cause VoIP to go down the toilet in a wink of an eye.
I also have plaid with Skype in Wifi environments with questionable reliability and quality, and it worked amazingly well...
What is the conclusion of this? It's neither a "Sure it's ready for broad VoIP use, because it worked for me", neither is it "I failed ,thus it's not ready." It just means that it can work, but isn't reliable, while there have improvements to be made to get it more thrustworthy for real world use.
Anyway, reliability of 802.11 gear is not the only obstacle that keeps us from efficiently using VoIP as a POTS or mobile phone alternative. I haven't come across any metropolitan (or other) area where there is enough and effordable WLAN coverage to really use VoIP, and as a simple DECT phone (aka wireless home phone connected to POTS), this is more like a geeky toy than a real application.
What makes PPTP a tempting VPN protocol is it's availibility among different plattforms. Although some plattforms offer built-in IPSec support, these implementations often differ in certain details which harms interoperability a lot. We have extensions like XAUTH, L2TP, DHCP-over-IPSec, not to mention the many different options to be configured, and even the new Mac OS X Panther release does strange things with it's IPSec-L2TP implementation. Yes, you get beer-free VPN IPSec clients in case you buy expensive iron, Cisco for example, but for many this is too much money...
PPTP is for poor man's VPN only, but if this is enough security for your setting (and you can increase this through tight password policies), you will have instant VPN access from all kinds of common plattforms, free and not free ones...
IPSec is great, but seldomly available and/or not trivially deployable. PPTP is less secure, but it's out there... Life isn't always that simple.
Then, if I can connect to a machine using arp -s (maybe throught some alike proxy), I can use whatever protocol I want, including SSL, SSH etc.
I don't want to diss the noiptun people, every idea being made reality has some value for somebody, and I guess this will be of some use for hidden snort users... But in fact, I am not as excited as some others among the /. croud, because it just does not feel as rocket-science-ish for me as the headline suggests...
What does noiptun add in functionality to this, what have I missed?
And elsewhere on /. people are concerned about blinkenlights not being important enough.... *sigh*
Yes, there is absolutely no need to be semifascist when it comes to systems control if you have people, including developers, using resources responsibly. But for admins, believing in the Good User/Developer(tm) that always knows how to behave is a daydream. There are both kinds of developers, nice and competent and dorks, too, and you don't want the dorks to harm the often business-critical servers you are in charge of.
Moreover, blaming the sysadmin for systems being overloaded by too long backups is easy, having the cheap management to invest in more capable gear might be not so easy, from my experiences. That oh-so-badly managed db server almost crashing under its load might work more smoothly if either the software and data design had been done more carefully, or if the CTO wouldnt have chosen the cheapest server without talking to the admins in the first place. And restrictive firewalling rules which keep the dear user or developer from using Gnutella might be seen as evil, but it might as well keep these ugly RIAA Cease&Desist letters from being sent to the CEO again....
The article describes a developer-admin relationship that is pretty similar to a bad user-admin-relationship. Apart from dealing with villain admins, work quality and efficency can be improved significantly through communication and understand each others needs and expectations.
And BTW, I wonder if outsourcing administration is mostly done due to bad quality of in-house admins, but rather to save money. This often reflects how poorly admin work is respected and valued through management, even the professional and good work, maybe because good admin work happens mostly behind the scenes. I know a lot of small companies that suffered badly from outsourcing administrational issues, mostly because the admin(s) who "obviously did not do so much during their work time, so we might outsource their service anyway" now were missing in the critical situations when you absolutely want a dedicated admin who knows his/her environment well.
So much for whining on the admin side.. .)
Now, will case modders with transparent cases have to face a new optical tempest problem (beware, PDF link!)? (People being able to sniff potentially critical data through analyzing LED blinking, that is...)
NiHM accus are fine for everything I ever used, at least when you need AA or AAA types. They offer the same voltage, last long, are cheap, don't have that memory effect, and not to forget, they are nice to the environment!.
The only reason to occasionally use batteries is when you really don't have any accus handy as on journeys, and you can get some at the next kiosk of something. Otherwise (and this means 'usually'): accus! (This might be a redundant, but still, why would anybody use evil throw-away batteries on a regular basis today?! Mind the children...
Easy, yes, but not truely practical I suppose...
The most practical alternative at the present time appears to be use of a magnetic stripe card in addition to the password, similar to the authentication process for an ATM.
What you refer to is known as multi factor authentication, IIRC. I agree that deploying authentication using the "need to have" and "need to know" dualism is way more secure than simple password authentication in principle. Besides that, the Kinko incident suffers from the problem that a public terminal cannot be trusted, and it wouldn't be more trustworthy by adding a magnetic card reader, since that card reader again is under control of the untrusted terminal.The equivalent to key loggers in using card readers is card loggers. There is no big difference between logging confidential key strokes and confidential digital data while being read by the computer, so I think this does not add to the security of public terminals at all.
What probably would help is
Both techniques still don't help against Woman-in-the-Middle or hijacking attacks, because they still have to trust the terminal device to transmit the authentication data in a manner the user intended it to.
This brings me to the question: Can anybody think up a way to use inherently untrustworthy public terminals in a trusted matter? How can you make the terminal transport sensitive data in a secured way? Any ideas?
The most promising answer to this problem to the paranoid (read: "sensible") roaming internet user seems to bring your own network-enabled devices, and find a way to connect them to the Net, for example through public WLAN hotspots. Then you can choose your own method to secure the data path, knowing that the end device is trustworthy because it is under your control (provided you run software and hardware that in fact can be considered trustworthy, for some profound reason, but that is another story I guess... .)
What's the next /. article? Government in Portugal allowing ice-cream vendors to wear leather underwear?
Now that they are being /.ed, they certainly are under cyber attack...
I smell a Strong Binding patent approaching...
Cool, so we just found the solution for world-wide starvation in poor areas...
I have got my SDF public shell access at lonestar about two years ago, and I love it! It's (almost, because they required people to send in a buck to show they seriously want to use it and don't create lots of fake accounts) free, they have nice services, rely mostly on their users' affection and willingness to donate money or equipment to them, and you can upgrade for some money to use more features... I hope they will manage to migrate to their new hoster...
What puzzles me is that NWLink seemd to have disconnected SDF because they fell preyto some DDoS'ing, they were not actively involved in some (D)DoS towards other sites, at least that's how I read the announcement!
Consequently, this DDoS might have been one of the most successful one reported, since it not only hogged their connection and thus technically Dos'sed them for a while, but this led to some organizational DoS carried out by NWLink!
How can they dare blaming the victim? And how can they dare putting all the consequences (that is, disconnection) onto the victim as well? Is this legal? Is this good practice? And: Does it help stop the DDoS towards SDF? Okay, the target host(s) is/are down, but the packets might rush to the dangling patch cable end anyway, crossing NWLink's infrastructure...
All in all: Thanks to the DDoS people attacking a nice and free public service! :( (Not that I am some DDoS fan of any kind, but aren't there much more promising targets out there, both in terms of
popularity, evilness and challenging huge trunks? Or did some script kiddies just got their shell accounts revoked, and now they felt like stomping their virtual feet? I hope you have learnt to deal better with your frustration by the age of 12...)
And big thanks to NWLink for dealing with a customer's problem in a great and professional way by supporting a DDos through fully shutting down services!
--
"Where do you wanna go today / Somewhere you could never take me"
-- Chumbawamba
Look, another culture clash! :)
In order to contribute to mutual understanding: I don't belive (although - as most of the times - i might be wrong) that it's mostly about costs. Sending an SMS for me primarily has the same reason as choosing an email over a letter or a phone call: Its handy, you don't have to disturb the recipient, but she can receive the msessage when convenient, and concerning appointment dates and times, you don't have to take notes, but can store an SMS in the cell phone.
Maybe that's the SMS culture you refer to... You miss a lot of fun with emoticon smileys .) ... And BTW, the learning curve isn't quite that steep also ;)