I've got a 1969 Accutron that I got from my Dad. It eats a battery every 18-24 months. Most modern digital watches might manage to make a battery last 5-10 years...
I've had it fixed up, but I don't wear the watch that much any more because the strap is a total mess, and getting a replacement that looks similar to the original is nigh on impossible.
Bulova licensed the technology by the looks of things too - my folks have a nasty plastic 1970 wall clock which is still humming away - it has a huge version of the Bulova mechanism in a clear housing on the back of the clock.
Omega also made their own version (rather than licence Bulova's technology) back in the 60's or 70's. I can't remember the model name right now.
Just because a language (in this case Perl) allows the programmer to program which ever way they like, it doesn't mean that they should.
Ideally any large project, or better still any program should be planned and specified before one single line of code gets written.
Standards and specifications are exactly what forces programmers to code in a manner that can be understood by the rest of the team, and in many cases will make life easier for the said programmer.
In theory it should end up in a better final product - if the initial specification phase is done properly, then most problems should have already been thought of - all you've got to worry about now is the customer changing the goal posts for the third time this week:-)
I'm all for fully Unix/*BSD/Linux systems, including the desktop (although I still think MS Office, as much as I hate it is more user/idiot friendly than most offerings like StarOffice or KOffice).
A business running all *Nix actually not to hard to achieve now, provided that your business is the type that isn't heavily reliant on users who must use Office like their lives depend on it.
Unfortunately, most of the struggle is getting Linux/*BSD/Unix systems integrated with existing networks and programs - especially those which have been touched by Microsoft's embrace and extend philosophy, or run on a closed protocol, or use closed file formats.
Many businesses are not going to start from scratch with Linux/*BSD - and are more likely to want to move piecemeal away from Windows if they decide to do so.
As much as we'd all love Microsoft to open up their "standards" they know exactly what they're doing, and the anti-trust case doesn't look like it's going to help all that much.
It's a bit of a Catch 22 situation, and one with shifting goal posts - but easier integration with existing systems - with projects such as SAMBA and Ximians Vapourware Exchange plugin for Evolution might are the sort of thing to persuade PHB that moving to Linux/UNIX/*BSD is easier.
This post seems to be yet another anti-Microsoft rant - but in most cases these are the sorts of things that make life hard for people to shift their IT intrastructures - vendor lock-ins.
But yes, moving to Linux (or other free *Nixes) has probably never been easier.
Re:Why can't anyone see the implications of this?
on
This is IT?
·
· Score: 1
I really like the idea, and Kamen appears to be targetting a good marketplace - with companies like the US Postal service and FedEx, or anyone with big warehouses.
This is the thing that could make or break the Segway - another wise it could turn into just another Sinclair C5.
Remember those?
I hope that these things take off - but then again, if everyone was so concerned about turning a 30 minute walk into a 10 minute ride, why are the streets of the World not packed with bicycles (or electic bikes) like we see on the streets of Beijing?
Be aware that the IPChains support in the 2.4 kernels is only a compatiblity layer over the top of netfilter, and in some cases will not just allow you to drop in your existing IPChains ruleset
without doing some work.
Well, if you've got a few minutes on your hands, then taking a look at the stateful capabilities of IPTables/Netfilter over IPChains might be time well spent.
Be aware that the IPChains support in the 2.4 kernels is only a compatiblity layer over the top of netfilter, and in some cases will not just allow you to drop in your existing IPChains ruleset with some work.
I found it trival to rewrite my IPChains ruleset to use IPTables (including some stateful stuff) with the help of Rusty Russell's Unreliable Guides (as already mentioned: see netfilter.samba.org for everything worth knowing about Netfilter.)
I know this is question time more than discussion, however:
This is not the end of the stable series at all.
2.4.15 is where Linus has suggested he will hand maintainence of the kernel to Marcelo.
The 2.4 series is still the "stable" (cough) branch - and will continue on - just not directly under the guiding hand of Linus.
2.5 will be the development branch, and hopefully 2.4 will become even more stable with all the developers having 2.5 are their playground.
2.2 is there as an ultra-stable/slightly behind the times branch for those people who do not wish to move to the newer 2.4 branch just yet.
I suspect Alan Cox has just gone quiet with his -ac series kernels because of the work he's putting to getting his changes merged into the main Linus/Marcelo branch before 2.4.15.
I would be very surprised if Alan does not continue to use the -ac series as a testing ground for much code - especially drivers, before submitting it to Marcelo.
IIRC, this had been hinted at in Alan's diary or in LKML posts.
There are also the joys of well configured webcaches to think of.
What happens with Big Company Inc. and their 10000 employees accessing a handful of sites each day via a cluster of Squid machines?
The number of page loads that the servers at Small Webhost charge Big Company Inc wouldn't be in proportion to the number of pageviews the employees create.
Sure, Small Webhost aren't going to have to pay bandwidth charges on those pages, but surely this idea is not to cover only bandwidth/server charges but also the costs of authoring work on the site?
IMHO, most pay-per-view systems never seem to work to well.
If this system was to purely cover bandwidth, then yes, this _might_ work, since on many large sites most pages are much the same size.
There are bound to be problems tracking all of this though.
Anyone that can read C, or at least guess a little could surely use the source code/patches to figure out what has been done.
Is this demented reverse-engineering of Changelogs going to mean Alan Cox will not release the source code to the US now too?
IMHO, it's all a little out of hand for a UK citizen (although Tony Blair does tend to jump at US ideas - who knows when he'll decide to implement the DCMA over here in the UK:-)
Add a new chain - divert everything destined for port 80 down that chain, filter and hop back on your normal ruleset.
When it's time to clear up, delete the chain.
Easy.
Doesn't solve any speed issues, but it solves one problem.
All we need now is a rule to drop Micro$oft from the Planet.:-)
I can't believe that this sort of thing is happening.
It's a fairly obvious difference between cracking a system, and exploiting the problems found, and coming across a problem by accident and reporting them in a sensible manner.
Behaviour like this from clueless law enforcement bodies who obviously don't know the difference is not going to help any one - it will deter people from helping one another out, because you don't know how the other sysadmin/business will react, and also that the law cannot tell that the party with the problem is overreacting.
What ever happened to the whole global village ethos - you scratch my back (i.e. tell me when I need help) and I'll scratch yours?
Now it's "Ahhh! A cracker!" to everything, good or bad.
No offense, but have you actually installed a Microsoft patch?
None taken, and no, I can raise my hand and say I haven't installed a Microsoft patch.
However, my comment was not just aimed at Microsoft in this instance.
I'm well aware that Microsoft patches aren't exact the easiest of things to make the wee small hours the most fun you've ever had, and in that respect I could go back to my argument that the vendor needs to ensure that the code they release is up to scratch - people (admins especially) have to able to trust anything that goes anywhere near production machines.
However, it's reasonably safe to say that your average *nix/BSD update can be trusted a little more not to give too much heartache, and yet most exploits out there attack old, well known and usually long since solved issues - and those exploits succeed, because there are still one subset of admins that do not maintain their systems.
It's the irresponsible/lazy admins who just go and apply the MS patches when they come out without testing them first.
Yes, I agree, patching is not everything, and it takes time to apply changes to development and then live environments after the relevant testing can be carried out, hence other ways around problem can (and should) be used if possible.
This comes back to the admins knowing enough about their systems, and how everything interacts to be able to recognise and implement alternative solutions - the end result is still an improved/secured (as secure as is possible at that time) system.
IMO, you *have* to blame everyone involved - everything has to come together, from vendor to admin.
Once again, I've steered clear of the root cause - the crackers and worm/virus writers - it's a problem that will probably never be solved, much to my regret.
Full disclosure is a good thing - in theory.
I'm all for releasing the details of an exploit, but in a partial, then full manner.
I'm not sure if this is what happens in all cases, but many white-hats operate in the following manner:
Make the vendor aware of the full extent of the problem, to give them the information required to develop and test a patch.
After a grace period, the full exploit should be made public, partially to force/persuade the vendor to ensure that the patch is ready in due course, and also to educate the wider community.
Unfortunately the one thing that this system cannot do is convince lazy or inept sysadmins/users to patch their systems.
I can't comprehend the mentality that afflicts these people.
"we've discovered an easy way for the entire world to break into your bank account and take all your money - but if you call your friendly bank now, they'll give you an gold star to stick on your credit card that will stop all this."
Watch for the thousands of phone calls that the bank would get....
Compare with:
"Hi it's $FAVOURITE_SOFTWARE_VENDOR - your server will be cracked unless you install this patch, potentially costing you your customers trust, their custom and your money as your servers fold, not to mention the untold wrath of other sysadmins whos networks your cracked systems have been attacking..."
Barely half the people out there bother.
Yes, it might be possible to say that its the vendor's fault that the software isn't secure - after all all software should be perfect (yeap, I know Microsoft are really taking the piss on this one - closed source and poor security - and you have to pay for the honour to be a security hazard).
It's also possible to say that it's the cracker or virus/worm writers fault for attacking systems.
It's especially easy to say that it's the sysadmin (if they deserve the title) that can't patch a system up.
However, it's more of a combination of all three, and probably more reasons than I can think of.
Everyone needs to pull their fingers out of their behind, and do their own part.
The problems in the system need to ironed out before it hits the shelves, good coding, code audits and sensible defaults to name but a few things the vendor needs to do - not just for security, but stability and maintainability.
The admin/users need to learn their own systems at least enough to not screw everyone over if something does go wrong, and prevent things going wrong in the first place.
The virus writers and crackers?
Sorry, since I'm probably gonna be modded down, I had to make the title a little catchy:-)
The statement that "the internet is now the backbone of most computing" might be OK, but saying that because of that "that puts Microsoft at the centre (I'm a Brit:-) of all things digital" doesn't quite figure.
I seem to remember looking at the last Netcraft survey and seeing Apache (on whatever platform) pissing all over IIS and the like as far as number of hosts out there goes.
Yeap, I'm sure that something 0.1% of those Apache hosts are running Win32, but the general idea is that there are an awful lot of *BSD/*Nix hosts out there on the internet.
Not every device connecting to those servers are going to be M$ (or even Intel) powered - not every handheld/PDA, mobile phone, or new-fangled digital picture frame runs Windoze (CE/ME/XP/Whatever) - especially at the embedded end of things.
There are always going to be some folk that refuse/choose not to/cannot/should not run something that comes out of Redmond.
OK, so there hasn't been a great deal of progress in the development of common plugins for GNU/Linux - Quicktime for example (I personally don't care about Shockwave or Flash, but it would be nice to take away another reason for people not to use Linux), but is this system not going to suggest to developers to not bother with plugins for Linux, and just knock out Windoze versions, expecting every Linux user on the planet to get this Codeweavers code?
Progress is good, but I'd still rather see a Linux version of $PLUGIN, instead of a compatiblity layer to run the Windows version.
Plugins aren't exactly the be-all-and-end-all of OS use, but it's just a thought.
It might be an idea to visit ArsDigita.com and OpenACS.org.
ArsDigita have a system based on Oracle and AOLserver that forms the ArsDigita Community System (ACS). There is also a fully GPL'd version based on PostGreSQL and AOLserver know as OpenACS.
To quote from OpenACS.org:
OpenACS (Open ArsDigita Community System) is an advanced toolkit for building scalable, community-oriented web applications.
ArsDigita host a number of Q&A forums on web/db issues, Oracle administration and a host of other subjects - including their own training material.
The main thing about the ACS is collaboration.
And BTW, it is already being used as part of courses at MIT...
Obviously, this company hasn't heard the idea that 20% of your customers provide 80% of income.
If a company excludes 10% of a population they might just find a few problems...
This is a subject that always rattles my cage - the web was brought about to allow a vast number of people to communicate, and now certain companies are trying to push closed source and/or proprietary technologies, or worse still subvert existing crossplatform systems with proprietary "improvements" (yes, I mean you, Microsoft).
Taking this slightly too far - is this also not an infridgement on our freedom to choose? Why must I be expected to run a system built to support Microsoft protocols/systems?
There are still plenty of other systems that are not Microsoft - especially in the server market I don't expect (or at least I hope) that this is not the way of the future.
This post seems to come across as an anti-Microsoft rant. It's not supposed to be, however most of the examples of this behaviour that I'm aware of do seem to originate from Redmond.
Hopefully the growing number of Linux/*BSD and other "alternative" OS users will make Microsoft sit up and think.
Let me see...Carnivore sits at your ISP and intercepts everything you send; someone else could packet sniff your connection, your sysadmin might have proxies in place...
Now, Yahoo recieves your email in cleartext, from you, through your ISP and only then encrypts it, to be sent on, and is collected by the recipient via SSL.
Why not go the whole hog and provide SSL from you to the Yahoo servers?
Call me crazy, but I see little benefit to these partially secured systems.
A system is only as secure as it's weakest link - and in this case there is a point where cleartext messages are transmitted by the system.
Is this truely the great innovation it's supposed to be? Yes, it will open up crypographic email to many people, but these are probably the same people that do not appreiciate the issues involved, and might blindly trust a system with what appear to be obvious shortfalls.
Guess I should add more info to bump up the karma:-)
Fieldpoint consists of a number of modules connected to a central PC.
There are a number of different modules including:
Network modules (RS-232/485, Ethernet, FieldBus plus option for wireless modem)
Analogue input (12 and 16 bit) and output
Digital input and output
Relay modules
Thermocouple input
And so on. Extremely tough Distributed DAQ or I/O solution - obviously more expensive than breaking out your soldering iron, but then again, you don't need to spend the rest of you life figuring how to do it all:-)
Try National Instruments FieldPoint system. It's a rugged distributed I/O system with wireless, serial, ethernet and Fieldbus options.
Look at the Fieldpoint section on NI's site
Yeap, you guessed it, I work for National Instruments:-)
Seriously though, there are some very interesting options with the NI gear.
Everyone seems really concerned that they might be blocking valid IP addresses if they trust this new site (when it ever comes back up).
Running a default policy of DENY will sort any hassle...(accept of course trying to access your server:-)
I hope everyone knows where they expect connections to be coming from, and if not, have hardened up those boxen!
OK, admittedly, you Slashdot maniacs shouldn`t be allowed to broadcast...:-) Mad!!! But funny!! I think you should make more of an effort to promote this craziness.
Slashdot Mirror
Posting bandwidth usage figures on your website is just asking everyone to click "reload" on their browsers as many times as possible :-)
Check out the top of each page:
You're not wrong about the battery usage.
I've got a 1969 Accutron that I got from my Dad. It eats a battery every 18-24 months. Most modern digital watches might manage to make a battery last 5-10 years...
I've had it fixed up, but I don't wear the watch that much any more because the strap is a total mess, and getting a replacement that looks similar to the original is nigh on impossible.
Bulova licensed the technology by the looks of things too - my folks have a nasty plastic 1970 wall clock which is still humming away - it has a huge version of the Bulova mechanism in a clear housing on the back of the clock.
Omega also made their own version (rather than licence Bulova's technology) back in the 60's or 70's. I can't remember the model name right now.
Just because a language (in this case Perl) allows the programmer to program which ever way they like, it doesn't mean that they should.
Ideally any large project, or better still any program should be planned and specified before one single line of code gets written.
Standards and specifications are exactly what forces programmers to code in a manner that can be understood by the rest of the team, and in many cases will make life easier for the said programmer.
In theory it should end up in a better final product - if the initial specification phase is done properly, then most problems should have already been thought of - all you've got to worry about now is the customer changing the goal posts for the third time this week :-)
I'm all for fully Unix/*BSD/Linux systems, including the desktop (although I still think MS Office, as much as I hate it is more user/idiot friendly than most offerings like StarOffice or KOffice).
A business running all *Nix actually not to hard to achieve now, provided that your business is the type that isn't heavily reliant on users who must use Office like their lives depend on it.
Unfortunately, most of the struggle is getting Linux/*BSD/Unix systems integrated with existing networks and programs - especially those which have been touched by Microsoft's embrace and extend philosophy, or run on a closed protocol, or use closed file formats.
Many businesses are not going to start from scratch with Linux/*BSD - and are more likely to want to move piecemeal away from Windows if they decide to do so.
As much as we'd all love Microsoft to open up their "standards" they know exactly what they're doing, and the anti-trust case doesn't look like it's going to help all that much.
It's a bit of a Catch 22 situation, and one with shifting goal posts - but easier integration with existing systems - with projects such as SAMBA and Ximians Vapourware Exchange plugin for Evolution might are the sort of thing to persuade PHB that moving to Linux/UNIX/*BSD is easier.
This post seems to be yet another anti-Microsoft rant - but in most cases these are the sorts of things that make life hard for people to shift their IT intrastructures - vendor lock-ins.
But yes, moving to Linux (or other free *Nixes) has probably never been easier.
I really like the idea, and Kamen appears to be targetting a good marketplace - with companies like the US Postal service and FedEx, or anyone with big warehouses.
This is the thing that could make or break the Segway - another wise it could turn into just another Sinclair C5.
Remember those? I hope that these things take off - but then again, if everyone was so concerned about turning a 30 minute walk into a 10 minute ride, why are the streets of the World not packed with bicycles (or electic bikes) like we see on the streets of Beijing?
Patches are here at kernel.org, but no READMEs.
You might also want to look at the kernel/crypto directory also at kernel.org.
There is also a pointer to cryptoapi.sourceforge.net
Slight mistake - should read:
Why bother?
Well, if you've got a few minutes on your hands, then taking a look at the stateful capabilities of IPTables/Netfilter over IPChains might be time well spent.
Be aware that the IPChains support in the 2.4 kernels is only a compatiblity layer over the top of netfilter, and in some cases will not just allow you to drop in your existing IPChains ruleset with some work.
I found it trival to rewrite my IPChains ruleset to use IPTables (including some stateful stuff) with the help of Rusty Russell's Unreliable Guides (as already mentioned: see netfilter.samba.org for everything worth knowing about Netfilter.)
man iptable is your friend.
I know this is question time more than discussion, however:
This is not the end of the stable series at all.
2.4.15 is where Linus has suggested he will hand maintainence of the kernel to Marcelo.
The 2.4 series is still the "stable" (cough) branch - and will continue on - just not directly under the guiding hand of Linus.
2.5 will be the development branch, and hopefully 2.4 will become even more stable with all the developers having 2.5 are their playground.
2.2 is there as an ultra-stable/slightly behind the times branch for those people who do not wish to move to the newer 2.4 branch just yet.
I suspect Alan Cox has just gone quiet with his -ac series kernels because of the work he's putting to getting his changes merged into the main Linus/Marcelo branch before 2.4.15.
I would be very surprised if Alan does not continue to use the -ac series as a testing ground for much code - especially drivers, before submitting it to Marcelo.
IIRC, this had been hinted at in Alan's diary or in LKML posts.
Cheers.
There are also the joys of well configured webcaches to think of.
:-)
What happens with Big Company Inc. and their 10000 employees accessing a handful of sites each day via a cluster of Squid machines?
The number of page loads that the servers at Small Webhost charge Big Company Inc wouldn't be in proportion to the number of pageviews the employees create.
Sure, Small Webhost aren't going to have to pay bandwidth charges on those pages, but surely this idea is not to cover only bandwidth/server charges but also the costs of authoring work on the site?
IMHO, most pay-per-view systems never seem to work to well.
If this system was to purely cover bandwidth, then yes, this _might_ work, since on many large sites most pages are much the same size.
There are bound to be problems tracking all of this though.
Just my 2p. ($0.02 for the US
Anyone that can read C, or at least guess a little could surely use the source code/patches to figure out what has been done.
Is this demented reverse-engineering of Changelogs going to mean Alan Cox will not release the source code to the US now too?
IMHO, it's all a little out of hand for a UK citizen (although Tony Blair does tend to jump at US ideas - who knows when he'll decide to implement the DCMA over here in the UK :-)
Add a new chain - divert everything destined for port 80 down that chain, filter and hop back on your normal ruleset. When it's time to clear up, delete the chain.
Easy.
Doesn't solve any speed issues, but it solves one problem.
All we need now is a rule to drop Micro$oft from the Planet. :-)
I can't believe that this sort of thing is happening.
It's a fairly obvious difference between cracking a system, and exploiting the problems found, and coming across a problem by accident and reporting them in a sensible manner.
Behaviour like this from clueless law enforcement bodies who obviously don't know the difference is not going to help any one - it will deter people from helping one another out, because you don't know how the other sysadmin/business will react, and also that the law cannot tell that the party with the problem is overreacting.
What ever happened to the whole global village ethos - you scratch my back (i.e. tell me when I need help) and I'll scratch yours?
Now it's "Ahhh! A cracker!" to everything, good or bad.
None taken, and no, I can raise my hand and say I haven't installed a Microsoft patch.
However, my comment was not just aimed at Microsoft in this instance. I'm well aware that Microsoft patches aren't exact the easiest of things to make the wee small hours the most fun you've ever had, and in that respect I could go back to my argument that the vendor needs to ensure that the code they release is up to scratch - people (admins especially) have to able to trust anything that goes anywhere near production machines.
However, it's reasonably safe to say that your average *nix/BSD update can be trusted a little more not to give too much heartache, and yet most exploits out there attack old, well known and usually long since solved issues - and those exploits succeed, because there are still one subset of admins that do not maintain their systems.
Yes, I agree, patching is not everything, and it takes time to apply changes to development and then live environments after the relevant testing can be carried out, hence other ways around problem can (and should) be used if possible.
This comes back to the admins knowing enough about their systems, and how everything interacts to be able to recognise and implement alternative solutions - the end result is still an improved/secured (as secure as is possible at that time) system.
IMO, you *have* to blame everyone involved - everything has to come together, from vendor to admin.
Once again, I've steered clear of the root cause - the crackers and worm/virus writers - it's a problem that will probably never be solved, much to my regret.
Full disclosure is a good thing - in theory. I'm all for releasing the details of an exploit, but in a partial, then full manner. I'm not sure if this is what happens in all cases, but many white-hats operate in the following manner:
Unfortunately the one thing that this system cannot do is convince lazy or inept sysadmins/users to patch their systems.
I can't comprehend the mentality that afflicts these people.
Watch for the thousands of phone calls that the bank would get....
Compare with:
Barely half the people out there bother.
Yes, it might be possible to say that its the vendor's fault that the software isn't secure - after all all software should be perfect (yeap, I know Microsoft are really taking the piss on this one - closed source and poor security - and you have to pay for the honour to be a security hazard). It's also possible to say that it's the cracker or virus/worm writers fault for attacking systems. It's especially easy to say that it's the sysadmin (if they deserve the title) that can't patch a system up.
However, it's more of a combination of all three, and probably more reasons than I can think of. Everyone needs to pull their fingers out of their behind, and do their own part.
The problems in the system need to ironed out before it hits the shelves, good coding, code audits and sensible defaults to name but a few things the vendor needs to do - not just for security, but stability and maintainability. The admin/users need to learn their own systems at least enough to not screw everyone over if something does go wrong, and prevent things going wrong in the first place. The virus writers and crackers?
Hell, I can't think of everything.
Sorry, since I'm probably gonna be modded down, I had to make the title a little catchy :-)
:-) of all things digital" doesn't quite figure.
The statement that "the internet is now the backbone of most computing" might be OK, but saying that because of that "that puts Microsoft at the centre (I'm a Brit
I seem to remember looking at the last Netcraft survey and seeing Apache (on whatever platform) pissing all over IIS and the like as far as number of hosts out there goes.
Yeap, I'm sure that something 0.1% of those Apache hosts are running Win32, but the general idea is that there are an awful lot of *BSD/*Nix hosts out there on the internet.
Not every device connecting to those servers are going to be M$ (or even Intel) powered - not every handheld/PDA, mobile phone, or new-fangled digital picture frame runs Windoze (CE/ME/XP/Whatever) - especially at the embedded end of things.
There are always going to be some folk that refuse/choose not to/cannot/should not run something that comes out of Redmond.
Just my 2p/$0.02
OK, so there hasn't been a great deal of progress in the development of common plugins for GNU/Linux - Quicktime for example (I personally don't care about Shockwave or Flash, but it would be nice to take away another reason for people not to use Linux), but is this system not going to suggest to developers to not bother with plugins for Linux, and just knock out Windoze versions, expecting every Linux user on the planet to get this Codeweavers code?
Progress is good, but I'd still rather see a Linux version of $PLUGIN, instead of a compatiblity layer to run the Windows version.
Plugins aren't exactly the be-all-and-end-all of OS use, but it's just a thought.
ArsDigita have a system based on Oracle and AOLserver that forms the ArsDigita Community System (ACS). There is also a fully GPL'd version based on PostGreSQL and AOLserver know as OpenACS.
To quote from OpenACS.org: ArsDigita host a number of Q&A forums on web/db issues, Oracle administration and a host of other subjects - including their own training material.
The main thing about the ACS is collaboration. And BTW, it is already being used as part of courses at MIT...
Obviously, this company hasn't heard the idea that 20% of your customers provide 80% of income.
If a company excludes 10% of a population they might just find a few problems...
This is a subject that always rattles my cage - the web was brought about to allow a vast number of people to communicate, and now certain companies are trying to push closed source and/or proprietary technologies, or worse still subvert existing crossplatform systems with proprietary "improvements" (yes, I mean you, Microsoft).
Taking this slightly too far - is this also not an infridgement on our freedom to choose? Why must I be expected to run a system built to support Microsoft protocols/systems?
There are still plenty of other systems that are not Microsoft - especially in the server market I don't expect (or at least I hope) that this is not the way of the future.
This post seems to come across as an anti-Microsoft rant. It's not supposed to be, however most of the examples of this behaviour that I'm aware of do seem to originate from Redmond.
Hopefully the growing number of Linux/*BSD and other "alternative" OS users will make Microsoft sit up and think.
Let me see...Carnivore sits at your ISP and intercepts everything you send; someone else could packet sniff your connection, your sysadmin might have proxies in place...
Now, Yahoo recieves your email in cleartext, from you, through your ISP and only then encrypts it, to be sent on, and is collected by the recipient via SSL.
Why not go the whole hog and provide SSL from you to the Yahoo servers?
Call me crazy, but I see little benefit to these partially secured systems.
A system is only as secure as it's weakest link - and in this case there is a point where cleartext messages are transmitted by the system.
Is this truely the great innovation it's supposed to be? Yes, it will open up crypographic email to many people, but these are probably the same people that do not appreiciate the issues involved, and might blindly trust a system with what appear to be obvious shortfalls.
Fieldpoint consists of a number of modules connected to a central PC.
There are a number of different modules including:
And so on. Extremely tough Distributed DAQ or I/O solution - obviously more expensive than breaking out your soldering iron, but then again, you don't need to spend the rest of you life figuring how to do it all
Try National Instruments FieldPoint system. It's a rugged distributed I/O system with wireless, serial, ethernet and Fieldbus options.
:-)
Look at the Fieldpoint section on NI's site
Yeap, you guessed it, I work for National Instruments
Seriously though, there are some very interesting options with the NI gear.
Everyone seems really concerned that they might be blocking valid IP addresses if they trust this new site (when it ever comes back up). :-)
Running a default policy of DENY will sort any hassle...(accept of course trying to access your server
I hope everyone knows where they expect connections to be coming from, and if not, have hardened up those boxen!
OK, admittedly, you Slashdot maniacs shouldn`t be allowed to broadcast... :-) Mad!!! But funny!!
I think you should make more of an effort to promote this craziness.