Hmm, then I must have been playing instead of working here in the office - it's been two years since I switched my laptop over. Thanks for letting me know; it's a good thing they haven't fired me.
Waze is actually better, because you can edit the map yourself and fix it. Not that you should have to, but at least it's an option. You do have to have the appropriate access level to edit main streets and highways, but there are usually plenty of people online with access who can help you with things (see live chat). It also helps if you can point them to google street view to clearly show the problem.
I've made several small edits to address locations, street names, and turn restrictions. They show up in app after Waze does a map dump (about every week, if I remember correctly).
There was a previous "We the People" petition to the White House regarding encryption, and it got the required number of signatures to elicit a response. Rather than just putting out a useless blanket statement (as they do for a lot of the petitions), the White House is actually soliciting specific feedback before creating a position. You can send them comments regarding encryption through the White House website (links below). No idea if this will actually go anywhere (or get you put on some kind of watchlist!), but presumably it's better than just remaining quiet and letting them come to their own conclusions?
JVP, I'm not the same person as the AC, but I have been on both MiniMed and Decom CGMs. I've also done some CGM medical trials for MiniMed.
Without a doubt, I can agree with you that MiniMed CGMs absolutely suck and that the "artificial pancreas" marketing from MiniMed is crap. I used the MiniMed CGM on my pump for about 2 years and it was often way off my actual blood sugar. I talked with MiniMed reps several times and they would tell me the same crap: don't calibrate when your blood sugar is rising / dropping, don't calibrate more often than every 8 hours, etc., etc. I stuck with it mainly because of the convenience factor of having only one device to carry around.
My doctor convinced me to try a Dexcom because of the issues I was having, and I can tell you that it's a world of difference. The Dexcom has been so damn accurate, and a hell of a lot more comfortable than any of the MiniMed CGMs I have used. I can let it run past calibration (>12 hours) and it still gives readings. When I go to calibrate it (even if it's been >12 hours) it's very rarely off by more than 20 mg/dL unless my blood sugar is shooting up like crazy.
Maybe you have tried it, and maybe it didn't work for you.. but don't write off all CGMs. They do work. The only thing that sort of sucks is having to carry around another device.. For what it's worth, last time I saw the study in TFA, they were using a Dexcom CGM.
I agree, you could argue those points. But consider the end goal here - to make an effective emergency alerting system. If the user doesn't notice the alert because it's handled like every other text message, then you've lost some of the effectiveness. Plus, there are some tangible benefits in this system, which you don't get with regular text messages, like location-based alerting and broadcast alerting.
Sure, it will piss some people off. Sure, there is a lot of money being spent to implement it. However, compared to most government initiatives, this is probably one which people will find helpful.
By the way, my extent of involvement is implementing this application on a handset. I didn't come up with the standards, but I think they're pretty reasonable. Only time will tell how the system is (ab)used.
A very easy solution is to have all phones sold in US preconfigured to be subscribed a specific cell broadcast topic. If you don't want the alerts just unsubscribe with the phone's standard interface.
Yep, that's essentially what this does. There are thirty topics reserved just for CMAS alerts. Phones will come pre-subscribed to some of those. The main difference here is that the "standard" CBS application isn't used to handle messages received on these topics. The reason is because there are some specific actions the phone must take when receiving these messages - playing a tone, vibra, etc.
But there's no real reason why an old phone which supports generic CBS couldn't receive the alerts, if it was subscribed to them. Part of the problem is that some phone makers limited the range of topic ids you can subscribe to using the UI, and the CMAS topics are outside of that range.
No need for a special chip (oooh, I forgot that someone has to pay for the personal planes of large companies and decision makers).
As I said in another post, this "special chip" stuff is completely bogus. I have no idea where the article got that from. On the phone-side of things, you only need CBS support in the cell modem (which should already be there) and a CMAS application (just software).
What is being added here is "special handling" for specific CBS messages. In other words, when you receive a CMAS message through CBS, your phone handles it differently than a "normal" CBS message by playing an alert tone, etc.
Technically, no. But when you connect your phone to a cell network, you do have some implicit trust that it's really your operator who's providing the service. So if someone could break in to the operator's network, maybe they could spoof a CMAS message. I guess you could make the same argument for all other kinds of broadcast services.
Text messages are, in a general sense, point-to-point. When you're trying to notify thousands of people at the same time (an emergency situation), you want as little overhead as possible. So, broadcasting makes the most efficient use of network resources. The expense here is largely in handsets (software support) and for the operators (alert gateway). They are trying to re-use existing technology, where appropriate..
I don't know where the article gets this "chip" idea from -- that is completely bogus.
The system uses the standard cell broadcast system (CBS) as its backend, and most phones have supported that forever. It is basically an application which sits on top of CBS.
It doesn't track your location.
The system is implemented using Cell Broadcast (CBS), which indiscriminately sends out messages to all users in a particular cell. So if your phone is camping in a cell where a tornado will soon strike, you get the message. In this sense, it works exactly like any other one-way radio broadcast -- the sender doesn't know who received the message or how many received it. They can do this because the cellular provider DOES know the location of each cell tower and the general area the tower covers.
Glad the info is helpful. I think the system has good potential as another way to get alerts out there if people miss other, traditional channels. Although, if the lines to your local tower are taken out by a tornado, I would hope the alerts go out long before that!
To answer your question, first you have to know about the types of messages that can be sent. The spec uses 30 total message identifiers, which fall into groups such as Presidential, Imminent-Extreme, Imminent-Severe, AMBER, Test, and Reserved. These 30 identifiers are consolidated into these groups before being presented to the user. This is a bit of a simplification, but you can probably get the general idea. The specification says that by default, phones will be subscribed to all alerts, but that they can opt-out of everything except presidential alerts. So maybe this is a small step towards Big Brother, but at least it is one way only!:)
I'm not 100% sure of how the Australian system works, but according to this site it appears to be based on text messages and uses locations based on the billing addresses? It sounds similar in concept but quite a bit different in implementation.
I have no idea how often messages would be sent out using this new system, but the existing emergency alert system on TV is probably a good indicator. This new system does allow for federal, state, and local agencies to send alerts, so I could see the possibility for some abuse. Thankfully, you can turn off almost all the alerts, so this shouldn't be a problem in practice..
I think this is possible; it should be up to the handset vendor to allow for things like this. The spec allows for users to opt-out of things like AMBER alerts, but I could foresee "opt-out" interpreted as "still receive message but don't alert". The spec also allows the message reception on the handset to respect the current volume level -- if you're phone's on silent, you wouldn't hear the tone, for example (it's debatable whether or not this is a good idea!).
In any case, you can opt-out of every alert type except one - Presidential-level alerts. I suppose that if Obama wants you to hear about something, you don't have a choice:)
First: Is there any sort of method in-place wherein a message can be repeatedly broadcast, but only alert subscribers on the first successfully received message?
Yes, that's part of the CBS specification and and the emergency system uses this as well. The messages are broadcast for a set amount of time at a set repetition rate. They also contain serial numbers so that the handsets can distinguish between old and new messages. There is also a provision for sending updates to messages which have already been transmitted.
With what geographic granularity will the broadcasts be sent (or perhaps more properly, received)?
I'm not sure how granular it will be in practice, but it could technically get down to the individual cell level. Most likely, the carriers know which cells approximately serve which zip codes and would group based on that. The specs don't say exactly how this should be done, except that the "Cell Broadcast Center" should determine the affected cell sites for the geolocation (geo-code, polygon, circle) of the emergency message.
Third: Is there any pertinent documentation available that I can ogle?
There really isn't much documentation which is publicly available. Here are a few things, although they're short on real details:
Announcements: FEMAFCCCTIA
Standards (paywalled): ATIS 0700006Joint ATIS/TIA J-STD-100
Sorry I don't have links to the actual specifications content. For some reason, you have to be a member company or pay for them.
I should have referred to the system by its proper name -- in the U.S., it's called the Commercial Mobile Alert System (CMAS). There are similar systems being set up in other countries which closely follow the U.S. specifications, and those systems should be compatible with CMAS (at least that's the plan).
I'm actually working on the handset side of this, so I can answer some of the questions people have about it.
It's really not that complicated of a system. It uses Cell Broadcast Services (CBS) which are part of the existing 3GPP and 3GPP2 standards. Some of you may have seen CBS applications in your phones, but they're typically not used in the U.S. CBS is, as its name implies, a broadcast service.. so obviously it's one-way only. If your phone isn't "subscribed" to the particular message identifier (a kind of topic or category), or your phone isn't on when the message is broadcast, you'll miss it. The system has different classifications for messages, from nationwide alerts, to local alerts (like hurricanes), to AMBER alerts. There can't really be any way for operators to charge for broadcast messages, any more than they can charge for other broadcast resources like paging channels, so I think the only way your bill would be affected would be if they do some blanket 10 cent "government" fee for everyone... By the way, the reason they are using CBS is because it does not place a strain on the network, like sending millions of SMS messages at once would (that's important in a disaster situation when people might be overloading the network).
The special handling on the handset side is to take some specific actions when an emergency message is received.. it has to play a special tone and vibration, among other things. You can opt-out of pretty much all messages, so don't get too worried about being woken up in the middle of the night for AMBER alerts (well, unless you want to receive them). The system supports a monthly test message, but you wouldn't be opted-in to those by default.
The nature of the cell network allows operators to broadcast the messages to specific cells, so you are not going to get alerts for things happening elsewhere in the country. But the design also allows for national (presidential-level) distribution, so yes, in those cases, everybody would get the alert. The network-side of things is more interesting than the handset side, because of how different levels of the government need to be able to send alerts, and this is mostly what the article talks about (although it's short on details).
If you have other questions, reply and I can try to answer them.
Maemo 5 default browser on the Nokia N900 (MicroB):
Acid3: 93 / 100
Sunspider Java: 36722.0ms +- 1.5%
It also has full flash support with no jerky playback. Not too bad, and in my opinion it's pretty fast for browsing (if you have 3G or WLAN). Acid3 results make sense because it has a similar engine as Fennec. I just installed the latest Fennec on my N900 and it is a really nice browser, too. Here are its results:
Acid3: 94 / 100
Sunspider Java: 18899.4ms +- 5.5%
I think it's important to count extensibility into the mix as well... I have Adblock Plus installed on my N900 for MicroB and that speeds up browsing a lot!
It's not a typo. When addresses are configured, there is a universal/local bit set. See the appendix of RFC 3513 for more info, under the section "Links or Nodes with IEEE 802 48 bit MAC's."
When TCP decides it can send more data, it dumps a whole window size load of packets onto the network. These will clog up your modem / router's transmit buffers. Normally not a huge drain, but if you're uploading to a number of hosts this can add significant lag for the small ACK packets you have to send periodically. If you can't send an ACK to the hosts you're downloading from, they'll stop sending more data since they will think that your download bandwidth is saturated.
This all well and good, but it assumes that you are sending small ACK's. From my experience and packet captures, the ACK's are sent in the same large data packets you're uploading to the peer you're downloading from. The only case you'd have small ACK's is if you're downloading from a seed or not uploading to a particular peer. I use BitTornado on Linux 2.6; I suppose other clients and TCP stacks might have different results.
I set up an iptables script on my box to prioritize small TCP ACKs (64 bytes) but the performance was almost as bad as when I let my upstream link get saturated. I've found the best method is to just force your client to limit its upload bandwidth. This way you generally avoid TCP retransmissions.
You could have two different opinions here: 1. Linux has ways to go because of silly things like this. 2. Be thankful that there are people in the community that are willing to help (for free) when you have problems.
And yes, the Linux community doesn't always have an answer, but it's feedback like this that can only make Linux software better!
Slashdot Mirror
I did. StarCraft used to work well under WINE, so I was hoping to play for nostagia's sake.
:)
It installed just fine, but fails to run with a DLL issue. Hopefully with some investigation, the WINE gods can figure out the cause.
https://bugs.winehq.org/show_bug.cgi?id=42741
Linux on desktop is a toy.
Is it now?
Hmm, then I must have been playing instead of working here in the office - it's been two years since I switched my laptop over. Thanks for letting me know; it's a good thing they haven't fired me.
Waze is actually better, because you can edit the map yourself and fix it. Not that you should have to, but at least it's an option. You do have to have the appropriate access level to edit main streets and highways, but there are usually plenty of people online with access who can help you with things (see live chat). It also helps if you can point them to google street view to clearly show the problem.
I've made several small edits to address locations, street names, and turn restrictions. They show up in app after Waze does a map dump (about every week, if I remember correctly).
See: https://www.waze.com/editor
There was a previous "We the People" petition to the White House regarding encryption, and it got the required number of signatures to elicit a response. Rather than just putting out a useless blanket statement (as they do for a lot of the petitions), the White House is actually soliciting specific feedback before creating a position. You can send them comments regarding encryption through the White House website (links below). No idea if this will actually go anywhere (or get you put on some kind of watchlist!), but presumably it's better than just remaining quiet and letting them come to their own conclusions?
Links:
The petition and response
The form to send comments
Funnily enough, it's a secure website.. hmm..
C'mon, editors!
http://www.nytimes.com/2015/11...
JVP, I'm not the same person as the AC, but I have been on both MiniMed and Decom CGMs. I've also done some CGM medical trials for MiniMed.
Without a doubt, I can agree with you that MiniMed CGMs absolutely suck and that the "artificial pancreas" marketing from MiniMed is crap. I used the MiniMed CGM on my pump for about 2 years and it was often way off my actual blood sugar. I talked with MiniMed reps several times and they would tell me the same crap: don't calibrate when your blood sugar is rising / dropping, don't calibrate more often than every 8 hours, etc., etc. I stuck with it mainly because of the convenience factor of having only one device to carry around.
My doctor convinced me to try a Dexcom because of the issues I was having, and I can tell you that it's a world of difference. The Dexcom has been so damn accurate, and a hell of a lot more comfortable than any of the MiniMed CGMs I have used. I can let it run past calibration (>12 hours) and it still gives readings. When I go to calibrate it (even if it's been >12 hours) it's very rarely off by more than 20 mg/dL unless my blood sugar is shooting up like crazy.
Maybe you have tried it, and maybe it didn't work for you.. but don't write off all CGMs. They do work. The only thing that sort of sucks is having to carry around another device.. For what it's worth, last time I saw the study in TFA, they were using a Dexcom CGM.
I agree, you could argue those points. But consider the end goal here - to make an effective emergency alerting system. If the user doesn't notice the alert because it's handled like every other text message, then you've lost some of the effectiveness. Plus, there are some tangible benefits in this system, which you don't get with regular text messages, like location-based alerting and broadcast alerting.
Sure, it will piss some people off. Sure, there is a lot of money being spent to implement it. However, compared to most government initiatives, this is probably one which people will find helpful.
By the way, my extent of involvement is implementing this application on a handset. I didn't come up with the standards, but I think they're pretty reasonable. Only time will tell how the system is (ab)used.
A very easy solution is to have all phones sold in US preconfigured to be subscribed a specific cell broadcast topic. If you don't want the alerts just unsubscribe with the phone's standard interface.
Yep, that's essentially what this does. There are thirty topics reserved just for CMAS alerts. Phones will come pre-subscribed to some of those. The main difference here is that the "standard" CBS application isn't used to handle messages received on these topics. The reason is because there are some specific actions the phone must take when receiving these messages - playing a tone, vibra, etc.
But there's no real reason why an old phone which supports generic CBS couldn't receive the alerts, if it was subscribed to them. Part of the problem is that some phone makers limited the range of topic ids you can subscribe to using the UI, and the CMAS topics are outside of that range.
No need for a special chip (oooh, I forgot that someone has to pay for the personal planes of large companies and decision makers).
As I said in another post, this "special chip" stuff is completely bogus. I have no idea where the article got that from. On the phone-side of things, you only need CBS support in the cell modem (which should already be there) and a CMAS application (just software).
That's exactly what this is. CBS is already part of the standards for GSM and CDMA. Wikipedia describes it pretty well: http://en.wikipedia.org/wiki/Cell_Broadcast
What is being added here is "special handling" for specific CBS messages. In other words, when you receive a CMAS message through CBS, your phone handles it differently than a "normal" CBS message by playing an alert tone, etc.
Technically, no. But when you connect your phone to a cell network, you do have some implicit trust that it's really your operator who's providing the service. So if someone could break in to the operator's network, maybe they could spoof a CMAS message. I guess you could make the same argument for all other kinds of broadcast services.
Text messages are, in a general sense, point-to-point. When you're trying to notify thousands of people at the same time (an emergency situation), you want as little overhead as possible. So, broadcasting makes the most efficient use of network resources. The expense here is largely in handsets (software support) and for the operators (alert gateway). They are trying to re-use existing technology, where appropriate..
I don't know where the article gets this "chip" idea from -- that is completely bogus.
The system uses the standard cell broadcast system (CBS) as its backend, and most phones have supported that forever. It is basically an application which sits on top of CBS.
It doesn't track your location. The system is implemented using Cell Broadcast (CBS), which indiscriminately sends out messages to all users in a particular cell. So if your phone is camping in a cell where a tornado will soon strike, you get the message. In this sense, it works exactly like any other one-way radio broadcast -- the sender doesn't know who received the message or how many received it. They can do this because the cellular provider DOES know the location of each cell tower and the general area the tower covers.
Glad the info is helpful. I think the system has good potential as another way to get alerts out there if people miss other, traditional channels. Although, if the lines to your local tower are taken out by a tornado, I would hope the alerts go out long before that!
:)
To answer your question, first you have to know about the types of messages that can be sent. The spec uses 30 total message identifiers, which fall into groups such as Presidential, Imminent-Extreme, Imminent-Severe, AMBER, Test, and Reserved. These 30 identifiers are consolidated into these groups before being presented to the user. This is a bit of a simplification, but you can probably get the general idea. The specification says that by default, phones will be subscribed to all alerts, but that they can opt-out of everything except presidential alerts. So maybe this is a small step towards Big Brother, but at least it is one way only!
I'm not 100% sure of how the Australian system works, but according to this site it appears to be based on text messages and uses locations based on the billing addresses? It sounds similar in concept but quite a bit different in implementation.
I have no idea how often messages would be sent out using this new system, but the existing emergency alert system on TV is probably a good indicator. This new system does allow for federal, state, and local agencies to send alerts, so I could see the possibility for some abuse. Thankfully, you can turn off almost all the alerts, so this shouldn't be a problem in practice..
I think this is possible; it should be up to the handset vendor to allow for things like this. The spec allows for users to opt-out of things like AMBER alerts, but I could foresee "opt-out" interpreted as "still receive message but don't alert". The spec also allows the message reception on the handset to respect the current volume level -- if you're phone's on silent, you wouldn't hear the tone, for example (it's debatable whether or not this is a good idea!).
:)
In any case, you can opt-out of every alert type except one - Presidential-level alerts. I suppose that if Obama wants you to hear about something, you don't have a choice
First: Is there any sort of method in-place wherein a message can be repeatedly broadcast, but only alert subscribers on the first successfully received message?
Yes, that's part of the CBS specification and and the emergency system uses this as well. The messages are broadcast for a set amount of time at a set repetition rate. They also contain serial numbers so that the handsets can distinguish between old and new messages. There is also a provision for sending updates to messages which have already been transmitted.
With what geographic granularity will the broadcasts be sent (or perhaps more properly, received)?
I'm not sure how granular it will be in practice, but it could technically get down to the individual cell level. Most likely, the carriers know which cells approximately serve which zip codes and would group based on that. The specs don't say exactly how this should be done, except that the "Cell Broadcast Center" should determine the affected cell sites for the geolocation (geo-code, polygon, circle) of the emergency message.
Third: Is there any pertinent documentation available that I can ogle?
There really isn't much documentation which is publicly available. Here are a few things, although they're short on real details:
Announcements: FEMA FCC CTIA
Standards (paywalled): ATIS 0700006 Joint ATIS/TIA J-STD-100
Sorry I don't have links to the actual specifications content. For some reason, you have to be a member company or pay for them.
I should have referred to the system by its proper name -- in the U.S., it's called the Commercial Mobile Alert System (CMAS). There are similar systems being set up in other countries which closely follow the U.S. specifications, and those systems should be compatible with CMAS (at least that's the plan).
I'm actually working on the handset side of this, so I can answer some of the questions people have about it.
It's really not that complicated of a system. It uses Cell Broadcast Services (CBS) which are part of the existing 3GPP and 3GPP2 standards. Some of you may have seen CBS applications in your phones, but they're typically not used in the U.S. CBS is, as its name implies, a broadcast service.. so obviously it's one-way only. If your phone isn't "subscribed" to the particular message identifier (a kind of topic or category), or your phone isn't on when the message is broadcast, you'll miss it. The system has different classifications for messages, from nationwide alerts, to local alerts (like hurricanes), to AMBER alerts. There can't really be any way for operators to charge for broadcast messages, any more than they can charge for other broadcast resources like paging channels, so I think the only way your bill would be affected would be if they do some blanket 10 cent "government" fee for everyone... By the way, the reason they are using CBS is because it does not place a strain on the network, like sending millions of SMS messages at once would (that's important in a disaster situation when people might be overloading the network).
The special handling on the handset side is to take some specific actions when an emergency message is received.. it has to play a special tone and vibration, among other things. You can opt-out of pretty much all messages, so don't get too worried about being woken up in the middle of the night for AMBER alerts (well, unless you want to receive them). The system supports a monthly test message, but you wouldn't be opted-in to those by default.
The nature of the cell network allows operators to broadcast the messages to specific cells, so you are not going to get alerts for things happening elsewhere in the country. But the design also allows for national (presidential-level) distribution, so yes, in those cases, everybody would get the alert. The network-side of things is more interesting than the handset side, because of how different levels of the government need to be able to send alerts, and this is mostly what the article talks about (although it's short on details).
If you have other questions, reply and I can try to answer them.
I just posted some info on the article:
Maemo 5 default browser on the Nokia N900 (MicroB):
Acid3: 93 / 100
Sunspider Java: 36722.0ms +- 1.5%
It also has full flash support with no jerky playback. Not too bad, and in my opinion it's pretty fast for browsing (if you have 3G or WLAN). Acid3 results make sense because it has a similar engine as Fennec. I just installed the latest Fennec on my N900 and it is a really nice browser, too. Here are its results:
Acid3: 94 / 100
Sunspider Java: 18899.4ms +- 5.5%
I think it's important to count extensibility into the mix as well... I have Adblock Plus installed on my N900 for MicroB and that speeds up browsing a lot!
Roll down the windows? :)
The sad thing is that this excerpt comes from the "features" section of that page. Who wants to be able to run only 3 programs as a *feature*?
It's not a typo. When addresses are configured, there is a universal/local bit set. See the appendix of RFC 3513 for more info, under the section "Links or Nodes with IEEE 802 48 bit MAC's."
http://www.faqs.org/rfcs/rfc3513.html
This all well and good, but it assumes that you are sending small ACK's. From my experience and packet captures, the ACK's are sent in the same large data packets you're uploading to the peer you're downloading from. The only case you'd have small ACK's is if you're downloading from a seed or not uploading to a particular peer. I use BitTornado on Linux 2.6; I suppose other clients and TCP stacks might have different results.
I set up an iptables script on my box to prioritize small TCP ACKs (64 bytes) but the performance was almost as bad as when I let my upstream link get saturated. I've found the best method is to just force your client to limit its upload bandwidth. This way you generally avoid TCP retransmissions.
You could have two different opinions here:
1. Linux has ways to go because of silly things like this.
2. Be thankful that there are people in the community that are willing to help (for free) when you have problems.
And yes, the Linux community doesn't always have an answer, but it's feedback like this that can only make Linux software better!
Just my $0.02.
.
Look, it's the night sky!