Trust me it can do 1X. The entire Kyocera 22xx line is a 1X line (Verizon uses the 2235 for their Express Network service). I suppose Sprint could refuse to offer "vision" service with this phone, but the phone itself is capacble of doing it.
Also, CNET reviews tend to suck and be grossly incomplete.
There were non-technical reasons behind this. For one thing NTT bought a big chunk (about 20%) of ATT Wireless. Literally a couple of days later ATT announced they were doing GSM not CDMA (they were undecided before). Not surprisingly NTT is a big GSM->GPRS->UMTS backer. ATT also soon after jusmped on the iMode bandwagon (not too bad of a bandwagon to jump on). The end game of UMTS is a good one. However, GSM is definitely showing its age, and it's going to be a slow and rocky path for the GSM people to get to UMTS, while the migration for CDMA is much nicer.
Sprint has been offering the Kyocera 2255 for many months now, and it is 1X compatable. I bought one for this reason. It's a decent phone, no big bells and whistles, but it won't go obsolete and it's a nice little phone.
My guess would be about the same as normal SprintPCS wireless web service with a laptop, which is you can get it to work (I use it all the time), but you may hit some limitations (they had some semi-neat image compression for http connections that made it semi-bearable to use that didn't have a linux client). It shouldn't matter, we're talking about open standards here.
Well you can use the technology with your laptop. I don't see why everyone thinks that if your data is being transmitted via cell phone, the cell phone has to be the final displaying device.
Also, I know it's not a popular thing to say here, but Microsoft's Smartphone group has come up with a fairly impressive product if you do want to use your phone as the endpoint.
The upgrade from a BPSK CDMA system to a QPSK CDMA system is totally different and quite a bit easier than the upgrade from a TDMA system to a CDMA system. Thus, the GPRS->UMTS evolution is quite a bit more complex than the relatively straightforward IS-95->IS-2000 evolution.
A few minor fact corrections (I won't comment on the opinions).
IS-95B is in use in Japan. KDDI offered the service, though 1X kind of obsoletes this.
I have heard no one talk about deploying 3X in the forseeable future. 1X, 1X-EX-DO, and 1X-EX-DV are in the works though.
To correct a replying poster too, despite the name 1X-EX-DO does not imply the phone would have to be data only, only that the standard is data only. It would still allow you to talk to a vanilla 1X base station, though this might not be the same base station you were talking to for data.
There is a substantial difference. The basic pieces of 1X evolve up to meet this requirement. The ITU standard defines "mega cells" (cells that cover the entire planet or at least something like a continent), "macro cells" (regions) "microcells" (local areas) and "pico cells" (like an office, home, or small park, the kind of area that an 802.11 network might cover today). The requirements are 9.6kbs for mega 144 for macro 384 for micro and 2 mbit/s for pico.
The requirements require that one should be able to seemlessly handoff between these various types of cells.
1X meets the requirements down to macro. 1X-EV-DO (Qualcomm's proposal, formerly HDR) and 1X-EV-DV (Motorola's proposal, formerly 1XTREME), cover the smaller cells and meet the requirement. Thus 1X evolves as a standard to meet the 3G requirment.
GPRS is totally different. GPRS simply is a hack on GSM. It involves ganging together timeslots to up the datarate. What you have now is as far as it goes, end of the line. The GSM folks envison UMTS (W-CDMA) replacing GPRS into the future. However, this is a totally different system. In fact it's CDMA-based while GSM/GPRS is a TDMA system. GPRS does not evolve to meet the ITU's requirements.
Actually I know of no one using 1X to transmit better voice quality. This is generally the result of better vocoders. IS-95 or 1X most are still using 14k or 8k vocoders.
However, from a voice standpoint, 1X does increase the number of calls possible on a given carrier. This means more efficient spectrum utilization, which in theory should mean lower end user cost.
However, as you mention higher data rates, means exactly that, high data rates while moving. You no longer have to be tied down to a wireline or a limited range 802.11 network. One is totally freed to go where they please. You can't tell me you've never wanted to have a semi-decent network connection while in a car, on a train, on a bus, or in an airport. Now you can. To me that is pretty cool, and is why I thought highly enough of 3G to take a job related to it. I'd use it. Wouldn't you?...and even if you wouldn't the voice capacity increase makes it good for you. Wins all alround.
To the best of my knowledge Matador Records is in no way associated with the RIAA. They also are the home to a number of really great artists. Yo La Tengo, which is on their label, is one of my favorites. Older music by Guided by Voices, another favorite band of mine, is also still on their label, although I believe more recently GBV moved to TVT.
It is not a subsidiary of another company. She is the sole proprieter and owner of Righteous Babe Records, and as far as I know the only artist on the label. Ani DiFranco is a truly _independent_ artist.
No, you don't understand what you're talking about. Both UNIX and NT are C1 systems. They offer the traditional discressionary access control: file permissions or acls. B1 is fundamentally different. MAC may sound like ACLs with documentation, but it is not. In DAC a file's access is controlled at the discression of the user (hence the name). Basically, if you and I are on the same system, I can let you see my file. In MAC, if you shouldn't be seeing my file, you won't. The system assigns a sensitivity label to the file. Think of it like the difference between a file in your filing cabinet and a file at a military institution. If you have a file in your cabinet that you wrote, you can let me read it or write to it if you desire. If it's at a military base, and its stored there, you need a certain clearance level to enter where the file is and read it. If I have Top Secret clearance, and you only have Secret, no matter how much I want you to read the file, you can't, and I can't make you Top Secret. It's a forced analogy but you get the point.
Documentation is required to confirm correctness and to specify how requirements were met. There's a lot of modification to the code.
In truth, I'd be surprised if FreeBSD wanted this in the core OS. A B1 level of security can get quite annoying in situations where security is not your paramount goal. There is a lot of extra overhead to do MAC checks and MAC intentionally sort of puts people in a prison.
The Orange Book is not simple either, and reading the glossary is not a substitute for reading the book (which I have not). It's very thick and extremely detailed.
You're assuming mistakenly that the checks are done somewhere in user space, such as in the shell or in cat. This is not the case. The checks are done in the kernel. Thus in the example given you would be able to open the two files but if you fread to a, the kernel will not allow you to write that info to b, but instead will return an error if the SL of the file you are trying to write to is bellow the one you have read from. Labels permeate the system, labeling files, processes, et al.
At least with encap, encap binary packages are quite available. As for dependencies, it is true those are not handledas much. However, in general many package management systems do a bad job with this. I end up using the force options to rpm a lot when I use it.
Right idea, wrong tool. See encap http://encap.cso.uiuc.edu. Stow and encap were developed completely independent of each other, but came up with the right idea. The difference is epkg, the current encap implementation, is far more featureful and far faster than stow. It's really a generation ahead.
The WINE project was going on when I first started using linux about 4 years ago. Opera for linux development started last year. The fact that the two are even comparable gives the edge to Opera.
Umm....Toll Tech, the makers of qt, did the port of Opera to X. I guess you should mail them can tell them it's "inconsiderate" for them to use their own toolkit.
Qt is probably the best designed toolkit for X. Go look at the qt source, then the motif source, then the CDE source (I realize the second two don't generally let you see the source for them, and let me tell you there's a reason for that), then come back.
Actually it is. The idea of using an WIMP (windows-icons-mouse-pointer IIRC) GUI without the mouse, and hence without the pointer is fairly evil. The command-line lends itself to this far better to this type of use.
Huh? What's this about a Debian FreeBSD port? I knew about the Debian/HURD thing, but never paid much attention. The HURD is vaporware at its finest. HURD development started before linux came about, and has still not met half of what it promises. As it stood the last time I looked at it, it was a nice fun toy for when you want to do a bit of kernel hacking, but it was nowhere close to done even now...and they've been going at it since around 1990. FreeBSD, though, is a real, living, working system. I'm currious what the debian folks are doing with it.
First of all having had some expirience with trusted systems that were sold to some military organizations, I can tell you that military organizations don't all run the same system. They use many different systems.
Second, CDE as a standard is more as an extention of the Motif API. The Lesstif people plan to implement this, but haven't started, and have plenty of work with plain old motif to do before they move on. xfce does not implement any of the CDE API--it's just a clone of the horrible UI (not the horrible code). So, basically, your example doesn't hold water.
Of the things one could clone why the CDE? The CDE is ugly. The CDE is slow (although xfce is faster). The CDE is some of the ugliest source I've ever seen. The CDE is a poor, counterintuitive user interface even when compared to something like fvwm. A lot of other user interfaces (windows, MacOS) are pretty decent, but lack flexibility. The CDE also is not flexible, but has extra flaws in addition. Why the hell would someone want to clone the CDE of all things? At least the KDE and GNOME people tried to take the good points of every GUI and combine them. The CDE does the exact opposite, it takes the worst points of every GUI and combines them. I've never understood why people use CDE, and I can't understand why anyone would want to make a clone of it. I mean with xfce they solved the speed problem, but since it's not heavily tied to motif, like CDE is, and since the CDE libraries aren't available, you don't even get access to CDE apps, you just clone what is perhaps the worst UI still actively maintained.
I'm currious if the list of processes will be as configurable under 2.0 as 1.0. Every screenshot I've seen shows the list as an applet of some sort in the panel. This is the way Gnome does it. The panel seems to have integrated some nice gnome-like features (it's good to see the two projects pushing each other to improve), however, the process list being there in Gnome is one of the worst, most poorly thought out parts of Gnome. In fact the whole idea of the windows-like bottom of the screen fixed-size process list is extremely stupid. The ability for the KDE to put its process list at the top-left corner, and let it expand down is a great feature. KDE and BeOS use a similar type of interface for this, and its a good one. I'd hate to see KDE go from doing the right thing to the wrong one. Perhaps I'll download krash just to check this out, and bitch (or write some code) if it doesn't.
Stow has the right concept, but its behind on its implementation. Check out encap (http://encap.cso.uiuc.edu). Basically, 3 or 4 years ago encap was at the state that stow is now, a perl script that handled this stuff, without many wistles and bells. Two newer implementations, encapper, and later epkg were written in C to be faster, more efficient, and more featureful. epkg is the only one I know of that is still being actively maintained. Encap is really a great system, and has let me keep from reinstalling for several years now.
Slashdot Mirror
Well, I use it for data today.
Trust me it can do 1X. The entire Kyocera 22xx line is a 1X line (Verizon uses the 2235 for their Express Network service). I suppose Sprint could refuse to offer "vision" service with this phone, but the phone itself is capacble of doing it.
Also, CNET reviews tend to suck and be grossly incomplete.
There were non-technical reasons behind this. For one thing NTT bought a big chunk (about 20%) of ATT Wireless. Literally a couple of days later ATT announced they were doing GSM not CDMA (they were undecided before). Not surprisingly NTT is a big GSM->GPRS->UMTS backer. ATT also soon after jusmped on the iMode bandwagon (not too bad of a bandwagon to jump on). The end game of UMTS is a good one. However, GSM is definitely showing its age, and it's going to be a slow and rocky path for the GSM people to get to UMTS, while the migration for CDMA is much nicer.
Sprint has been offering the Kyocera 2255 for many months now, and it is 1X compatable. I bought one for this reason. It's a decent phone, no big bells and whistles, but it won't go obsolete and it's a nice little phone.
My guess would be about the same as normal SprintPCS wireless web service with a laptop, which is you can get it to work (I use it all the time), but you may hit some limitations (they had some semi-neat image compression for http connections that made it semi-bearable to use that didn't have a linux client). It shouldn't matter, we're talking about open standards here.
Well you can use the technology with your laptop. I don't see why everyone thinks that if your data is being transmitted via cell phone, the cell phone has to be the final displaying device.
Also, I know it's not a popular thing to say here, but Microsoft's Smartphone group has come up with a fairly impressive product if you do want to use your phone as the endpoint.
This is also wrong.
The upgrade from a BPSK CDMA system to a QPSK CDMA system is totally different and quite a bit easier than the upgrade from a TDMA system to a CDMA system. Thus, the GPRS->UMTS evolution is quite a bit more complex than the relatively straightforward IS-95->IS-2000 evolution.
A few minor fact corrections (I won't comment on the opinions).
IS-95B is in use in Japan. KDDI offered the service, though 1X kind of obsoletes this.
I have heard no one talk about deploying 3X in the forseeable future. 1X, 1X-EX-DO, and 1X-EX-DV are in the works though.
To correct a replying poster too, despite the name 1X-EX-DO does not imply the phone would have to be data only, only that the standard is data only. It would still allow you to talk to a vanilla 1X base station, though this might not be the same base station you were talking to for data.
There is a substantial difference. The basic pieces of 1X evolve up to meet this requirement. The ITU standard defines "mega cells" (cells that cover the entire planet or at least something like a continent), "macro cells" (regions) "microcells" (local areas) and "pico cells" (like an office, home, or small park, the kind of area that an 802.11 network might cover today). The requirements are 9.6kbs for mega 144 for macro 384 for micro and 2 mbit/s for pico.
The requirements require that one should be able to seemlessly handoff between these various types of cells.
1X meets the requirements down to macro. 1X-EV-DO (Qualcomm's proposal, formerly HDR) and 1X-EV-DV (Motorola's proposal, formerly 1XTREME), cover the smaller cells and meet the requirement. Thus 1X evolves as a standard to meet the 3G requirment.
GPRS is totally different. GPRS simply is a hack on GSM. It involves ganging together timeslots to up the datarate. What you have now is as far as it goes, end of the line. The GSM folks envison UMTS (W-CDMA) replacing GPRS into the future. However, this is a totally different system. In fact it's CDMA-based while GSM/GPRS is a TDMA system. GPRS does not evolve to meet the ITU's requirements.
Actually I know of no one using 1X to transmit better voice quality. This is generally the result of better vocoders. IS-95 or 1X most are still using 14k or 8k vocoders.
...and even if you wouldn't the voice capacity increase makes it good for you. Wins all alround.
However, from a voice standpoint, 1X does increase the number of calls possible on a given carrier. This means more efficient spectrum utilization, which in theory should mean lower end user cost.
However, as you mention higher data rates, means exactly that, high data rates while moving. You no longer have to be tied down to a wireline or a limited range 802.11 network. One is totally freed to go where they please. You can't tell me you've never wanted to have a semi-decent network connection while in a car, on a train, on a bus, or in an airport. Now you can. To me that is pretty cool, and is why I thought highly enough of 3G to take a job related to it. I'd use it. Wouldn't you?
Apparently you missed that announcement that QT2.2 will appear for download Weds, Sept. 6, which depending on when you read this, may be now.
Let it rest. This is all so rediculous.
Whn it's done (though they hint probably sometime this month if all goes well).
To the best of my knowledge Matador Records is in no way associated with the RIAA. They also are the home to a number of really great artists. Yo La Tengo, which is on their label, is one of my favorites. Older music by Guided by Voices, another favorite band of mine, is also still on their label, although I believe more recently GBV moved to TVT.
It is not a subsidiary of another company. She is the sole proprieter and owner of Righteous Babe Records, and as far as I know the only artist on the label. Ani DiFranco is a truly _independent_ artist.
No, you don't understand what you're talking about. Both UNIX and NT are C1 systems. They offer the traditional discressionary access control: file permissions or acls. B1 is fundamentally different. MAC may sound like ACLs with documentation, but it is not. In DAC a file's access is controlled at the discression of the user (hence the name). Basically, if you and I are on the same system, I can let you see my file. In MAC, if you shouldn't be seeing my file, you won't. The system assigns a sensitivity label to the file. Think of it like the difference between a file in your filing cabinet and a file at a military institution. If you have a file in your cabinet that you wrote, you can let me read it or write to it if you desire. If it's at a military base, and its stored there, you need a certain clearance level to enter where the file is and read it. If I have Top Secret clearance, and you only have Secret, no matter how much I want you to read the file, you can't, and I can't make you Top Secret. It's a forced analogy but you get the point.
Documentation is required to confirm correctness and to specify how requirements were met. There's a lot of modification to the code.
In truth, I'd be surprised if FreeBSD wanted this in the core OS. A B1 level of security can get quite annoying in situations where security is not your paramount goal. There is a lot of extra overhead to do MAC checks and MAC intentionally sort of puts people in a prison.
The Orange Book is not simple either, and reading the glossary is not a substitute for reading the book (which I have not). It's very thick and extremely detailed.
You're assuming mistakenly that the checks are done somewhere in user space, such as in the shell or in cat. This is not the case. The checks are done in the kernel. Thus in the example given you would be able to open the two files but if you fread to a, the kernel will not allow you to write that info to b, but instead will return an error if the SL of the file you are trying to write to is bellow the one you have read from. Labels permeate the system, labeling files, processes, et al.
At least with encap, encap binary packages are quite available. As for dependencies, it is true those are not handledas much. However, in general many package management systems do a bad job with this. I end up using the force options to rpm a lot when I use it.
Right idea, wrong tool. See encap http://encap.cso.uiuc.edu. Stow and encap were developed completely independent of each other, but came up with the right idea. The difference is epkg, the current encap implementation, is far more featureful and far faster than stow. It's really a generation ahead.
The WINE project was going on when I first started using linux about 4 years ago. Opera for linux development started last year. The fact that the two are even comparable gives the edge to Opera.
Umm....Toll Tech, the makers of qt, did the port of Opera to X. I guess you should mail them can tell them it's "inconsiderate" for them to use their own toolkit.
Qt is probably the best designed toolkit for X. Go look at the qt source, then the motif source, then the CDE source (I realize the second two don't generally let you see the source for them, and let me tell you there's a reason for that), then come back.
Actually it is. The idea of using an WIMP (windows-icons-mouse-pointer IIRC) GUI without the mouse, and hence without the pointer is fairly evil. The command-line lends itself to this far better to this type of use.
Huh? What's this about a Debian FreeBSD port? I knew about the Debian/HURD thing, but never paid much attention. The HURD is vaporware at its finest. HURD development started before linux came about, and has still not met half of what it promises. As it stood the last time I looked at it, it was a nice fun toy for when you want to do a bit of kernel hacking, but it was nowhere close to done even now...and they've been going at it since around 1990. FreeBSD, though, is a real, living, working system. I'm currious what the debian folks are doing with it.
First of all having had some expirience with trusted systems that were sold to some military organizations, I can tell you that military organizations don't all run the same system. They use many different systems.
Second, CDE as a standard is more as an extention of the Motif API. The Lesstif people plan to implement this, but haven't started, and have plenty of work with plain old motif to do before they move on. xfce does not implement any of the CDE API--it's just a clone of the horrible UI (not the horrible code). So, basically, your example doesn't hold water.
Of the things one could clone why the CDE? The CDE is ugly. The CDE is slow (although xfce is faster). The CDE is some of the ugliest source I've ever seen. The CDE is a poor, counterintuitive user interface even when compared to something like fvwm. A lot of other user interfaces (windows, MacOS) are pretty decent, but lack flexibility. The CDE also is not flexible, but has extra flaws in addition. Why the hell would someone want to clone the CDE of all things? At least the KDE and GNOME people tried to take the good points of every GUI and combine them. The CDE does the exact opposite, it takes the worst points of every GUI and combines them. I've never understood why people use CDE, and I can't understand why anyone would want to make a clone of it. I mean with xfce they solved the speed problem, but since it's not heavily tied to motif, like CDE is, and since the CDE libraries aren't available, you don't even get access to CDE apps, you just clone what is perhaps the worst UI still actively maintained.
I'm currious if the list of processes will be as configurable under 2.0 as 1.0. Every screenshot I've seen shows the list as an applet of some sort in the panel. This is the way Gnome does it. The panel seems to have integrated some nice gnome-like features (it's good to see the two projects pushing each other to improve), however, the process list being there in Gnome is one of the worst, most poorly thought out parts of Gnome. In fact the whole idea of the windows-like bottom of the screen fixed-size process list is extremely stupid. The ability for the KDE to put its process list at the top-left corner, and let it expand down is a great feature. KDE and BeOS use a similar type of interface for this, and its a good one. I'd hate to see KDE go from doing the right thing to the wrong one. Perhaps I'll download krash just to check this out, and bitch (or write some code) if it doesn't.
Stow has the right concept, but its behind on its implementation. Check out encap (http://encap.cso.uiuc.edu). Basically, 3 or 4 years ago encap was at the state that stow is now, a perl script that handled this stuff, without many wistles and bells. Two newer implementations, encapper, and later epkg were written in C to be faster, more efficient, and more featureful. epkg is the only one I know of that is still being actively maintained. Encap is really a great system, and has let me keep from reinstalling for several years now.