Isn't that was HTTP persistent connections are for?
Despite persistent connections you usually find browsers will open multiple TCP streams at once and get a number of objects in parallel. You could use a single SCTP association with several streams to do this, and the server would have more control over how many objects a single client should request in parallel.
However, I think the main advantage for many protocols, HTTP included, is the preservation of datagram boundaries. Rather than having to delimit and parse each header you just send each header as a separate datagram and it arrives at the other end still in separate datagrams so you can just read each header individually. It may not seem like a big deal when we already have things like HTTP running over a streaming protocol, but it would certainly simplify the implementation. How many protocols run over TCP streams would be better suited to reliable (and optionally ordered) datagrams rather than byte streams? I would say a lot. Basically anything which currently has to delimit chunks of data in order to parse it at the other end is better suited to datagrams rather than byte streams.
but it is too easy for 99% of the world to just open 2 sockets if you want 2 streams, or rpc's and threads... both of which are well supported and seasoned.
Except that doing NAT traversal is a pain in the arse so if you're having to traverse NATs (which most IPv4 peer-to-peer stuff needs to) then you may as well only do it once and then use the same connection ("association" in SCTP speak) for everything.
Also, there is a certain amount of overhead (time) required to set up a TCP connection. If you already have an SCTP association it's fast to use the multi-streaming support.
Another advantage is that SCTP has a much less abusable handshake system - it eliminates the SYN flood vulnerability that TCP has (which has only partly been mitegated through the introduction of TCP SYN cookies).
Sctp is new, new bugs, not supported everywhere and as a result will go not go far.
Not really new - it's been in use in major telephony networks for years. However, you're right that it isn't supported everywhere - typically, native support in Windows is years away... exactly as it's been for every other networking protocol (remember that IPv6 didn't appear in Windows until XP whereas everyone else had supported it for years previously... and IPv4 didn't appear until Windows 95 but everyone else had supported it for years previously. Microsoft originally wrote off the Internet as a fad and refused to put development time into supporting it.)
In the future there will no need for a central office, all calls will NOT route through central servers and thus negate a heavy need for sctp altogether! sctp is like a T1-T2-Txxx to sockets, allowing n channels of calls through one IP connection. If VoIP (not strictly defined) goes point to point direct there is no need for a central office. End user devices only need 1 to 4 channels. (Audio/Video/Control/MP3 Movies).
I can't see that doing peer-to-peer VoIP negates the need for SCTP.
1. SCTP provides reliable ordered datagram delivery - this is something required for signalling between nodes participating in the call (whether they be a central office or two peers). You can do it over TCP but that means you have to put in your own datagram delimiters. For example, SIP (much like HTTP) sends "datagrams" as lines of ASCII with each datagram delimited by \r\n. SIP (and indeed HTTP, and many other protocols) would benefit from the protocol not destroying datagram boundaries so that they didn't need to delimit the datagrams themselves.
2. SCTP provides an unordered datagram delivery - this is required for passing real time traffic (voice, video, etc). RTP over UDP is commonly used for this purpose but it makes more sense to build this functionality into the transport protocol itself since it's a commonly used feature.
3. Just because you don't need hundreds of streams doesn't negate the usefulness of the multi-stream support. And I think you underestimate what streams could be used for peer-to-peer phone calls: signalling, voice, video, application sharing (think NetMeeting style stuff, and you could well have multiple applications all using separate streams at once), electronic whiteboard, etc. Even stuff like SSH could benefit from this, allowing you to tunnel several connections in separate streams.
4. Explicit multihoming support would benefit a lot of applications, not just telephony (although I question whether this should be addressed in IP itself rather than a transport layer protocol)
I agree with you that the future of telephony is largely peer-to-peer, I still believe there will me large "central offices" running services. For example, in the same way as most people rely on their ISP to hold on to incoming mail when they're offline, many will probably rely on their ISP (or some other service provider) to do their voicemail, etc. Also, I don't expect businesses to stop having central PABXs and they qualify as potentially large central offices (and in a large organisation with a large number of offices it's quite likely that there will be several inter-connected PABX systems).
*disclaimer: I work in SS7 and SCTP software development.
So I am wondering if after this, in US, Skype would introduce such "anti reverse engineering" clause in the agreements.
It's probably already in the EULA - most EULAs have a clause outright banning reverse engineering. The point is that in the EU it is unenforcable if you're reverse engineering for interoperability purposes because that's an explicit permission given by the law that cannot be revoked by a licence.
Reverse-engineering things not a violation of the DMCA if done for interoperability.
I'm sure the authorities will say different if you reverse engineer the DRM on BluRay discs of HDCP in order to make them interoperable with open systems.
A lot of companies have a clause in the EUA that the user may not reverse compile or reverse engineer the binaries.
In the EU at least, reverse engineering *for interoperability purposes* is a legal entitlement that can't be revoked by any licence agreement. Dunno how it works in the US though. (I also suspect that the EUCD overrides this entitlement since otherwise you'd be able to get away with cracking the DRM on bluray discs to make your open source player interoperable with them:)
If those trhings wre spinning clos to c as the poster suggest, and they flew appart, there is no place on earth far enough away to protect from the resulting effect.
Well the bits would fly off at a tangent, so assuming you were above or below the plane of the disc you would probably be ok...
OTTH (On the third hand...) if your skin is sweaty, it conducts a lot better than when it is dry. Enough better that enough current flows to dissipate enough power to heat your skin past the point where you suffer burns. Or worse.
AFAIK even wet skin isn't conductive enough for you to get a serious shock off a 48v potential. Remember that the amount of current that _can_ be delivered by the supply is completely irrelevent if the load isn't low enough resistance to draw that current. In the case of your body, the resistance is high enough that you won't draw much current at 48v. Slapping a big conductor across the power rails such as a screw driver OTOH, will happilly max out whatever current the PSU will supply (until it melts).
although you can arc weld a screwdriver with it - melted metal==ouch
Well that's more about current - most 48v supplies are capable of delivering quite high currents (lower voltage == higher current for the same wattage). So whacking a big conductor across the circuit like a screwdriver means you'll get a massive current compared to most high voltage supplies (which would've blown a fuse for similar currents).
OTOH your body is not a great conductor so the fact there is a higher current available doesn't matter since it doesn't have the voltage required to pass through you.
The major inconvenience is you just can't send it through a transformer.
Less of a problem these days - most modern electronics use switched mode PSUs because they're cheaper, lighter and more efficient.
Yes, DC is better for a local area, until you need it at a different voltage than it was delivered at. Then AC starts to be better. And how many sites use the same voltage everywhere? Sweet FA. For example a PC uses 12v, 5v and more. A TV uses from about 25Kv to 5 volt. etc. etc.
Low frequency (50-60Hz) AC sucks only slightly less than DC for voltage conversion. You need big bulky inductors and capacitors. Which is why all the stuff you just mentioned rectifies the 50-60Hz AC and then uses an oscillator to generate a much higher frequency AC for stepping up and down (KHz or even MHz).
Of course very high frequency signals suffer really badly from transmission loss so you don't want to use them over any distance, so using DC for distribution in a local area is a good plan - especially if you can reduce losses by running it at a high voltage (but not high enough to kill you - e.g. 48 volts is a good compromise).
A 300W PC power supply at 63% efficiency has about 475W input, which means 175W loss. 175W would turn it into a crispy critter--more heat than a high end CPU, with less effective heat removal.
Efficiency in most PSUs increases as you increase the amount of power you're drawing. So whilest it may be 90% efficient when pulling the full 300W, it's probably only 70% when you're pulling 150W. Most machines don't spend the majority of their lives maxing out the PSU.
If every person in China spun up such a disk at the same time, it might affect the position of the North Star or change the length of the day.
The solution there is to spin up 50% of them clockwise and 50% anticlockwise so the torque cancels itself out. But moving them would likley be an almighty PITA given the gyroscopic effects of that much mass spinning at relativistic speeds, not to mention the problems of building bearings that will run that fast for any length of time without wearing or overheating. And I'd rather not be anywhere near that thing when it fails and flies apart.
They just claim Vonage takes up too much bandwidth and therefore violates the Terms of Service agreement that says they alone determine who or what is using up too much bandwidth and causing problems on their network.
GSM compressed VoIP takes up at most 13Kbps. I can't see that they can get away with blocking such a low bandwidth application on the grounds that it uses up too much bandwidth.
Whoever is sitting on the near-earth passing asteroid is in fact in command of weapon similar to clean nuke.
How exactly are you going to change the orbit of a few million tons of iron significantly enough to hit the Earth, let alone be able to aim the thing at a particular location?
lol every reply against him makes it all the more obvious how not ready for average users linux is. and truely a nightmare for tech support. sometimes..u gotta realize not everyone is a geek. yea really u know
Please tell me which bit of my reply tells you Linux isn't ready for average users? The only thing I can see there that could be a problem is that users get a _choice_ as to whether to use the commandline or the GUI. I guess choice is confusing for some people, far better to force everyone into doing things in a particular way even if they don't like it.
I think there are 2 stumbling blocks that stop Linux being ready for the average user: 1. Lack of hardware support - this is getting better, but still if you don't buy the right hardware you're screwed. I'm not sure what can be done about this short of encouraging binary drivers (and this would be a very bad thing for stability) 2. People can't buy $random_software from PC World and install it. That's because most software companies only publish for Windows (to a lesser extent, Mac users have the same problem). FWIW, if you look around you can usually find an alternative piece of software (often free), but the average user would prefer to hand over a bundle of cash and buy a boxed application.
But given a choice, despite all my frustrations with Windows, I simply find Windows easier to use in a number of ways.
Having recently had to start using Windows after 5 years of not touching it, I can tell you that Windows is *exceptionally* unusable from my point of view. It's just nowhere near as userfriendly and capable as Linux.
On the other hand, with Linux, you usually have to get the executeable for your specific CPU if not your CPU and flavor of Linux
Yes, whereas Windows is far better because it only supports 1 type of CPU (x86)... I'm not sure what you're complaining about here - of course you can't run a program on an incompatable CPU, nomatter what OS you're using.
ease of finding apps, ease of installing said apps.
Yes, I too find typing "yum install foo" very taxing... no wait, I don't...
MPlayer, for example: An app for watching movies, is command-line.
Mplayer comes in both commandline and GUI versions. You can't tell me that giving the user a choice of whether they want to use the GUI or CLI is a bad thing.
I for one make a lot of use of the command line version.
but why don't they just include one so I don't go have to find one
They do - I get gmplayer installed with mplayer.
Most of the time I use the commandline version directly, on the odd occasion that I actually want to use a GUI version I tend to use Xine though.
Most non-tech users don't even know Windows has a command line. They don't need to know. That's a good thing.
I'm sorry, I can't see how you can complain about this stuff - if you install something that's designed to run from the commandline you can't complain that it runs from the commandline - if you wanted a program that runs from the GUI you damned well should've installed one instead.
Also, if Joe Sixpack makes a mistake and selects his neighbor's unsecured "linksys" (and sets it as default) rather than his own unsecured "linksys" should he be arrested?
It doesn't even need to be the user's mistake - if you tell a client to associate with your access point with SSID "linksys", it'll happilly associate with any access point with the SSID "linksys" (which will almost certainly hand out a DHCP lease too) without the user doing *anything*. This is of course how 802.11 roaming works.
Is it sane to arrest someone because a feature that's present in every piece of 802.11 hardware has automatically done what was intended?
If anyone should be held responsible for people associating with open access points it surely should be the person who set up the thing in the first place and maybe the AP manufacturer for making it easy (or even default) to set up an open network. There are uses for open access points, but the vast majority of people really don't want one so you should really have to look for the buttons to turn _off_ the encryption rather than it defaulting that way.
If a car manufacturer started shipping cars with no locks because "it's easier for the customer to use" then I'm sure there'd be hell to pay.
It becomes de facto prohibited because it leaves any law-abiding person in sufficient doubt to not do it.
Extending the analogy a bit, what if some non-free software "accidentally" came with free licences? Would the authorities be expected to protect the software publishers by arresting anyone exercising the rights that licence gives them? If so, would it then be ok for free software to be defacto-banned because noone knows which software is really free?
I can't understand how using a network that's *broadcasting* *invitations* can possibly be considered unauthorised. If the network owner didn't want to authorise your access then they damned well shouldn't have configured their access point to invite everyone to use it. Are we going to extend this interpretation of the law to prevent pwople from accessing *any* public network services? if not, why not?
I'm well aware that people have been jailed for unauthorised use of open APs, but my questions are: 1. If using a device that is actively broadcasting invitations for the public to use it is considered "unauthorised", surely it would be considered even more unauthorised if you were to go out of your way and actually probe a service to see if it's there (this is the case whenever you access any web server). 2. How is the user to know whether an open access point is supposed to be open or not? Shouldn't it be up to the owner of the access point to prevent it from inviting the public to use it? If I were to leave the door to my house open and hang a pub sign on the front, should I _really_ complain when someone comes in looking for a drink? Do I have the right to throw that person in jail? I'd argue not.
This isn't a question about network security - this is simply a question of how the defendent is supposed to _know_ whether they were authorised to use the access point.
The computer misuse act is rather fuzzy when it comes to "unauthorised use" - it rather predates the notion of public network servers. What constitutes "unauthorised use"?
I.e. if you're running a publically accessible web server and I connect my browser to it, is that "unauthorised use"? You haven't given me written permission to use your web server. Lets say you argue that publically accessible web servers are obviously authorised, otherwise you'd have to get permission from every webmaster before visiting their site - what if someone leaves their DSL router's web based administration page accessible to the internet? Does accessing that constitute unauthorised access? How were you to know that it wasn't a web server you were allowed to access before you actually accessed it?
Under a strict interpretation of the law it seems that it's illegal to access any computer without prior permission, which kinda outlaws most of the internet.
So far I've talked about network servers where you have to actively go out of your way to connect to them to discover if they are really public servers. What about open 802.11 networks? They actively _advertise_ the fact that they are public access points and there's no way to tell the difference between a real public AP and someone's home AP that's been set up by a complete moron. So is using a system that is actively inviting you to use it considered unauthorised? I would've thought that broadcast advertisements constitute authorisation.
The laws certainly need to catch up with modern technology, clearly if someone has firewalled off a service or encrypted their 802.11 network then you shouldn't be using it. However, I'm not sure what you can do to protect people who are stupid enough to leave their networks open without legislation killing off legitimate services - how do you legislate that people shouldn't use accidentally open access points without killing legitimately open access points at the same time?
incorrect. copies of software are sold, not licensed. this is established by precedent.
Can you provide a link to the precident?
If you really have been sold the software, rather than a licence to use it this would mean you didn't need to agree to a licence in order to use the software. Like it or not, EULAs have been shown to be legally enforcable by precident.
Actually, in this case, you're really only paying for support.
From a strictly technical point of view you're right. But in reality you are _effectively_ selling the software as well since it's bundled with the support - you can't get the support without the software, they are a package.
Similarly, selling FireFox on CDs you're _technically_ selling the media and the work involved in burning the CD, but for all intents and purposes you're effectively selling the software, media and service - they are bundled together, you can't buy the media and copying service without the software.
It's really just understanding how the masses view the transaction. How many times have you heard someone say something like "I've bought Microsoft Office"? They haven't, they've bought an aluminium and plastic disc, a cardboard box and a _licence_ to use the software. In the MS Office case, the licence you just bought may even be completely worthless to you as it may contain a clause that prevents you from using the software (since you can't view the licence until you've bought it). But from the perspective of most end users they have bought the software - they don't care about the legal technicalities.
Same goes for music and videos, etc. This is partly why many people get confused and angry about what they're allowed to do with stuff - as far as they're concerned when they bought a CD, they bought the actual music on it and don't see why they shouldn't be allowed to listen to it on their iPod. Infact they bought a licence to use the music in a certain way and that licence forbids them from using it how they want.
Whether or not you should be _required_ to agree the a licence (that you probably haven't seen) before you can use the content you've paid for, and whether that licence should be able to restrict your fair use rights, etc. are of course other matters open to debate.
Practically, though, GPL software can only be distributed for free, as there's nothing stopping someone who buys a copy of the software from turning around and giving it away for free to everyone else.
I think people like Red Hat, SUSE, etc would disagree with you to some extent. If you buy RHEL you get software _and_ support for a certain amount of cash. Much of the software is free but it is essentially being sold by being bundled with the support (and guaranteed future updates).
You can do this now. If you have a windows based mobile phone you can use skype.
Why would you want to do Skype? You could use SIP, which is the industry standard protocol rather than using a propriatory system. That way you could call anyone else who uses SIP without needing to involve a third-party "service provider" and you get to choose which PSTN gateway you use if you want to call someone on the PSTN.
Slashdot Mirror
Isn't that was HTTP persistent connections are for?
Despite persistent connections you usually find browsers will open multiple TCP streams at once and get a number of objects in parallel. You could use a single SCTP association with several streams to do this, and the server would have more control over how many objects a single client should request in parallel.
However, I think the main advantage for many protocols, HTTP included, is the preservation of datagram boundaries. Rather than having to delimit and parse each header you just send each header as a separate datagram and it arrives at the other end still in separate datagrams so you can just read each header individually. It may not seem like a big deal when we already have things like HTTP running over a streaming protocol, but it would certainly simplify the implementation. How many protocols run over TCP streams would be better suited to reliable (and optionally ordered) datagrams rather than byte streams? I would say a lot. Basically anything which currently has to delimit chunks of data in order to parse it at the other end is better suited to datagrams rather than byte streams.
but it is too easy for 99% of the world to just open 2 sockets if you want 2 streams, or rpc's and threads... both of which are well supported and seasoned.
Except that doing NAT traversal is a pain in the arse so if you're having to traverse NATs (which most IPv4 peer-to-peer stuff needs to) then you may as well only do it once and then use the same connection ("association" in SCTP speak) for everything.
Also, there is a certain amount of overhead (time) required to set up a TCP connection. If you already have an SCTP association it's fast to use the multi-streaming support.
Another advantage is that SCTP has a much less abusable handshake system - it eliminates the SYN flood vulnerability that TCP has (which has only partly been mitegated through the introduction of TCP SYN cookies).
Sctp is new, new bugs, not supported everywhere and as a result will go not go far.
Not really new - it's been in use in major telephony networks for years. However, you're right that it isn't supported everywhere - typically, native support in Windows is years away... exactly as it's been for every other networking protocol (remember that IPv6 didn't appear in Windows until XP whereas everyone else had supported it for years previously... and IPv4 didn't appear until Windows 95 but everyone else had supported it for years previously. Microsoft originally wrote off the Internet as a fad and refused to put development time into supporting it.)
In the future there will no need for a central office, all calls will NOT route through central servers and thus negate a heavy need for sctp altogether! sctp is like a T1-T2-Txxx to sockets, allowing n channels of calls through one IP connection. If VoIP (not strictly defined) goes point to point direct there is no need for a central office. End user devices only need 1 to 4 channels. (Audio/Video/Control/MP3 Movies).
I can't see that doing peer-to-peer VoIP negates the need for SCTP.
1. SCTP provides reliable ordered datagram delivery - this is something required for signalling between nodes participating in the call (whether they be a central office or two peers). You can do it over TCP but that means you have to put in your own datagram delimiters. For example, SIP (much like HTTP) sends "datagrams" as lines of ASCII with each datagram delimited by \r\n. SIP (and indeed HTTP, and many other protocols) would benefit from the protocol not destroying datagram boundaries so that they didn't need to delimit the datagrams themselves.
2. SCTP provides an unordered datagram delivery - this is required for passing real time traffic (voice, video, etc). RTP over UDP is commonly used for this purpose but it makes more sense to build this functionality into the transport protocol itself since it's a commonly used feature.
3. Just because you don't need hundreds of streams doesn't negate the usefulness of the multi-stream support. And I think you underestimate what streams could be used for peer-to-peer phone calls: signalling, voice, video, application sharing (think NetMeeting style stuff, and you could well have multiple applications all using separate streams at once), electronic whiteboard, etc. Even stuff like SSH could benefit from this, allowing you to tunnel several connections in separate streams.
4. Explicit multihoming support would benefit a lot of applications, not just telephony (although I question whether this should be addressed in IP itself rather than a transport layer protocol)
I agree with you that the future of telephony is largely peer-to-peer, I still believe there will me large "central offices" running services. For example, in the same way as most people rely on their ISP to hold on to incoming mail when they're offline, many will probably rely on their ISP (or some other service provider) to do their voicemail, etc. Also, I don't expect businesses to stop having central PABXs and they qualify as potentially large central offices (and in a large organisation with a large number of offices it's quite likely that there will be several inter-connected PABX systems).
*disclaimer: I work in SS7 and SCTP software development.
So I am wondering if after this, in US, Skype would introduce such "anti reverse engineering" clause in the agreements.
It's probably already in the EULA - most EULAs have a clause outright banning reverse engineering. The point is that in the EU it is unenforcable if you're reverse engineering for interoperability purposes because that's an explicit permission given by the law that cannot be revoked by a licence.
Reverse-engineering things not a violation of the DMCA if done for interoperability.
I'm sure the authorities will say different if you reverse engineer the DRM on BluRay discs of HDCP in order to make them interoperable with open systems.
A lot of companies have a clause in the EUA that the user may not reverse compile or reverse engineer the binaries.
:)
In the EU at least, reverse engineering *for interoperability purposes* is a legal entitlement that can't be revoked by any licence agreement. Dunno how it works in the US though. (I also suspect that the EUCD overrides this entitlement since otherwise you'd be able to get away with cracking the DRM on bluray discs to make your open source player interoperable with them
If those trhings wre spinning clos to c as the poster suggest, and they flew appart, there is no place on earth far enough away to protect from the resulting effect.
Well the bits would fly off at a tangent, so assuming you were above or below the plane of the disc you would probably be ok...
OTTH (On the third hand...) if your skin is sweaty, it conducts a lot better than when it is dry. Enough better that enough current flows to dissipate enough power to heat your skin past the point where you suffer burns. Or worse.
AFAIK even wet skin isn't conductive enough for you to get a serious shock off a 48v potential. Remember that the amount of current that _can_ be delivered by the supply is completely irrelevent if the load isn't low enough resistance to draw that current. In the case of your body, the resistance is high enough that you won't draw much current at 48v. Slapping a big conductor across the power rails such as a screw driver OTOH, will happilly max out whatever current the PSU will supply (until it melts).
although you can arc weld a screwdriver with it - melted metal==ouch
Well that's more about current - most 48v supplies are capable of delivering quite high currents (lower voltage == higher current for the same wattage). So whacking a big conductor across the circuit like a screwdriver means you'll get a massive current compared to most high voltage supplies (which would've blown a fuse for similar currents).
OTOH your body is not a great conductor so the fact there is a higher current available doesn't matter since it doesn't have the voltage required to pass through you.
The major inconvenience is you just can't send it through a transformer.
Less of a problem these days - most modern electronics use switched mode PSUs because they're cheaper, lighter and more efficient.
Yes, DC is better for a local area, until you need it at a different voltage than it was delivered at. Then AC starts to be better. And how many sites use the same voltage everywhere? Sweet FA. For example a PC uses 12v, 5v and more. A TV uses from about 25Kv to 5 volt. etc. etc.
Low frequency (50-60Hz) AC sucks only slightly less than DC for voltage conversion. You need big bulky inductors and capacitors. Which is why all the stuff you just mentioned rectifies the 50-60Hz AC and then uses an oscillator to generate a much higher frequency AC for stepping up and down (KHz or even MHz).
Of course very high frequency signals suffer really badly from transmission loss so you don't want to use them over any distance, so using DC for distribution in a local area is a good plan - especially if you can reduce losses by running it at a high voltage (but not high enough to kill you - e.g. 48 volts is a good compromise).
A 300W PC power supply at 63% efficiency has about 475W input, which means 175W loss. 175W would turn it into a crispy critter--more heat than a high end CPU, with less effective heat removal.
Efficiency in most PSUs increases as you increase the amount of power you're drawing. So whilest it may be 90% efficient when pulling the full 300W, it's probably only 70% when you're pulling 150W. Most machines don't spend the majority of their lives maxing out the PSU.
If every person in China spun up such a disk at the same time, it might affect the position of the North Star or change the length of the day.
The solution there is to spin up 50% of them clockwise and 50% anticlockwise so the torque cancels itself out. But moving them would likley be an almighty PITA given the gyroscopic effects of that much mass spinning at relativistic speeds, not to mention the problems of building bearings that will run that fast for any length of time without wearing or overheating. And I'd rather not be anywhere near that thing when it fails and flies apart.
They just claim Vonage takes up too much bandwidth and therefore violates the Terms of Service agreement that says they alone determine who or what is using up too much bandwidth and causing problems on their network.
GSM compressed VoIP takes up at most 13Kbps. I can't see that they can get away with blocking such a low bandwidth application on the grounds that it uses up too much bandwidth.
Whoever is sitting on the near-earth passing asteroid is in fact in command of weapon similar to clean nuke.
How exactly are you going to change the orbit of a few million tons of iron significantly enough to hit the Earth, let alone be able to aim the thing at a particular location?
lol every reply against him makes it all the more obvious how not ready for average users linux is. and truely a nightmare for tech support. sometimes ..u gotta realize not everyone is a geek. yea really u know
Please tell me which bit of my reply tells you Linux isn't ready for average users? The only thing I can see there that could be a problem is that users get a _choice_ as to whether to use the commandline or the GUI. I guess choice is confusing for some people, far better to force everyone into doing things in a particular way even if they don't like it.
I think there are 2 stumbling blocks that stop Linux being ready for the average user:
1. Lack of hardware support - this is getting better, but still if you don't buy the right hardware you're screwed. I'm not sure what can be done about this short of encouraging binary drivers (and this would be a very bad thing for stability)
2. People can't buy $random_software from PC World and install it. That's because most software companies only publish for Windows (to a lesser extent, Mac users have the same problem). FWIW, if you look around you can usually find an alternative piece of software (often free), but the average user would prefer to hand over a bundle of cash and buy a boxed application.
But given a choice, despite all my frustrations with Windows, I simply find Windows easier to use in a number of ways.
Having recently had to start using Windows after 5 years of not touching it, I can tell you that Windows is *exceptionally* unusable from my point of view. It's just nowhere near as userfriendly and capable as Linux.
On the other hand, with Linux, you usually have to get the executeable for your specific CPU if not your CPU and flavor of Linux
Yes, whereas Windows is far better because it only supports 1 type of CPU (x86)... I'm not sure what you're complaining about here - of course you can't run a program on an incompatable CPU, nomatter what OS you're using.
ease of finding apps, ease of installing said apps.
Yes, I too find typing "yum install foo" very taxing... no wait, I don't...
MPlayer, for example: An app for watching movies, is command-line.
Mplayer comes in both commandline and GUI versions. You can't tell me that giving the user a choice of whether they want to use the GUI or CLI is a bad thing.
I for one make a lot of use of the command line version.
but why don't they just include one so I don't go have to find one
They do - I get gmplayer installed with mplayer.
Most of the time I use the commandline version directly, on the odd occasion that I actually want to use a GUI version I tend to use Xine though.
Most non-tech users don't even know Windows has a command line. They don't need to know. That's a good thing.
I'm sorry, I can't see how you can complain about this stuff - if you install something that's designed to run from the commandline you can't complain that it runs from the commandline - if you wanted a program that runs from the GUI you damned well should've installed one instead.
Also, if Joe Sixpack makes a mistake and selects his neighbor's unsecured "linksys" (and sets it as default) rather than his own unsecured "linksys" should he be arrested?
It doesn't even need to be the user's mistake - if you tell a client to associate with your access point with SSID "linksys", it'll happilly associate with any access point with the SSID "linksys" (which will almost certainly hand out a DHCP lease too) without the user doing *anything*. This is of course how 802.11 roaming works.
Is it sane to arrest someone because a feature that's present in every piece of 802.11 hardware has automatically done what was intended?
If anyone should be held responsible for people associating with open access points it surely should be the person who set up the thing in the first place and maybe the AP manufacturer for making it easy (or even default) to set up an open network. There are uses for open access points, but the vast majority of people really don't want one so you should really have to look for the buttons to turn _off_ the encryption rather than it defaulting that way.
If a car manufacturer started shipping cars with no locks because "it's easier for the customer to use" then I'm sure there'd be hell to pay.
It becomes de facto prohibited because it leaves any law-abiding person in sufficient doubt to not do it.
Extending the analogy a bit, what if some non-free software "accidentally" came with free licences? Would the authorities be expected to protect the software publishers by arresting anyone exercising the rights that licence gives them? If so, would it then be ok for free software to be defacto-banned because noone knows which software is really free?
I can't understand how using a network that's *broadcasting* *invitations* can possibly be considered unauthorised. If the network owner didn't want to authorise your access then they damned well shouldn't have configured their access point to invite everyone to use it. Are we going to extend this interpretation of the law to prevent pwople from accessing *any* public network services? if not, why not?
You jail users:
http://news.bbc.co.uk/1/hi/technology/4721723.stm
I'm well aware that people have been jailed for unauthorised use of open APs, but my questions are:
1. If using a device that is actively broadcasting invitations for the public to use it is considered "unauthorised", surely it would be considered even more unauthorised if you were to go out of your way and actually probe a service to see if it's there (this is the case whenever you access any web server).
2. How is the user to know whether an open access point is supposed to be open or not? Shouldn't it be up to the owner of the access point to prevent it from inviting the public to use it? If I were to leave the door to my house open and hang a pub sign on the front, should I _really_ complain when someone comes in looking for a drink? Do I have the right to throw that person in jail? I'd argue not.
This isn't a question about network security - this is simply a question of how the defendent is supposed to _know_ whether they were authorised to use the access point.
Computer laws are pretty out-of-date in the UK
The computer misuse act is rather fuzzy when it comes to "unauthorised use" - it rather predates the notion of public network servers. What constitutes "unauthorised use"?
I.e. if you're running a publically accessible web server and I connect my browser to it, is that "unauthorised use"? You haven't given me written permission to use your web server.
Lets say you argue that publically accessible web servers are obviously authorised, otherwise you'd have to get permission from every webmaster before visiting their site - what if someone leaves their DSL router's web based administration page accessible to the internet? Does accessing that constitute unauthorised access? How were you to know that it wasn't a web server you were allowed to access before you actually accessed it?
Under a strict interpretation of the law it seems that it's illegal to access any computer without prior permission, which kinda outlaws most of the internet.
So far I've talked about network servers where you have to actively go out of your way to connect to them to discover if they are really public servers. What about open 802.11 networks? They actively _advertise_ the fact that they are public access points and there's no way to tell the difference between a real public AP and someone's home AP that's been set up by a complete moron. So is using a system that is actively inviting you to use it considered unauthorised? I would've thought that broadcast advertisements constitute authorisation.
The laws certainly need to catch up with modern technology, clearly if someone has firewalled off a service or encrypted their 802.11 network then you shouldn't be using it. However, I'm not sure what you can do to protect people who are stupid enough to leave their networks open without legislation killing off legitimate services - how do you legislate that people shouldn't use accidentally open access points without killing legitimately open access points at the same time?
Instead, we must weigh the legitimate and illegitimate uses against one another.
Which is clearly why guns (which are primarilly designed to put lumps of lead in people) are legal in the US...
incorrect. copies of software are sold, not licensed. this is established by precedent.
Can you provide a link to the precident?
If you really have been sold the software, rather than a licence to use it this would mean you didn't need to agree to a licence in order to use the software. Like it or not, EULAs have been shown to be legally enforcable by precident.
Actually, in this case, you're really only paying for support.
From a strictly technical point of view you're right. But in reality you are _effectively_ selling the software as well since it's bundled with the support - you can't get the support without the software, they are a package.
Similarly, selling FireFox on CDs you're _technically_ selling the media and the work involved in burning the CD, but for all intents and purposes you're effectively selling the software, media and service - they are bundled together, you can't buy the media and copying service without the software.
It's really just understanding how the masses view the transaction. How many times have you heard someone say something like "I've bought Microsoft Office"? They haven't, they've bought an aluminium and plastic disc, a cardboard box and a _licence_ to use the software. In the MS Office case, the licence you just bought may even be completely worthless to you as it may contain a clause that prevents you from using the software (since you can't view the licence until you've bought it). But from the perspective of most end users they have bought the software - they don't care about the legal technicalities.
Same goes for music and videos, etc. This is partly why many people get confused and angry about what they're allowed to do with stuff - as far as they're concerned when they bought a CD, they bought the actual music on it and don't see why they shouldn't be allowed to listen to it on their iPod. Infact they bought a licence to use the music in a certain way and that licence forbids them from using it how they want.
Whether or not you should be _required_ to agree the a licence (that you probably haven't seen) before you can use the content you've paid for, and whether that licence should be able to restrict your fair use rights, etc. are of course other matters open to debate.
Practically, though, GPL software can only be distributed for free, as there's nothing stopping someone who buys a copy of the software from turning around and giving it away for free to everyone else.
I think people like Red Hat, SUSE, etc would disagree with you to some extent. If you buy RHEL you get software _and_ support for a certain amount of cash. Much of the software is free but it is essentially being sold by being bundled with the support (and guaranteed future updates).
You can do this now. If you have a windows based mobile phone you can use skype.
Why would you want to do Skype? You could use SIP, which is the industry standard protocol rather than using a propriatory system. That way you could call anyone else who uses SIP without needing to involve a third-party "service provider" and you get to choose which PSTN gateway you use if you want to call someone on the PSTN.