Even the best language in the world would benefit from the facilities that an IDE brings - syntax hilighting, code completion, refactoring, integrated source control, incremental builds, error hilighting, integrated bug / task management, wizards, formatting, build / clean / deploy, multiple projects, interactive debugging, etc. etc. etc.
You'd have to be a masochist to choose a basic syntax hilighting editor over an IDE without an extremely good reason. I realise there are a lot of good reasons but a language so perfect that an IDE is unnecessary is not one of them.
It should be possible to assign a trust level to an app - implicit (for apps baked into firmware), trusted or untrusted. The default level might be the untrusted group which requires manual confirmation each time the app does something potentially bad. But a user could change the trust level manually either from the confirmation or from the Apps settings.
Freedom is good but the security model in Android still sucks. It needs something akin to UAC for at least for voice and SMS so that malicious apps simply can't perform an action without explicit user permission.
Application compatibility is a nice win for x86 BUT.. the truth is you'll likely not want to run desktop applications on a tablet anyway.
I'd love to be able use a tablet on the go but be able to plug in a mouse / keyboard, or park it in a dock and suddenly it becomes a desktop PC. This is a massively useful concept.
I like Android a lot, but I also recognize how limited the experience is even with a mouse and keyboard. I think Microsoft would have a winner if Windows 8 ran on tablets which were actually competitively priced against Android models. However I'm not so sure this will happen for some time and in the meantime we have Windows RT which really isn't so compelling.
An Asus transformer could be used in the way I suggest. The keyboard is attached to the tablet with a stiff hinge so works much like a laptop albeit one with a higher centre of gravity. I believe Asus are even doing a Windows based transformer. I'm just pointing out that the Surface for all its supposed design prowess might actually suck quite a bit for real world use with people being forced to use the on screen keyboard even when they want to use the cover.
If you run older hardware, what's the big rush to upgrade to a dist offering shiny new desktop any way? Install Debian, stick a light WM on it, or stick with an older dist which the hardware is capable of running.
I imagine that if you were attempting to balance this thing on your knees, e.g. in bed, or in an airport lounge that this keyboard and stand would be a huge pain in the ass. I doubt it would work so great in lecture halls on those thin tables between seats or airline clip trays either for that matter.
Ceefax / Oracle et all sent packers attached to scanlines which were usually hidden in the overscan area. It's possible that the TIVO reencoded the analogue signal and cropped all that stuff out. VCRs probably just blindly copied the overscan area but due to degradation and lack of error checking, it was hit or miss if it survived. Teletext could also be incredibly flakey with a poor reception.
On digital streams IIRC teletext was sent as packets in the stream and the SoC would reconsitute the packets into the output signal in the overscan area so the TV could see them. Some STBs might also be able to show teletext through their own software.
Subtitles are now included in the transport stream as bitmaps. Some programmes will also have a separate audio track for partial sighted / blind people.
The BBC has moved to digital "teletext" which is basically the same service sitting over MHEG-5. So instead of news headlines as pure text you get news headlines as text and a thumbnail graphic. Instead of a weather forecast rendered in blocks, asterisks and slashes in garish mode 7 colours you get a nice picture. Theoretically it's more powerful since it can embed graphics and text, is interactive and can even use picture-in-picture and switch video streams. But it's still primitive compared to HTML + JS markup and I can't see this service lasting 38 years.
The issue is compounded because it's quite slow. Most boxes I've used are not caching the content so feeling reminds me of teletext circa 1980. You have to sit there for ages waiting for the carousel to deliver the content the box is waiting on. To improve responsiveness the data stream has to keep repeating the indexes and main content more frequently. It also doesn't work with recorded content since most PVRs strip out the data stream unlike Ceefax which would survive. I assume some boxes would cache content so the responsiveness could be improved.
The main other use of Ceefax was subtitles, and subtitles are handled through a different mechanism. Transport streams from the BBC contain a subtitle track and often also a separate narration audio track too for blind people.
5 actors, doubtless paid large sums of money, appear together on stage for the second time in the space of 4 months. It's of earth shattering importance.
I expect most Linux dists will provide backends X11 and Wayland for QT / GTK and the code will intelligently pick the right one according to the context at runtime. Eg if DISPLAY isn't set or pointing locally it tests for and uses Wayland otherwise X11. Further out someone will produce a working network transport for Wayland and all that be slotted in somehow.
I think I addressed that in the para below - " X already something like this in GLX which sends OpenGL commands over a transport from the server to the client (i.e. from the X client to the X server in X's back to front parlance)."
I'm aware of X11's back assward definition of client and server but usually people would expect the server to be the thing where the process is located and sending the data, and the client to be display it.
Anyone who has looked at the utterly ludicrous and swingeing bandwidth caps and the data rates of 4G would have seen this coming. I really don't see ANY reason for these high speeds unless it comes with a monthly cap of at least 50GB or more to justify it.
X11 stopped performing well a long time ago. All the primitives X11 provides for drawing fonts and drawing lines & rectangles are arcane and obsolete and aren't even used any more. QT and GTK render their graphics and fonts to a bitmap on the server and send the bitmap over the wire. So X11 imposes a CPU and memory penalty on the server and a network penalty to send all this data. When that's the starting position, it's hard to see how Wayland could do any worse.
Since Wayland uses an OpenGL ES backend. It's possible to envisage that the client / server make some initial negotiation regarding their respective capabilities and then data is rendered in the server, or in the client or some mix of both. Maybe some clients are "dumb" and everything is prerendered, maybe some are smart and some of the load and bandwidth can be offloaded to them, e.g. textures and shaders might reside in the client.
X already something like this in GLX which sends OpenGL commands over a transport from the server to the client (i.e. from the X client to the X server in X's back to front parlance). It seems perfectly reasonable to consider that Wayland could do something similar.
Wayland doesn't take away network transparency. X11 can run over Wayland. It's likely Wayland will get its own network transport in time too and it'd probably be more efficient too simply by virtue that GTK / QT send prerendered bitmaps around over a remote connection whereas Wayland could potentially send the drawing primitives.
So exactly why does Wayland preclude running remotely? The answer of course is it doesn't. Nor does it preclude somebody running X11 transparently over Wayland (just like X11 will run over Windows / OS X) if they need it but sparing the rest of us who don't need it.
X11 absolutely needs replacing. It was designed for the time when a desktop consisted of 2D rectangles controlled by a damage model, where fonts were raster graphics and apps were content to draw graphics with simple primitives. It's simply not suited to for a modern compositing desktop. Much of it isn't even used any more - GTK and QT render their stuff to surfaces, and use GL extensions to recompose the display. X11 is just the arcane glue that holds all this together and imposes its own overheads through extra context switches. It should be done away with.
It doesn't stop X11 from running as a client over Wayland for those who need a remote app and working in practically the same way as it does now. But it does mean the vast majority of people do not need to run it and do not incur the performance penalties from doing so.
No, the perception is that X11 is arcane and it is. All the font and drawing primitives are junk, the rendering engine is stuck in a 2D world of rectangles and damage. Libraries like Cairo, Pango, FreeType, plus a raft of extensions et al were produced to workaround all these limitations. So much of X11 is obsolete and worked around, and what remains adds extra latency and complexity that it is completely valid to consider dumping it entirely.
X11 is a dinosaur and a millstone around the neck of Linux. Huge chunks of it are completely obsolete and what remains is just a bottleneck and extra context switches to drag down performance. The sooner it is dumped the better for Linux. People who really want remote desktops can run X11 as a client over Wayland though eventually Wayland will get a remote protocol which will do away with that requirement too.
To clarify I'm talking of the native GMail client on Android - there isn't one for the Playbook. The web interface runs on the Playbook though and is actually quite slick.
I have a Playbook running 2.1 (the latest firmware) and while the native email client is quite good I wouldn't rate it any better than GMail's client, or even GMail's web interface for that matter.
I really don't see this as a huge threat. Let's assume the worst case, that some people buy a mag stripe reader/writer and use software to program the tickets with bogus data. These tickets might fool automatic barriers but they won't fool a ticket inspector.
I expect most transport systems have inspectors already to catch people jumping barriers or coasting in and out behind other people. So the faker is going to get caught eventually. If they're really unlucky the inspector will compare the printed data on the ticket to the data on the stripe using a portable reader and call the cops.
Some transport systems don't even bother with barriers and rely exclusively teams of inspectors. e.g. Dublin's Luas tramline has no barriers so there is nothing to stop someone riding for nothing. To enforce the ticketing system it is not uncommon to see a team of 4 or 5 ticket inspectors board without notice and systematically sweep the train for either end. People with no tickets risk huge fines so you'd have to be pretty dumb to ride this way, fake ticket or not.
Slashdot Mirror
You'd have to be a masochist to choose a basic syntax hilighting editor over an IDE without an extremely good reason. I realise there are a lot of good reasons but a language so perfect that an IDE is unnecessary is not one of them.
It should be possible to assign a trust level to an app - implicit (for apps baked into firmware), trusted or untrusted. The default level might be the untrusted group which requires manual confirmation each time the app does something potentially bad. But a user could change the trust level manually either from the confirmation or from the Apps settings.
Freedom is good but the security model in Android still sucks. It needs something akin to UAC for at least for voice and SMS so that malicious apps simply can't perform an action without explicit user permission.
Application compatibility is a nice win for x86 BUT.. the truth is you'll likely not want to run desktop applications on a tablet anyway.
I'd love to be able use a tablet on the go but be able to plug in a mouse / keyboard, or park it in a dock and suddenly it becomes a desktop PC. This is a massively useful concept.
I like Android a lot, but I also recognize how limited the experience is even with a mouse and keyboard. I think Microsoft would have a winner if Windows 8 ran on tablets which were actually competitively priced against Android models. However I'm not so sure this will happen for some time and in the meantime we have Windows RT which really isn't so compelling.
An Asus transformer could be used in the way I suggest. The keyboard is attached to the tablet with a stiff hinge so works much like a laptop albeit one with a higher centre of gravity. I believe Asus are even doing a Windows based transformer. I'm just pointing out that the Surface for all its supposed design prowess might actually suck quite a bit for real world use with people being forced to use the on screen keyboard even when they want to use the cover.
If you run older hardware, what's the big rush to upgrade to a dist offering shiny new desktop any way? Install Debian, stick a light WM on it, or stick with an older dist which the hardware is capable of running.
I imagine that if you were attempting to balance this thing on your knees, e.g. in bed, or in an airport lounge that this keyboard and stand would be a huge pain in the ass. I doubt it would work so great in lecture halls on those thin tables between seats or airline clip trays either for that matter.
Does that mean that in addition to enduring stupid unskippable Nvidia clips playing when games start we can look forward to the same from AMD?
On digital streams IIRC teletext was sent as packets in the stream and the SoC would reconsitute the packets into the output signal in the overscan area so the TV could see them. Some STBs might also be able to show teletext through their own software.
Subtitles are now included in the transport stream as bitmaps. Some programmes will also have a separate audio track for partial sighted / blind people.
The issue is compounded because it's quite slow. Most boxes I've used are not caching the content so feeling reminds me of teletext circa 1980. You have to sit there for ages waiting for the carousel to deliver the content the box is waiting on. To improve responsiveness the data stream has to keep repeating the indexes and main content more frequently. It also doesn't work with recorded content since most PVRs strip out the data stream unlike Ceefax which would survive. I assume some boxes would cache content so the responsiveness could be improved.
The main other use of Ceefax was subtitles, and subtitles are handled through a different mechanism. Transport streams from the BBC contain a subtitle track and often also a separate narration audio track too for blind people.
5 actors, doubtless paid large sums of money, appear together on stage for the second time in the space of 4 months. It's of earth shattering importance.
I expect most Linux dists will provide backends X11 and Wayland for QT / GTK and the code will intelligently pick the right one according to the context at runtime. Eg if DISPLAY isn't set or pointing locally it tests for and uses Wayland otherwise X11. Further out someone will produce a working network transport for Wayland and all that be slotted in somehow.
I think I addressed that in the para below - " X already something like this in GLX which sends OpenGL commands over a transport from the server to the client (i.e. from the X client to the X server in X's back to front parlance)." I'm aware of X11's back assward definition of client and server but usually people would expect the server to be the thing where the process is located and sending the data, and the client to be display it.
Anyone who has looked at the utterly ludicrous and swingeing bandwidth caps and the data rates of 4G would have seen this coming. I really don't see ANY reason for these high speeds unless it comes with a monthly cap of at least 50GB or more to justify it.
Since Wayland uses an OpenGL ES backend. It's possible to envisage that the client / server make some initial negotiation regarding their respective capabilities and then data is rendered in the server, or in the client or some mix of both. Maybe some clients are "dumb" and everything is prerendered, maybe some are smart and some of the load and bandwidth can be offloaded to them, e.g. textures and shaders might reside in the client.
X already something like this in GLX which sends OpenGL commands over a transport from the server to the client (i.e. from the X client to the X server in X's back to front parlance). It seems perfectly reasonable to consider that Wayland could do something similar.
Wayland doesn't take away network transparency. X11 can run over Wayland. It's likely Wayland will get its own network transport in time too and it'd probably be more efficient too simply by virtue that GTK / QT send prerendered bitmaps around over a remote connection whereas Wayland could potentially send the drawing primitives.
So exactly why does Wayland preclude running remotely? The answer of course is it doesn't. Nor does it preclude somebody running X11 transparently over Wayland (just like X11 will run over Windows / OS X) if they need it but sparing the rest of us who don't need it.
It doesn't stop X11 from running as a client over Wayland for those who need a remote app and working in practically the same way as it does now. But it does mean the vast majority of people do not need to run it and do not incur the performance penalties from doing so.
No, the perception is that X11 is arcane and it is. All the font and drawing primitives are junk, the rendering engine is stuck in a 2D world of rectangles and damage. Libraries like Cairo, Pango, FreeType, plus a raft of extensions et al were produced to workaround all these limitations. So much of X11 is obsolete and worked around, and what remains adds extra latency and complexity that it is completely valid to consider dumping it entirely.
X11 is a dinosaur and a millstone around the neck of Linux. Huge chunks of it are completely obsolete and what remains is just a bottleneck and extra context switches to drag down performance. The sooner it is dumped the better for Linux. People who really want remote desktops can run X11 as a client over Wayland though eventually Wayland will get a remote protocol which will do away with that requirement too.
To clarify I'm talking of the native GMail client on Android - there isn't one for the Playbook. The web interface runs on the Playbook though and is actually quite slick.
I have a Playbook running 2.1 (the latest firmware) and while the native email client is quite good I wouldn't rate it any better than GMail's client, or even GMail's web interface for that matter.
I expect most transport systems have inspectors already to catch people jumping barriers or coasting in and out behind other people. So the faker is going to get caught eventually. If they're really unlucky the inspector will compare the printed data on the ticket to the data on the stripe using a portable reader and call the cops.
Some transport systems don't even bother with barriers and rely exclusively teams of inspectors. e.g. Dublin's Luas tramline has no barriers so there is nothing to stop someone riding for nothing. To enforce the ticketing system it is not uncommon to see a team of 4 or 5 ticket inspectors board without notice and systematically sweep the train for either end. People with no tickets risk huge fines so you'd have to be pretty dumb to ride this way, fake ticket or not.
This is what happens when you dig too deep for mithril.