He didn't say to avoid ALL closed hardware -- Just nVidia specifically, because it is such a crucial component which can be very difficult to support.
When calling for a boycott of a company because of their business practices, it seems somewhat wrong to only boycott that one company and say it's ok to buy from other people who have exactly the same business practices.
There isn't a huge amount of choice amoungst half-decent graphics hardware, and whilest nVidia don't open their specs they _are_ some of the easier devices to get working because their binary drivers are quite reasonable - it seems more worthwhile to target hardware manufacturers in markets where there is more choice in the first place - I can think of a few good examples in the 802.11 sector for one.
I think he started showing his insanity when he suggested that everyone should boycott any hardware with closed specs such as nVidia chips.... I guess he'll be going back to working on a PDP-11 then coz there's no way in hell he'll find a modern computer which has published specs for all it's hardware. It's a nice idea in theory, but really (at the moment) there is no option but to accept a certain amount of closed hardware.
RSS uses XML. XML is, you know, extensible? Why is Microsoft taking advantage of this standard a bad thing?
Extending *standards* is one thing, extending arbitrarilly is bad because when the software than most people use extends the functionality, people start using the new functionality and excluding software that doesn't support it which means everyone else has to play catch-up to add the new defacto features to their software. For RSS this might not be such a big deal since the format is basically pure informational data, but for other formats such as (X)HTML which contain meta-data like display formatting it starts to get difficult to use software that doesn't support all the features that are being used. This problem is made worse when the developers only test on the "leading" platform.
But if you are someone who wants RedHat to port a driver for some esoteric piece of hardware, you've got to have a long-term viability
Well, I'm basically agreeing with you but I don't see it as a problem really. Obviously no company is going to be especially interested in putting in man-hours to do something they'll never get paid for. But the thing with Linux is that you have the option of paying a third party developer to write some code. (With Windows, third parties can write drivers but certainly not hack the core kernel to do what they want).
That said, I've done a fair amount of work with Red Hat on their free distributions and they have usually been very helpful even though I'm not paying them - because I'm helping them to fix bugs and those fixes will end up in both Fedora Core and RHEL (benefitting their paying customers). And when I'm actually _fixing_ bugs they certainly tend to be quite helpful since obviously I'm improving their product at almost no cost to them.
When it comes to mixed mode mdia comminications, SIP is hardly a standard. The closest thing that comes to s standard is Netmeeting, and yes, it can interface with SIP, but doesn't use it natively.
Why does the VoIP signalling and IM traffic need to go over the same protocol? When you click a link in an email would you expect the web pages it points to to be retrieved over SMTP? If you have a SIP server and an XMPP server running on the same domain name and using the same user database then there's no reason why the client can't do IM over XMPP and VoIP over SIP transparantly.
On another note, once upon a time, people would have looked at your funny and said 'Why use this SIP crap? Just use Digital T1 signaling over the wire!'.
VoIP offers significant advantages over stuffing TDM traffic over a T1 or E1. I can't see any similarly significant advantages in using XMPP rather than SIP. The telco industry is slowly migrating from SS7 to SIGTRAN (as a stop-gap) and to IMS, which incorporates SIP - like it or not, SIP _is_ the industry standard VoIP protocol these days and there's a lot of software and hardware available to support it.
If we were designing VoIP from scratch then XMPP would be the place to put it, but with existing kid out there it seems silly to introduce another protocol which isn't really advantageous. To me, the only difference between Google inventing Jingle and Microsoft deciding they don't like Open Document and inventing something that does exactly the same job is that Jingle is open source - that still doesn't make it a Good Thing.
Most would consider THAT sort of request.. Commercial Software.. But I'm glad you have the need to give your preferences on what the engineers having fun should be doing..
Whilest I'm sure Google's employees may well have fun doing this stuff, this _is_ a commercial project - it was invented by Google for commercial reasons. I'd like to see some *good reasons* why they decided that they couldn't implement their project on a SIP architecture - "it's more fun" is not what I consider to be a good reason why a commercial entity would reinvent the wheel.
Mostly becouse XMPP can be extended easily to transport new types of data, without requiring modification of the existing protocol/servers/clients.
Errm, except you _do_ need to modify the client, otherwise it won't understand the new data you're transporting (VoIP). So where was the advantage over using the industry standard protocol? Similarly, if you want the server to do anything interesting you also need to modify that (voicemail?). I would much prefer to see effort going into supporting the existing industry standard protocol rather than creating another set of software that just reimplements what we already have in an incompatable way (I still haven't found a decent FOSS Linux SIP softphone). And on the subject of compatability, you can already get plenty of hardware SIP phones (either desk phones or walk-about 802.11 phones) and they won't work with XMPP.
Sorry, but if someone hands me a VoIP address to call, I want it to be a SIP address so I can use existing SIP hardware and software to call it. If there is a significant advantage then it might be worth migrating all VoIP stuff to a new protocol, but in this case I just don't see a reason to do it.
SIP is great. For phone calls. Adding VoIP transport information to Jabber/XMPP is mad easy.
Just because it can be done and/or is easy doesn't necessarilly mean it _should_ be done if it doesn't gain you anything. Don't get me wrong, I'm a big fan of XMPP but I don't see the point in just adding stuff into it that's already handled by other open protocols if there's no advantage in doing so.
Jabber support means one application can use the same common protocol for more things.
I'm still not convinced that using "one protocol for everything" is necessarilly a good reason for creating yet another VoIP protocol which is no more capable than the existing protocol (and from what I saw in the specs it's a good deal less capable). What's next? ditch HTTP and SMTP in favor of doing web and email over XMPP? Yes, it may be possible but does that make it worthwhile changing what we already have?
Parallel access to flash memory is relatively easy, unlike disk which is inherently serial to each platter. If demand for fast, large flash takes off I expect they'll just parallelize access to it, with the appropriate price/performance tradeoff off course.
Flash also suffers from significant wear issues - run an average system off a writable flash file system for any reasonable length of time and you _will_ wear the flash out, it's only good for a few thousand writes per cell. I did a lot of work building Linux systems that run off flash in my last job and this was a significant consideration - avoiding frequent writes is a big deal, and not something you can usually get away with on a general purpose computer (especially when the average moron user just pulls the power to shut it down, that's bad enough with hard drives which leave buffers dirty for relatively short periods of time)
Using XMPP also allows the use of transports, which will allow Jabber to connect to SIP and IAX networks, as well as supporting voice connections with MSN, Yahoo, etc.
Well you could do the same with SIP - gatewaying SIP calls to other networks through a SIP proxy has been possible for a long time (how do you think SIP PSTN gateways work?)
Key point here is that a system based on "email" like addresses would be batter and easier to remember than the current telecoms number based system.
You already get this with SIP... I'm not, on the whole, sure what integrating this with XMPP does to benefit anyone. I'd far prefer to see a bunch of decent FOSS SIP clients than yet another VoIP protocol.
Someone noted on one of the Google Talk mailing lists that as of the 9th of December Gmail's DNS has contained the SRV record necessary for other Jabber servers to send messages to the talk.google.com server (previously only the SRV record for clients was there), so it looks like it's definitely coming soon.
_xmpp-server._tcp.google.com. 86400 IN SRV 5 0 5269 federation.google.com.
Notice the "federation.google.com" bit - implies they're sticking to their federation plans and won't be letting people running their own servers connect. Whilest I understand why, I think this is a Bad Thing because the thing that makes Jabber so good is that I can (and do) run my own server and still talk to other people in the network.
Just looking a bit deeper, but not too much, I think JEP-0166 outlines a handshaking protocol, but actual binary data transmission takes place on other channels, say over rtp or rtcp. It looks like when handshaking (signalling) takes place, a list of possible channel candidates are offered, but it's not clear to me how the accepting party tells the initiating party which candidate is chosen.
Yes, XMPP is used as the signalling protocol, similar to SIP. AFAIK Google uses peer-to-peer RTP for the actual voice traffic, which means that NAT discovery (e.g. STUN) and traversal is needed, exactly like when using SIP.
Whilest I like the fact that Google are doing some open innovation, I'm not sure what the advantage of this is over the already well established SIP. A brief glance over the spec seems to suggest that this is nowhere near as capable as SIP infact, just providing the bare essentials to get an RTP session up and running. If *all* the traffic was transported over XMPP then it would have the advantage of making it easy to use on NATted connections, but would also mean that the quality of service would be severely degraded by TCP's head-of-line blocking, slow-start and congestion algorithms. As it is, signalling over XMPP and putting the voice traffic over RTP seems to offer no advantage over SIP and adds yet another VoIP protocol to the mix.
OTOH, maybe the addition of VoIP to XMPP will cause more IM clients to support VoIP natively which would make them easier to extend to support SIP - that would be good since there seem to be very few open source soft-phones ATM (I've certainly not found any decent ones, I've been using sjPhone which is closed source but happens to be freely available for Linux)
virtually every article is filled with grammatical errors.
The majority of articles I've read on Wikipedia are actually surprisingly good grammatically. The most obvious problem I keep seeing is where someone has edited a section of an article to expand or clarify it but hasn't modified another section of the same article, leading to slight repetition.
Of course, the advantage of the Wiki is that you can (and should) correct errors that you spot, whether they are factual or grammatical.
I think there is a dilemma about how to "start the process". Should people start buying hydrogen powered cars and hope there will be gas stations around, or should the stations be built, hoping that people around them will start getting hydrogen cars?
They managed to get LPG started and that has a similar problem (at least here in the UK, LPG is reasonably easy to get hold of - it'd not available at every petrol station, but there's usually a few places to fill up with LPG within a reasonable distance so I guess the people with LPG cars just have to know which petrol stations they can go to.
Admittedly it would be harder if the cars weren't dual-fuel since then you would _have_ to find somewhere selling LPG each time you needed to fill up (no idea if hydrogen powered internal combustian engines can be dual-fuel?)
The only way I know how to get pure hydrogen around here right now is to put magnesium into vinegar (or any other acid, but vinegar is easiest to get).
Electrolysis is the usual method. Not especially efficient, but it works. Crack water using electricity generated by fission plants and your hydrogen cars are effectively (highly inefficient) fission powered cars but without the risk of having millions of nuclear reactors doing 70mph down the motorway.:)
So let me guess we are going to have a 50ft thick cable floating from earth where these solar panels are located in space
No - the solar array sits in geosync orbit and transmits the collected energy back to a rectenna array on Earth as microwaves using a phased array. This is a pretty safe idea - you transmit a pilot microwave signal from Earth up to the satellite and the phased array on the satellite then uses the wave fronts of that pilot signal to synchronise the wavefronts transmitted by the phased array, so the energy will always be focussed on the source of the pilot beam. If the pilot beam stops transmitting then the phased array on the satellite will simply defocus the energy.
The rectenna array on Earth would also allow sunlight pass through it so it's even possible to use the land under it for growing crops or grazing animals, and in geosync orbit the satellite is exposed to the sun almost all the time.
Previous suggestions for putting large satellites like these in orbit have been to construct them on the moon from local materials - the moon's gravity is so low that you can launch them with a linear mass driver, no rockets required.
IMHO, this technology should be taken seriously to meet our long term energy needs - in the short term I can see fission being a good energy source but over the next 50 or so years I think fusion and orbital solar platforms are the best plan. Sadly, noone seems to want to get their finger out and spend money on this stuff until it's too late and we _have_ to.
Wasn't there a story just a while ago, telling that open (unlogged) WiFi is going to be illegal for just this reason ?
Does this mean that morons who set up an open access point because they're clueless will actually be accountable instead of people who take advantage of the open networks?
Honestly, I can't see how you can claim that someone logging into an open access point is illegal - there's no way you can tell it's not supposed to be open and it's *broadcasting* an *advertisment* *inviting* you to connect FFS. If that's illegal then surely connecting to a public webserver must be because when you're connecting to a webserver it didn't even invite you.
That said, I don't believe people running open APs should be responsible for illicit data passed through their connections any more than ISPs are.
Errm, how does liking a certain behaviour that I have used for years somehow make me low in intelligence?
The INABILITY to copy and replace text under X is the single MOST annoying reason for which I would switch to it.
Ok, so *YOU* don't like it - why should your opinion affect the way I do my work? The point is that this is a user preference and so should be settable by the user - when using Windows I'm being forced to deal with a behaviour _I don't like_ purely because someone else made a decision that a user shouldn't have the option of making it behave how they want.
You never accidentally highlight anything you don't mean to copy.
Why does that matter? If I never paste it, does it matter I hilighted a lump of text somewhere?
You never highlight a URL, switch to your browser, click the address bar, delete the current URL, switch BACK to re-copy the new URL and switch BACK to paste it
Actually, I usually highlight a URI, switch to my browser, hit ctrl+T to open a new tab and then paste into the blank address box because I virtually never want to open a URI I copied from somewhere in an existing tab. Also, FWIW Firefox allows you to go to the URI in your paste buffer without pasting it by using the middle button so this is never a problem.
His complaints are just as valid of OS X as of Gnome. He should use KDE or some other infinitely tweakable Linux desktop.
My big problem with the direction Gnome has gone is that it _was_ a good tweakable desktop suitable for techies, but all the moderately advanced features have been iteratively ripped out at each new release for the past few years.
If it started off as a desktop for dummies then that'd be fine since those of us who don't want a desktop for dummies would never have started using it (just as I don't volantarilly use Windows). The problem is that you get hackers like me who have been using it for years and get pissed off when a feature they've taken for granted and used on a day to day basis is just vanished for no good reason. Having this happen once is bad enough but having it happen with more features every time you upgrade is really bad.
As it is, I got sick of stuff I use vanishing and ditched Gnome in favour of E17, which is *much* lighter, much priddier and gets rid of the silly ripped-off-Windows taskbar, taking me back towards my TWM/FVWM roots.
It's worth me pointing out that it's not the *major* features that you can't do without that they're ripping out, it's the minor stuff that just makes it easier and faster to work with.
A good example of what I don't want to see is a good feature-rich WM turning into the MS Windows WM, which lacks all the infinitely useful stuff that makes it so much easier and more efficient to use: i.e. no window shade, no sloppy focus, no ability to use partially covered windows without raising them first, no proper select+paste (I still can't get used to the horrible idea that you have to tell it to copy what you selected before you can paste it elsewhere).
Assuming you're not attached to a miserably slow ISDN line (last I knew there was much heel dragging regarding upgrading from obsolete yet expensive tech) nor having to take out a second mortgage to pay for it I envy you.
It's a 2Mbps ADSL line, costs me about 20ukp / month (paid to the ISP) plus about 10ukp / month (paid to the telco for the POTS line). Other than having to pay for a voice line I hardly ever use (come on naked DSL!) the only problem I have with it is the rather slow 512Kbps upstream.
Your paying alot for it then. My static IP is $12 a year.
My static/29 subnet is free... If your ISP doesn't do that then I guess you need to shop around a bit - a large percentage (i.e. well over 50%) of the ISPs here in the UK will do static IPs by default and small subnets for free on request (usually they'll to a/30 without question and a/29,/28 or/27 without quibbling if you fill out a RIPE form showing why you need it).
We have the means to translate the entire IPv4 space into an IPv6 range, so many people won't notice when their ISP switches.
I don't believe IPv4 will be completely turned off within a reasonable length of time of the introduction of IPv6 at an ISP.
For a while we'll have IPv4 addresses for end users just as we do now, but also hand out IPv6 networks to them as well. (This is the start of the transition - IPv4 is still used by the masses, IPv6 traffic gradually increases)
At some point I suppose the ISP may well stop giving people global scope IPv4 addresses - give all the customers RFC1918 addresses and NAT everything at the ISP's border. (IPv4 usage is in decline - only a small percentage of traffic is IPv4, most is IPv6)
Eventually IPv4 will be turned off completely, but because they coexist I don't see a time when translating between IPv6 and IPv4 will be necessary (at least for the ISP).
I don't know what percentage of active switches do IPv6, but many of the older switches will start broadcasting the IPv6 because they don't understand it. Now your switch is a hub. That will choke any network that needed switches in the first place. Even a single switch that doesn't do IPv6 could take out a large chunk of your network.
I'm sorry, you are wrong. Switches don't know or care about network layer 3 (IPv4/IPv6/IPX/NetBios/etc) - switches only care about layer 2 (Ethernet). This is why your Ethernet network can run any of IP, NetBios, IPX, PPPoE, and anything else that runs over Ethernet regardless of what switches you have.
PBS is producing a lot of content (e.g. NOVA) in 16:9 SD. I was told the reason is so that it can be upsampled to HD without the black bars.
There's very little 4:3 content in the UK these days - pretty much all modern stuff is 16:9. Infact the only stuff I see that's 4:3 is old stuff and some of the US imports. But then, 16:9 TVs have been selling like hot cakes for *years* here. (I've had my 28" Sony Trinitron 16:9 for over 5 years and that only cost me 550ukp new).
What I'm getting at is that it's not exactly easy to find a 16:9 SDTV
Dead easy to get hold of them in the UK at very good prices (has been for many years, infact it's starting to get hard to find 4:3 TVs - these days the choice is mainly between standard definition 16:9 and HD 16:9) - why is the US different?
Slashdot Mirror
He didn't say to avoid ALL closed hardware -- Just nVidia specifically, because it is such a crucial component which can be very difficult to support.
When calling for a boycott of a company because of their business practices, it seems somewhat wrong to only boycott that one company and say it's ok to buy from other people who have exactly the same business practices.
There isn't a huge amount of choice amoungst half-decent graphics hardware, and whilest nVidia don't open their specs they _are_ some of the easier devices to get working because their binary drivers are quite reasonable - it seems more worthwhile to target hardware manufacturers in markets where there is more choice in the first place - I can think of a few good examples in the 802.11 sector for one.
Wow, RMS was rather lucid in this interview.
I think he started showing his insanity when he suggested that everyone should boycott any hardware with closed specs such as nVidia chips.... I guess he'll be going back to working on a PDP-11 then coz there's no way in hell he'll find a modern computer which has published specs for all it's hardware. It's a nice idea in theory, but really (at the moment) there is no option but to accept a certain amount of closed hardware.
RSS uses XML. XML is, you know, extensible? Why is Microsoft taking advantage of this standard a bad thing?
Extending *standards* is one thing, extending arbitrarilly is bad because when the software than most people use extends the functionality, people start using the new functionality and excluding software that doesn't support it which means everyone else has to play catch-up to add the new defacto features to their software. For RSS this might not be such a big deal since the format is basically pure informational data, but for other formats such as (X)HTML which contain meta-data like display formatting it starts to get difficult to use software that doesn't support all the features that are being used. This problem is made worse when the developers only test on the "leading" platform.
Is the icon covered by the GPL? If so Microsoft may potentially be opening themselves up for legal action.
(No, this isn't a dig at Microsoft or a dig at the GPL, it's just something that needs to be considered)
But if you are someone who wants RedHat to port a driver for some esoteric piece of hardware, you've got to have a long-term viability
Well, I'm basically agreeing with you but I don't see it as a problem really. Obviously no company is going to be especially interested in putting in man-hours to do something they'll never get paid for. But the thing with Linux is that you have the option of paying a third party developer to write some code. (With Windows, third parties can write drivers but certainly not hack the core kernel to do what they want).
That said, I've done a fair amount of work with Red Hat on their free distributions and they have usually been very helpful even though I'm not paying them - because I'm helping them to fix bugs and those fixes will end up in both Fedora Core and RHEL (benefitting their paying customers). And when I'm actually _fixing_ bugs they certainly tend to be quite helpful since obviously I'm improving their product at almost no cost to them.
When it comes to mixed mode mdia comminications, SIP is hardly a standard. The closest thing that comes to s standard is Netmeeting, and yes, it can interface with SIP, but doesn't use it natively.
Why does the VoIP signalling and IM traffic need to go over the same protocol? When you click a link in an email would you expect the web pages it points to to be retrieved over SMTP? If you have a SIP server and an XMPP server running on the same domain name and using the same user database then there's no reason why the client can't do IM over XMPP and VoIP over SIP transparantly.
On another note, once upon a time, people would have looked at your funny and said 'Why use this SIP crap? Just use Digital T1 signaling over the wire!'.
VoIP offers significant advantages over stuffing TDM traffic over a T1 or E1. I can't see any similarly significant advantages in using XMPP rather than SIP. The telco industry is slowly migrating from SS7 to SIGTRAN (as a stop-gap) and to IMS, which incorporates SIP - like it or not, SIP _is_ the industry standard VoIP protocol these days and there's a lot of software and hardware available to support it.
If we were designing VoIP from scratch then XMPP would be the place to put it, but with existing kid out there it seems silly to introduce another protocol which isn't really advantageous. To me, the only difference between Google inventing Jingle and Microsoft deciding they don't like Open Document and inventing something that does exactly the same job is that Jingle is open source - that still doesn't make it a Good Thing.
Most would consider THAT sort of request.. Commercial Software.. But I'm glad you have the need to give your preferences on what the engineers having fun should be doing..
Whilest I'm sure Google's employees may well have fun doing this stuff, this _is_ a commercial project - it was invented by Google for commercial reasons. I'd like to see some *good reasons* why they decided that they couldn't implement their project on a SIP architecture - "it's more fun" is not what I consider to be a good reason why a commercial entity would reinvent the wheel.
Mostly becouse XMPP can be extended easily to transport new types of data, without requiring modification of the existing protocol/servers/clients.
Errm, except you _do_ need to modify the client, otherwise it won't understand the new data you're transporting (VoIP). So where was the advantage over using the industry standard protocol? Similarly, if you want the server to do anything interesting you also need to modify that (voicemail?). I would much prefer to see effort going into supporting the existing industry standard protocol rather than creating another set of software that just reimplements what we already have in an incompatable way (I still haven't found a decent FOSS Linux SIP softphone). And on the subject of compatability, you can already get plenty of hardware SIP phones (either desk phones or walk-about 802.11 phones) and they won't work with XMPP.
Sorry, but if someone hands me a VoIP address to call, I want it to be a SIP address so I can use existing SIP hardware and software to call it. If there is a significant advantage then it might be worth migrating all VoIP stuff to a new protocol, but in this case I just don't see a reason to do it.
SIP is great. For phone calls. Adding VoIP transport information to Jabber/XMPP is mad easy.
Just because it can be done and/or is easy doesn't necessarilly mean it _should_ be done if it doesn't gain you anything. Don't get me wrong, I'm a big fan of XMPP but I don't see the point in just adding stuff into it that's already handled by other open protocols if there's no advantage in doing so.
Jabber support means one application can use the same common protocol for more things.
I'm still not convinced that using "one protocol for everything" is necessarilly a good reason for creating yet another VoIP protocol which is no more capable than the existing protocol (and from what I saw in the specs it's a good deal less capable). What's next? ditch HTTP and SMTP in favor of doing web and email over XMPP? Yes, it may be possible but does that make it worthwhile changing what we already have?
Parallel access to flash memory is relatively easy, unlike disk which is inherently serial to each platter. If demand for fast, large flash takes off I expect they'll just parallelize access to it, with the appropriate price/performance tradeoff off course.
Flash also suffers from significant wear issues - run an average system off a writable flash file system for any reasonable length of time and you _will_ wear the flash out, it's only good for a few thousand writes per cell. I did a lot of work building Linux systems that run off flash in my last job and this was a significant consideration - avoiding frequent writes is a big deal, and not something you can usually get away with on a general purpose computer (especially when the average moron user just pulls the power to shut it down, that's bad enough with hard drives which leave buffers dirty for relatively short periods of time)
Using XMPP also allows the use of transports, which will allow Jabber to connect to SIP and IAX networks, as well as supporting voice connections with MSN, Yahoo, etc.
Well you could do the same with SIP - gatewaying SIP calls to other networks through a SIP proxy has been possible for a long time (how do you think SIP PSTN gateways work?)
re: NAT, Jabber already has a specification (JEP-0065) for bytestream proxying. My guess is that's what will be used to get around NAT.
Google Talk uses STUN.
But whatever NAT discovery and traversal method is used, I still don't see an advantage in signalling over XMPP rather than SIP.
Key point here is that a system based on "email" like addresses would be batter and easier to remember than the current telecoms number based system.
You already get this with SIP... I'm not, on the whole, sure what integrating this with XMPP does to benefit anyone. I'd far prefer to see a bunch of decent FOSS SIP clients than yet another VoIP protocol.
Someone noted on one of the Google Talk mailing lists that as of the 9th of December Gmail's DNS has contained the SRV record necessary for other Jabber servers to send messages to the talk.google.com server (previously only the SRV record for clients was there), so it looks like it's definitely coming soon.
_xmpp-server._tcp.google.com. 86400 IN SRV 5 0 5269 federation.google.com.
Notice the "federation.google.com" bit - implies they're sticking to their federation plans and won't be letting people running their own servers connect. Whilest I understand why, I think this is a Bad Thing because the thing that makes Jabber so good is that I can (and do) run my own server and still talk to other people in the network.
Just looking a bit deeper, but not too much, I think JEP-0166 outlines a handshaking protocol, but actual binary data transmission takes place on other channels, say over rtp or rtcp. It looks like when handshaking (signalling) takes place, a list of possible channel candidates are offered, but it's not clear to me how the accepting party tells the initiating party which candidate is chosen.
Yes, XMPP is used as the signalling protocol, similar to SIP. AFAIK Google uses peer-to-peer RTP for the actual voice traffic, which means that NAT discovery (e.g. STUN) and traversal is needed, exactly like when using SIP.
Whilest I like the fact that Google are doing some open innovation, I'm not sure what the advantage of this is over the already well established SIP. A brief glance over the spec seems to suggest that this is nowhere near as capable as SIP infact, just providing the bare essentials to get an RTP session up and running. If *all* the traffic was transported over XMPP then it would have the advantage of making it easy to use on NATted connections, but would also mean that the quality of service would be severely degraded by TCP's head-of-line blocking, slow-start and congestion algorithms. As it is, signalling over XMPP and putting the voice traffic over RTP seems to offer no advantage over SIP and adds yet another VoIP protocol to the mix.
OTOH, maybe the addition of VoIP to XMPP will cause more IM clients to support VoIP natively which would make them easier to extend to support SIP - that would be good since there seem to be very few open source soft-phones ATM (I've certainly not found any decent ones, I've been using sjPhone which is closed source but happens to be freely available for Linux)
virtually every article is filled with grammatical errors.
The majority of articles I've read on Wikipedia are actually surprisingly good grammatically. The most obvious problem I keep seeing is where someone has edited a section of an article to expand or clarify it but hasn't modified another section of the same article, leading to slight repetition.
Of course, the advantage of the Wiki is that you can (and should) correct errors that you spot, whether they are factual or grammatical.
I think there is a dilemma about how to "start the process". Should people start buying hydrogen powered cars and hope there will be gas stations around, or should the stations be built, hoping that people around them will start getting hydrogen cars?
:)
They managed to get LPG started and that has a similar problem (at least here in the UK, LPG is reasonably easy to get hold of - it'd not available at every petrol station, but there's usually a few places to fill up with LPG within a reasonable distance so I guess the people with LPG cars just have to know which petrol stations they can go to.
Admittedly it would be harder if the cars weren't dual-fuel since then you would _have_ to find somewhere selling LPG each time you needed to fill up (no idea if hydrogen powered internal combustian engines can be dual-fuel?)
The only way I know how to get pure hydrogen around here right now is to put magnesium into vinegar (or any other acid, but vinegar is easiest to get).
Electrolysis is the usual method. Not especially efficient, but it works. Crack water using electricity generated by fission plants and your hydrogen cars are effectively (highly inefficient) fission powered cars but without the risk of having millions of nuclear reactors doing 70mph down the motorway.
So let me guess we are going to have a 50ft thick cable floating from earth where these solar panels are located in space
No - the solar array sits in geosync orbit and transmits the collected energy back to a rectenna array on Earth as microwaves using a phased array. This is a pretty safe idea - you transmit a pilot microwave signal from Earth up to the satellite and the phased array on the satellite then uses the wave fronts of that pilot signal to synchronise the wavefronts transmitted by the phased array, so the energy will always be focussed on the source of the pilot beam. If the pilot beam stops transmitting then the phased array on the satellite will simply defocus the energy.
The rectenna array on Earth would also allow sunlight pass through it so it's even possible to use the land under it for growing crops or grazing animals, and in geosync orbit the satellite is exposed to the sun almost all the time.
Previous suggestions for putting large satellites like these in orbit have been to construct them on the moon from local materials - the moon's gravity is so low that you can launch them with a linear mass driver, no rockets required.
IMHO, this technology should be taken seriously to meet our long term energy needs - in the short term I can see fission being a good energy source but over the next 50 or so years I think fusion and orbital solar platforms are the best plan. Sadly, noone seems to want to get their finger out and spend money on this stuff until it's too late and we _have_ to.
Wasn't there a story just a while ago, telling that open (unlogged) WiFi is going to be illegal for just this reason ?
Does this mean that morons who set up an open access point because they're clueless will actually be accountable instead of people who take advantage of the open networks?
Honestly, I can't see how you can claim that someone logging into an open access point is illegal - there's no way you can tell it's not supposed to be open and it's *broadcasting* an *advertisment* *inviting* you to connect FFS. If that's illegal then surely connecting to a public webserver must be because when you're connecting to a webserver it didn't even invite you.
That said, I don't believe people running open APs should be responsible for illicit data passed through their connections any more than ISPs are.
You are an unmitigated moron.
Errm, how does liking a certain behaviour that I have used for years somehow make me low in intelligence?
The INABILITY to copy and replace text under X is the single MOST annoying reason for which I would switch to it.
Ok, so *YOU* don't like it - why should your opinion affect the way I do my work? The point is that this is a user preference and so should be settable by the user - when using Windows I'm being forced to deal with a behaviour _I don't like_ purely because someone else made a decision that a user shouldn't have the option of making it behave how they want.
You never accidentally highlight anything you don't mean to copy.
Why does that matter? If I never paste it, does it matter I hilighted a lump of text somewhere?
You never highlight a URL, switch to your browser, click the address bar, delete the current URL, switch BACK to re-copy the new URL and switch BACK to paste it
Actually, I usually highlight a URI, switch to my browser, hit ctrl+T to open a new tab and then paste into the blank address box because I virtually never want to open a URI I copied from somewhere in an existing tab. Also, FWIW Firefox allows you to go to the URI in your paste buffer without pasting it by using the middle button so this is never a problem.
His complaints are just as valid of OS X as of Gnome. He should use KDE or some other infinitely tweakable Linux desktop.
My big problem with the direction Gnome has gone is that it _was_ a good tweakable desktop suitable for techies, but all the moderately advanced features have been iteratively ripped out at each new release for the past few years.
If it started off as a desktop for dummies then that'd be fine since those of us who don't want a desktop for dummies would never have started using it (just as I don't volantarilly use Windows). The problem is that you get hackers like me who have been using it for years and get pissed off when a feature they've taken for granted and used on a day to day basis is just vanished for no good reason. Having this happen once is bad enough but having it happen with more features every time you upgrade is really bad.
As it is, I got sick of stuff I use vanishing and ditched Gnome in favour of E17, which is *much* lighter, much priddier and gets rid of the silly ripped-off-Windows taskbar, taking me back towards my TWM/FVWM roots.
It's worth me pointing out that it's not the *major* features that you can't do without that they're ripping out, it's the minor stuff that just makes it easier and faster to work with.
A good example of what I don't want to see is a good feature-rich WM turning into the MS Windows WM, which lacks all the infinitely useful stuff that makes it so much easier and more efficient to use: i.e. no window shade, no sloppy focus, no ability to use partially covered windows without raising them first, no proper select+paste (I still can't get used to the horrible idea that you have to tell it to copy what you selected before you can paste it elsewhere).
Assuming you're not attached to a miserably slow ISDN line (last I knew there was much heel dragging regarding upgrading from obsolete yet expensive tech) nor having to take out a second mortgage to pay for it I envy you.
It's a 2Mbps ADSL line, costs me about 20ukp / month (paid to the ISP) plus about 10ukp / month (paid to the telco for the POTS line). Other than having to pay for a voice line I hardly ever use (come on naked DSL!) the only problem I have with it is the rather slow 512Kbps upstream.
Your paying alot for it then. My static IP is $12 a year.
/29 subnet is free... If your ISP doesn't do that then I guess you need to shop around a bit - a large percentage (i.e. well over 50%) of the ISPs here in the UK will do static IPs by default and small subnets for free on request (usually they'll to a /30 without question and a /29, /28 or /27 without quibbling if you fill out a RIPE form showing why you need it).
My static
So why bother making an estimate?
Because a bad estimate that makes something appear expensive gives you an excuse not to do it.
This isn't a lot different to "we must go to war because there are WMDs in Iraq" - bad research which can be used to justify stuff.
We have the means to translate the entire IPv4 space into an IPv6 range, so many people won't notice when their ISP switches.
I don't believe IPv4 will be completely turned off within a reasonable length of time of the introduction of IPv6 at an ISP.
For a while we'll have IPv4 addresses for end users just as we do now, but also hand out IPv6 networks to them as well. (This is the start of the transition - IPv4 is still used by the masses, IPv6 traffic gradually increases)
At some point I suppose the ISP may well stop giving people global scope IPv4 addresses - give all the customers RFC1918 addresses and NAT everything at the ISP's border. (IPv4 usage is in decline - only a small percentage of traffic is IPv4, most is IPv6)
Eventually IPv4 will be turned off completely, but because they coexist I don't see a time when translating between IPv6 and IPv4 will be necessary (at least for the ISP).
I don't know what percentage of active switches do IPv6, but many of the older switches will start broadcasting the IPv6 because they don't understand it. Now your switch is a hub. That will choke any network that needed switches in the first place. Even a single switch that doesn't do IPv6 could take out a large chunk of your network.
I'm sorry, you are wrong. Switches don't know or care about network layer 3 (IPv4/IPv6/IPX/NetBios/etc) - switches only care about layer 2 (Ethernet). This is why your Ethernet network can run any of IP, NetBios, IPX, PPPoE, and anything else that runs over Ethernet regardless of what switches you have.
PBS is producing a lot of content (e.g. NOVA) in 16:9 SD. I was told the reason is so that it can be upsampled to HD without the black bars.
There's very little 4:3 content in the UK these days - pretty much all modern stuff is 16:9. Infact the only stuff I see that's 4:3 is old stuff and some of the US imports. But then, 16:9 TVs have been selling like hot cakes for *years* here. (I've had my 28" Sony Trinitron 16:9 for over 5 years and that only cost me 550ukp new).
What I'm getting at is that it's not exactly easy to find a 16:9 SDTV
Dead easy to get hold of them in the UK at very good prices (has been for many years, infact it's starting to get hard to find 4:3 TVs - these days the choice is mainly between standard definition 16:9 and HD 16:9) - why is the US different?