Do you think Telecom Developers are the same as Telecoms?
Sorry, I forgot that in USA the companies are people too. Especially telecoms who just have life of their own, completely independent from the the people who actually work there.
LOL. Apple has hired quite a lot of telecom developers back then. That's how first rumors about iPhone have started: journalists/etc seen the job openings at Apple.
Or you think developers of all kinds grow on trees?
I haven't followed Tizen much previously. As far as I know, it picked up quite a lot from other previous Linux-based mobile OSs. Samsung AFAIK played big role in the push into mobile phones by bringing in the components from Bada (the interface for non-native, managed run-time) and also the Android compatibility layer. (Interesting bit: Nokia provided to Tizen the navigation app and maps.)
My interested in Tizen piqued only recently, when updates for Google Apps started removing functionality and crippling battery life. And when I actually have tried Google's Android Pure phones and realized just how much work the OEMs invest into making out of it something tad more useful. Samsung/Sony/HTC/LG have quite a lot of expertise in the area apparently and it is absolutely feasible for them to develop a mobile OS on their own.
By whom do you think the telecom developers are employed?
Telecoms do lots of development and are involved in lots of connected things. There is no way around it.
Anyway, I'd rather first wait for the Tizen phones to arrive and then evaluate them. Considering the race to bottom Google has choosen as a path forward for Android, Tizen might get a fair chance in the market. That, of course, if the Tizen would be even comparable to Android.
Samsung Wave phones were pretty decent phones. No, not phablets with gazzilion of everything and the kitchen sink. Just a very good smartphone, with decent browser and some level customization.
On top of that, the whole premise "Samsung develops new mobile OS" is bogus. It might have been the case with Bada, but not the case with the Tizen:
The Tizen Association formed to guide the industry role of Tizen, including requirements gathering, identifying and facilitating service models, and overall industry marketing and education.[4] Members of the Tizen Association represent every major sector of the mobility industry and every region of the world. Current members include operators, OEMs and computing leaders: Fujitsu, Huawei, Intel Corporation, KT, NEC CASIO Mobile Communications, NTT DOCOMO, Orange, Panasonic Mobile Communications, Samsung, SK Telecom, Sprint and Vodafone.
What's more, Tizen isn't particularly "new". Not only there are tried bits of LiMo and Bada inside, but there were already several releases for the "In-Vehicle-Infotainment".
I've seen the cost sheets. It's not dominant cost by far. E.g. I work in relatively expensive location (which is the cheapest location within city bounds you can find) and the rent for a large floor in the office complex (good for ~120 pople) costs per year about the same as an average mid-manager. Yet company's management layers gets fatter and fatter every reorg - while they constantly try to "optimize" the office space usage.
The "office space is expensive" excuse doesn't work for most location very long time now. Literally all cities have special programs to attract blue collar workforce and offer very generous rates for mid- to large-sized companies. I know that for a fact about Germany (where I work) and China (where we previously had an office). Never seen any hard data about India, but I doubt it is much different there.
Do what I do: replace any mention of "mission critical" with "business critical".
But even then, miscompiles do happen with literally every compiler and are hardly "business critical". One miscompile can't bring the company down. Unlike, for example one melt-down nuclear reactor.
If tests haven't exposed the problem, then it is rather lack of testing which is the problem.
I can confirm this. My Google Talk also started showing "Nick First Last" names instead of just the Nick.
Luckily I had purged my real name from there long time ago - when I noticed that it was exposed via my blog hosted on the blogger.com . Still the junk I used showed up in other people's GTalks.
Still, it took me quite sometime to figure out what to put there: it turned out that the last name field is optional, and if you fill in the first name with the nick, then it works as before.
And no, my gmail account never ever touched anything of the Google, the Social.
Here is the page. It is whyever not accessible from my GMail, but clicking "Account Settings.." in GTalk brought it up.
Chasing users that want to play old games is a quick way to an early death.
AFAIU Valve isn't "chasing users" with the old games. That is a merely sideeffect of porting of their software to Linux plus H/W requirements being set that any relatively recent PC with nVidia graphics would do. That's the beauty of it: you are not required to buy new H/W.
Many old games are real cheap and, believe me, the $5 is a better deal than the hours of troubleshooting why the darn thing won't start under Win7/Win8.
Considering the very low entry price (buy and plug new HDD(*) into my rig, install SteamOS) I actually might do it over a week-end just to kill the boredom by playing some of the sentimental junk.
(*) Or even cheaper: pick old (potentially failing) HDD from the pile on the shelf.
...are still much more secure than code written in C++. There are no stack or heap overflows to worry about, no double frees.
Ah, here we go again: poorly written C++ is worse than poorly written Java.
Coming from network daemons, frankly, I see more often how Java developers manage to fsck-up the most trivial things. All in the name of the "proper design" and "{buzzwords du jour}" and stuff. Where in C++ I needed one routine for which one code review session was enough to harden it, Java people created instead a net of 12 classes for the task. And there is no end to bugs in this convoluted mess.
In the end, I still blame Java itself. The standard library, though swelling in some parts, in many parts remained very very spartan. I've seen lots of stupid reimplementations in the C/C++ - and I tend to remove them and replace with standard functions. But with Java way too often I get back responses like "there is no standard function for it" or "standard function is way too slow". And more code gets written, causing more code to be written to organize the previously written code. And then even more code is written to organize now this code. And it goes on. End result is, a supposedly simple application, linking three 3rd party libraries, has 250 classes and requires minimum 15 threads and 16GB RAM. And that, before you count the requirements of the 3rd party libraries.
What I'm getting at, is that image of "poorly written Java application" is wrong. It probably doesn't have stack overflows, but sure like hell it has RAM and thread abuse. And blanket exception handling. And vast unparsable nets of objects delegating everything to some other objects making finding what is responsible for what virtually impossible. Making fixing the problems virtually impossible.
I'm not sidestepping anything. The point is that RH will NOT do half of what you suggest. Customers will NOT want most of it too.
The "new features" are often desired by developers, not the customers.
The whole point of RHEL (and the commercial *NIX systems) is to support the long running systems (think 5-10-more years). They are not test beds for new fancy shit. (For that you have Fedora/etc.) They are for production systems, with support options optimized not for developers/ISVs, but for the customers actually running the software. And why would ever customer care what version of Python is installed on their production servers?
This is totally different market where developer who says "we want that and this" does not survive for very long. (That is typical talk of the bug multi-nationals, their usual lack of flexibility and the reason why they eventually disappear.) What normally happens is the reverse: developer asks "what you run? OK, that would cost you that much."
Asking RH to provide something in RHEL I expect would result in them saying "upgrade to RHELn.m" or "it would be only supported in future release RHELn.m".
I do not have any vast experience to extrapolate - only one minor incident, where we were told that "not available in 5.1, but it would be in the RHEL5.3". IIRC glibc header was missing a definition.
You also largely miss the point of why the stuff is "not available". Or rather the whole train of thoughts is in wrong direction. The new stuff is not available, because the production server configuration is frozen once it is in production. Even if I had such update from RH, I wouldn't install it in production anyway: risk is simply too high.
I don't have any experience with Python, but with kernel and glibc, they always keep the original version number and binary compatibility, but backport fixes/features/etc from higher versions.
That occasionally leads to some amount of confusion when one tries to rely on the version numbers to workaround known bugs or detect supported interfaces.
From the description it seem to require special RDP server (FreeRDP 1.0). Is that so? Or would it work with the plane Win7 remote desktop service? (Fastest for me to test.) (I'm not sure that our RHEL boxes have the RDP service at all.)
Does it support several connections/applications in parallel? The normal Windows RDP allows only one connection, kicking out previous connection is necessary.
Tizen already does it for some time. There were already a number of Tizen release - for IVI.
I think Google has recently read a press release about Tizen on mobiles. They have looked it up and found out that it is already available and used in IVI market for few years now.
Or, the claimed "Android App compatibility" Tizen 3.0 feature might have gotten them worrying. So they have decided to jump on it before it gets too big.
You should have checked the prices first. Or used a price matching site where one can easily filter by "non-glare" and "Android".
Panasonic Toughpad starts at around €900 for 7" device. (10" costs €1100 and does NOT have matte display.)
Bit too much for a content consumption device, don't you think? (Comparable normal, non-tough 10" tablet would cost at most €500.)
P.S. Also HP (Android) and Fujitsu (Win8) appear to produce on and off tablets with matte screen. Also ViewSonic (ViewPad 10e). But try to find the "non-glare" or "matte" in the official spec sheet... I have tried with no luck.
I have tried some plain media consumption on my current Android phone and technically there are very little problems. (No built-in samba is probably the biggest minor "glitch", but there are some solutions to that.)
But the overall experience is simply ruined by the glossy screen. It is the worst with the movies: half time you wonder if it is some detail in the movie - or it is reflection of something - or just my face. It's like frigging mirror.
Until they start producing devices with matte screens, I'm absolutely not interested in tablets.
P.S. Yes, I know about the matte screen protectors, but they are all fiddly to apply and in case of large device it is mission impossible to apply such protector without bubbles or dust specks. And the screen protectors eventually peel off - more you use the device, sooner.
You and your friends are a tiny fraction of the overall number of X users. You are insignificant in the face of our needs.
Not true.
The not "tiny fraction of the overall" desktop users are migrating in droves to tablets/etc.
Last time I checked neither Android, iOS nor Windows 8 employ X or Wayland.
That is kind of the problem with the change Wayland brings: the people who need it most in two 2-5 years time would be 90% on tablets.
The only notable exception is the SteamOS and gaming. But it, if it lives on, would be guaranteed to be a fork, living in its own universe. And that's the only place where I see any kind of potential for Wayland.
And that leaves us with the same set of people who started with *NIX 40 years, Linux 20 years ago: engineers. Engineers do not need Wayland. Engineers need a tool and they need the most flexible most configurable tool possible. Not shiny animated buttons or wobbly windows.
Slashdot Mirror
Do you think Telecom Developers are the same as Telecoms?
Sorry, I forgot that in USA the companies are people too. Especially telecoms who just have life of their own, completely independent from the the people who actually work there.
Idiot.
Imbecile.
LOL. Apple has hired quite a lot of telecom developers back then. That's how first rumors about iPhone have started: journalists/etc seen the job openings at Apple.
Or you think developers of all kinds grow on trees?
I haven't followed Tizen much previously. As far as I know, it picked up quite a lot from other previous Linux-based mobile OSs. Samsung AFAIK played big role in the push into mobile phones by bringing in the components from Bada (the interface for non-native, managed run-time) and also the Android compatibility layer. (Interesting bit: Nokia provided to Tizen the navigation app and maps.)
My interested in Tizen piqued only recently, when updates for Google Apps started removing functionality and crippling battery life. And when I actually have tried Google's Android Pure phones and realized just how much work the OEMs invest into making out of it something tad more useful. Samsung/Sony/HTC/LG have quite a lot of expertise in the area apparently and it is absolutely feasible for them to develop a mobile OS on their own.
By whom do you think the telecom developers are employed?
Telecoms do lots of development and are involved in lots of connected things. There is no way around it.
Anyway, I'd rather first wait for the Tizen phones to arrive and then evaluate them. Considering the race to bottom Google has choosen as a path forward for Android, Tizen might get a fair chance in the market. That, of course, if the Tizen would be even comparable to Android.
Samsung Wave phones were pretty decent phones. No, not phablets with gazzilion of everything and the kitchen sink. Just a very good smartphone, with decent browser and some level customization.
On top of that, the whole premise "Samsung develops new mobile OS" is bogus. It might have been the case with Bada, but not the case with the Tizen:
The Tizen Association formed to guide the industry role of Tizen, including requirements gathering, identifying and facilitating service models, and overall industry marketing and education.[4] Members of the Tizen Association represent every major sector of the mobility industry and every region of the world. Current members include operators, OEMs and computing leaders: Fujitsu, Huawei, Intel Corporation, KT, NEC CASIO Mobile Communications, NTT DOCOMO, Orange, Panasonic Mobile Communications, Samsung, SK Telecom, Sprint and Vodafone.
What's more, Tizen isn't particularly "new". Not only there are tried bits of LiMo and Bada inside, but there were already several releases for the "In-Vehicle-Infotainment".
It's plain greed, you dummy.
I've seen the cost sheets. It's not dominant cost by far. E.g. I work in relatively expensive location (which is the cheapest location within city bounds you can find) and the rent for a large floor in the office complex (good for ~120 pople) costs per year about the same as an average mid-manager. Yet company's management layers gets fatter and fatter every reorg - while they constantly try to "optimize" the office space usage.
The "office space is expensive" excuse doesn't work for most location very long time now. Literally all cities have special programs to attract blue collar workforce and offer very generous rates for mid- to large-sized companies. I know that for a fact about Germany (where I work) and China (where we previously had an office). Never seen any hard data about India, but I doubt it is much different there.
To me the reasons for the open office space are partially explained by this Dilbert strip.
Do what I do: replace any mention of "mission critical" with "business critical".
But even then, miscompiles do happen with literally every compiler and are hardly "business critical". One miscompile can't bring the company down. Unlike, for example one melt-down nuclear reactor.
If tests haven't exposed the problem, then it is rather lack of testing which is the problem.
They should call it the "this is it" version.
Change the codename to "Skyfall" - and they get a title song for free!
I can confirm this. My Google Talk also started showing "Nick First Last" names instead of just the Nick.
Luckily I had purged my real name from there long time ago - when I noticed that it was exposed via my blog hosted on the blogger.com . Still the junk I used showed up in other people's GTalks.
Still, it took me quite sometime to figure out what to put there: it turned out that the last name field is optional, and if you fill in the first name with the nick, then it works as before.
And no, my gmail account never ever touched anything of the Google, the Social.
Here is the page. It is whyever not accessible from my GMail, but clicking "Account Settings.." in GTalk brought it up.
Chasing users that want to play old games is a quick way to an early death.
AFAIU Valve isn't "chasing users" with the old games. That is a merely sideeffect of porting of their software to Linux plus H/W requirements being set that any relatively recent PC with nVidia graphics would do. That's the beauty of it: you are not required to buy new H/W.
Many old games are real cheap and, believe me, the $5 is a better deal than the hours of troubleshooting why the darn thing won't start under Win7/Win8.
And that is bad how? It is actually very good.
Considering the very low entry price (buy and plug new HDD(*) into my rig, install SteamOS) I actually might do it over a week-end just to kill the boredom by playing some of the sentimental junk.
(*) Or even cheaper: pick old (potentially failing) HDD from the pile on the shelf.
Ah, here we go again: poorly written C++ is worse than poorly written Java.
Coming from network daemons, frankly, I see more often how Java developers manage to fsck-up the most trivial things. All in the name of the "proper design" and "{buzzwords du jour}" and stuff. Where in C++ I needed one routine for which one code review session was enough to harden it, Java people created instead a net of 12 classes for the task. And there is no end to bugs in this convoluted mess.
In the end, I still blame Java itself. The standard library, though swelling in some parts, in many parts remained very very spartan. I've seen lots of stupid reimplementations in the C/C++ - and I tend to remove them and replace with standard functions. But with Java way too often I get back responses like "there is no standard function for it" or "standard function is way too slow". And more code gets written, causing more code to be written to organize the previously written code. And then even more code is written to organize now this code. And it goes on. End result is, a supposedly simple application, linking three 3rd party libraries, has 250 classes and requires minimum 15 threads and 16GB RAM. And that, before you count the requirements of the 3rd party libraries.
What I'm getting at, is that image of "poorly written Java application" is wrong. It probably doesn't have stack overflows, but sure like hell it has RAM and thread abuse. And blanket exception handling. And vast unparsable nets of objects delegating everything to some other objects making finding what is responsible for what virtually impossible. Making fixing the problems virtually impossible.
So your point in the last paragraph is ... ?
I'm not sidestepping anything. The point is that RH will NOT do half of what you suggest. Customers will NOT want most of it too.
The "new features" are often desired by developers, not the customers.
The whole point of RHEL (and the commercial *NIX systems) is to support the long running systems (think 5-10-more years). They are not test beds for new fancy shit. (For that you have Fedora/etc.) They are for production systems, with support options optimized not for developers/ISVs, but for the customers actually running the software. And why would ever customer care what version of Python is installed on their production servers?
This is totally different market where developer who says "we want that and this" does not survive for very long. (That is typical talk of the bug multi-nationals, their usual lack of flexibility and the reason why they eventually disappear.) What normally happens is the reverse: developer asks "what you run? OK, that would cost you that much."
Asking RH to provide something in RHEL I expect would result in them saying "upgrade to RHELn.m" or "it would be only supported in future release RHELn.m".
I do not have any vast experience to extrapolate - only one minor incident, where we were told that "not available in 5.1, but it would be in the RHEL5.3". IIRC glibc header was missing a definition.
You also largely miss the point of why the stuff is "not available". Or rather the whole train of thoughts is in wrong direction. The new stuff is not available, because the production server configuration is frozen once it is in production. Even if I had such update from RH, I wouldn't install it in production anyway: risk is simply too high.
That is really quirky under RHEL.
I don't have any experience with Python, but with kernel and glibc, they always keep the original version number and binary compatibility, but backport fixes/features/etc from higher versions.
That occasionally leads to some amount of confusion when one tries to rely on the version numbers to workaround known bugs or detect supported interfaces.
Thanks. I'll check it out.
Couple of quick questions, if you would allow.
From the description it seem to require special RDP server (FreeRDP 1.0). Is that so? Or would it work with the plane Win7 remote desktop service? (Fastest for me to test.) (I'm not sure that our RHEL boxes have the RDP service at all.)
Does it support several connections/applications in parallel? The normal Windows RDP allows only one connection, kicking out previous connection is necessary.
Sticking with system-installed Python means that you need to worry whenever that system decides to update the version of Python that it uses.
"That system" would never "[decide] to update the version of (whatever)" because RedHat provides guarantees of that.
If RedHat would start sending its RHEL users such updates, the next thing the users would do is to migrate to SuSE' SLES or CentOS.
Remember, not every upstream is as fsckd up as GNOME or Mozilla or Google. Even MSFT is much much more sensible in that regard.
Tizen already does it for some time. There were already a number of Tizen release - for IVI.
I think Google has recently read a press release about Tizen on mobiles. They have looked it up and found out that it is already available and used in IVI market for few years now.
Or, the claimed "Android App compatibility" Tizen 3.0 feature might have gotten them worrying. So they have decided to jump on it before it gets too big.
Wow. Support for GNU Arch is really an outstanding feature!
TLA is for all intent and purposes is dead. The .gitignore alone is reason enough to migrate to git.
OK, archives is a very cool feature found literally nowhere else, but it alone isn't enough to sway any decision process in favor of TLA.
What would have I've done without you? </sarcasm>
You should have checked the prices first. Or used a price matching site where one can easily filter by "non-glare" and "Android".
Panasonic Toughpad starts at around €900 for 7" device. (10" costs €1100 and does NOT have matte display.)
Bit too much for a content consumption device, don't you think? (Comparable normal, non-tough 10" tablet would cost at most €500.)
P.S. Also HP (Android) and Fujitsu (Win8) appear to produce on and off tablets with matte screen. Also ViewSonic (ViewPad 10e). But try to find the "non-glare" or "matte" in the official spec sheet... I have tried with no luck.
P.P.S. Link to the British version of the price matching. The German one I use, because I live in Germany.
I have tried some plain media consumption on my current Android phone and technically there are very little problems. (No built-in samba is probably the biggest minor "glitch", but there are some solutions to that.)
But the overall experience is simply ruined by the glossy screen. It is the worst with the movies: half time you wonder if it is some detail in the movie - or it is reflection of something - or just my face. It's like frigging mirror.
Until they start producing devices with matte screens, I'm absolutely not interested in tablets.
P.S. Yes, I know about the matte screen protectors, but they are all fiddly to apply and in case of large device it is mission impossible to apply such protector without bubbles or dust specks. And the screen protectors eventually peel off - more you use the device, sooner.
You and your friends are a tiny fraction of the overall number of X users. You are insignificant in the face of our needs.
Not true.
The not "tiny fraction of the overall" desktop users are migrating in droves to tablets/etc.
Last time I checked neither Android, iOS nor Windows 8 employ X or Wayland.
That is kind of the problem with the change Wayland brings: the people who need it most in two 2-5 years time would be 90% on tablets.
The only notable exception is the SteamOS and gaming. But it, if it lives on, would be guaranteed to be a fork, living in its own universe. And that's the only place where I see any kind of potential for Wayland.
And that leaves us with the same set of people who started with *NIX 40 years, Linux 20 years ago: engineers. Engineers do not need Wayland. Engineers need a tool and they need the most flexible most configurable tool possible. Not shiny animated buttons or wobbly windows.
The spawns of GNOME having poor visuals has nothing to do with X, but rather the GNOME itself.
Just check how animation in the Enlightenment works. And it worked like that for 10+ years now.
The Enlightenment requires only basic 2D H/W acceleration which X has had forever. While GNOME requires 3D/bells and whistles - and still sucks.