systemd versus upstart is mostly anti-canonical sentiment coming home to roost. Canonical has made it clear they don't want to play nice with the wider non-canonical community, and now that's going reciprocal. In a way, systemd and Wayland should be grateful. A non trivial amount of the increased urgency behind migration to those schemes are driven by a distaste for canonical as they push upstart and Mir.
systemd versus sysv init most visibly leads to faster boot (by providing a richer dependency model and avoiding spawning as many processes through skipping shell scripts a lot). The downside should be clear in general, the philosophy leaning more toward compiled modules over shell scripts means it's harder for a lay person to dig in and follow things and understand how they work. If you dig deeper you'll notice that the number of getty processes is lower for most people by skipping spawning such things until the VC is active and other similar things. These are things that really don't meaningfully add to the experience in 99.999% of cases, but it's the sorts of little awkward/arbitrary things that systemd aspires to be a bit more fancy about managing. If a distribution fully embraces systemd philosophy (e.g. Fedora), no more plaintext logfile to peruse. You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.
I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible (ambition to replace at, cron, change from running static number of getty on VC specified by inittab to on demand spawning of getty as auto detected). It's clear they regard users valuing plain text data with some disdain. There is plenty of opportunity to achieve the gains whilst concurrently providing a plain text stream to peruse natively, but they have *zero* interest in trying to pursue such paths.
This is also the brainchild of Lennart Poettering, who has had a track record of getting stuff widely into distribution critical usage path before it's ready (avahi and pulseaudio have given me lots of headaches). Also trying to get DBus into the kernel, which seems absolutely bonkers.
In general, distributions embracing this become increasingly opaque to admins. Distribution behavior flows through an increasingly complex labyrinth of crap that it approaches Microsoft level BS. I'm somewhat disheartened at the possibilities here.
The point being that if you have a cell phone, you have the means of verifying things without need for a physical currency. If you don't have a means of verifying that currency, a 'bitcoin' currency is no more counterfeit resistant than any other currency.
He makes the case for the currency over purely electronic by saying that 3rd world countries won't tolerate cell phones as it's too expensive. At the same time, he wants to trivialize that requirement when it comes to supporting his point of adding value to such a currency since 'anyone with an NFC equipped cellphone' can verify the currency. He comes right back to the same requirement that non-physical bitcoin has, with dramatic differences of opinion of how onerous it is depending on whether he's talking about non-physical or physical medium of exchange.
So for the article, either such infrastructure is out of reach of those markets and thus the physical currency is not inherently more counterfeit proof than anything else, or it is in reach at which point the physicality of the currency is utterly pointless.
Even if you think bitcoin is a reasonable path (I personally don't), this concept is pretty bonkers.
It goes on and on about how the there is no number that can be easily faked. Fiat currency counterfeiters with plain old serial numbers can copy a valid serial number and someone bothering to lookup the serial number could be fooled, not so with Bitcoin. Point taken, but the thing is before that has any value, the recipient of the currency must actually verify that data. There is no point in conveying that info in an expensive physical coin, because such infrastructure could just as easily be fed the data by electronic means or even a printed slip of paper. The physical coin aspect of it becomes the tail wagging the dog, an overpriced way of conveying the counterfeit resistant data. If the data is not actually envisioned to be verified at time of transaction, then it's as useless as the serial number on a dollar.
The only thing holding Bitcoin from exploding in many markets is a lack of a physical incarnation.
Incredibly wishful thinking there. Bitcoin has a lot more problems than lack of a physical incarnation. Being outlawed by major governments, at the mercy of speculators without any regulation, and downright vulnerable to an attack by a critical mass of mining resources working together.
rural farmers in 3rd world countries are not going to get a smartphone and a $100/month data plan just so they can accept Bitcoin.
Exactly! But just a few sentences above it says:
anyone with an NFC equipped cellphone can check if a coin is counterfeit.
You've come round full circle to the problem in the first place: You need functioning internet infrastructure (and a long time) to validate a transaction in the secure way. Without that, you could counterfeit any 'bitcoin' based currency just as easily as any other currency.
A viable alternative currency for micro-nations and dictatorships with hyper-inflation."
Another foolish statement. Again, people are incorrectly assuming there is a technological solution to a socioeconomic problem. The failure of such currencies are a symptom, not a root cause. If it were as simple as all that, the citizens could just as easily move around some stable foreign currency. You can't do a safe, 'sneaky' end run around the force that governs a citizenry. So long as they are empowered to prosecute, shut down internet infrastructure, or just send soldiers into the street, no currency trick is going to work in the face of the fundamental problem.
I think for me the short message is that the X protocol as a remote display protocol no longer provides the optimal remote experience even amongst *nix applications. The solutions that make it workable really involve having an X server running on the same endpoint as the application and picking their favorite protocol to talk back to the client (NX uses X, Xpra uses something else). In the NX case, for whatever reason, they have not delivered a very reliable solution and manage not to convey some key WM hints, so using X as the protocol doesn't seem to make it magically that easy. With that in mind, the question I think moves toward whether or not it makes sense for X11 to define the primary interface between applications running on the same system. I don't really have as much of a horse in that race.
I just think Wayland faces unfair criticism that it doesn't do 'network transparency'. 'Network transparency' refers to the fact that application relationship to the drawing engine is defined in terms where that can be sent over the network directly. People don't really need *that* per se, they need quality seamless remote application support. In Wayland, the relationship between clients and the compositor is decoupled from how the clients are actually displayed. Xpra shows how the COMPOSITE extension in X11 provides the same decoupling and what you can get out of that. The emphasis for those defending Wayland should be "It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor." using Xpra as an example of how that already can be done today. Leading their answer to that with "No, that is outside the scope of Wayland" just pisses people off and gives them the wrong idea (they don't mean to dismiss the scenario, they literally mean that the Wayland specification does not say *anything* about the relationship between compositor and eyeballs, which could be remote, local, who knows, not their problem). So instead of having a 'remote wayland client', you have a 'remote client'.
I know Xpra, it is nice, although I don't need it. But I don't get your point, it uses 'ssh -X'.
No it doesn't. It can tunnel over ssh much like X11 can, but it does not speak X at all between the remote system and local system.
But Xpra speaks X on both sides!
It doesn't though. One one side it talks as a compositor and ICCCM to clients that are going to be displayed elsewhere. The X clients talk X to a dummy X server that runs on the 'remote' end. Then it has it's own protocol to convey encoded graphical content and contextual data gleaned from being the compositor and ICCCM. The client (there's your first clue, the piece that is actually showing the content to someone is indeed a *client*, not a server) talks to the server using that protocol. It then *can* be an X11 client to a local running X server (because in order to be a GUI application in Linux it's pretty much required), but it also can render content on a client with no X server at al (e.g. running on windows without requiring nor including an X server). Xpra acheives great result precisely by avoiding use of X *at all* for network transparency. It is able then to get away with a *much simpler* protocol, trivially provide session persistence, and beat the pants off of ssh -X performance wise to boot.
Which of course leads me to a point of some heresy. I don't know if it's worth it to replace X as the protocol between graphical clients and servers, but I for one think it *is* very much worth it to stop thinking of the X protocol as the best means of providing network transparent remote application access. Yes, RDP doesn't do the job as implemented by microsoft (the per application mode is still not seamless), but Xpra has demonstrated precisely how good remote seamless applications can be in a world without using X as the transport.
Ask the question in text? Even if you made a video asking the question, you'd still be vocalizing the request.
Simply put, when it gets down to it, words are the only thing we can wrap our minds around to convey most concepts. Sure, sometimes a diagram comes into play, but overwhelmingly text is the tool. Same goes for programming. Tools exist to help build UI elements, but the logic is textual. There have been tools to help visualize the relationships in code, but the usage that has persisted is mostly about profiling (I've seen people advocate for other things being visualized, but generally other applications to non-GUI code visualization get old real quick by adding no value but being more cumbersome to wrangle.
That may be beyond the point of diminishing returns. It's true that GTK or QT has the best opportunity to have good primitives for a network connection and provides the ability for remote applications to appear even more seamless with local applications in cases of theme differences, but the work would be a lot more complicated than it was implementing the X primitives that were relevant in the 80s. On addition to being very difficult, the coupling between client and server would be tighter (if application goes to render a widget the display doesn't have due to version mismatch, that could be a problem).
On the otherhand, realtime encode of desktop display is actually pretty serviceable nowadays. You still want the ability to recognize very high level elements for what they are to provide the goodness of network transparency (this is a 'window', a 'dialog', a 'tray icon'), but perhaps not require that the display understand what region of a displayed window is a button versus something else.
I will suggest looking into Xpra. I'm personally wary of RDP as the specific solution unless it deviates from MS design significantly, but Xpra at least seems to me a proof point that the 'ssh -X' way is no longer the only way.
Xpra acheives everything I like about ssh -X, but it performs way better and sessions are not hopelessly broken if the connection is lost. It manages to acheive this by sitting between X server and clients as the window manager/compositor rather than actually using the X protocol to acheive it.
Of course I'm not convinced there is such a dire need to replace X at all, but at least I'm open to the possibility that there is a nice and clean mechanism to add X level network transparency by way of the compositor/window manager rather than the relationship between applications and the display server.
Like many people, my chief concern over Wayland is 'network transparency. Unlike some others, I'm willing to believe there is a light at the end of the tunnel.
Specifically, with X based systems, X remoting is no longer the way I use X remotely, I use xpra as it delivers me a better experience. Unlike something like NX, Xpra does not try to extend or enhance X based protocols, but instead gets content by setting itself as the compositor, knowing things like window relationships to each other and being able to do things like recognizing a tray icon for what it is.
My question is if the same sort of thing would be possible with Wayland today and if people are doing it.
I am entirely amateur hour at this and may have mischaracterized, but I'm willing to hold out hope that the one major fundamental downside of Wayland could be overcome in the same way that Xpra makes X better.
On the one hand, layoffs are frequently considered a 'good thing' by investors, if they believe the company may still be capable of functioning afterward. I don't think Dell is in this boat, but layoffs have upon occasion been taken as a sign of the end times for a particular enterprise.
As to your point about taking it in a new direction as fast as he can, away from a commodity business; the challenge is Dell has yet to show capability in any candidate market. Investors eat up announcements by IBM for decreasing stake in the hardware business because they have shown data that they have already established themselves in other markets. Contrast to when Apotheker announced an intent for him to take HP away from hardware and be a software company. HP's stock took a nosedive because they were not seen as a credible software company, but giving up on their bread and butter to chase a dream. Even if that hardware business isn't as profitable, it's better than nothing.
It's not to say it's a bad thing to reduce needless CPU activity, I was just explaining how this particularly was a strategic move for AMD. The GP was saying 'it's pointless because gamers buy power CPUs', I was simply pointing out that's not what AMD would currently want, since beefy CPU means Intel at this particular point (and really most points since Nehalem came out).
I will say it *could* be a bad thing if it leads to Mantle-exclusive games that are unable to support other GPUs at all (Intel, nVidia, etc).
A server developer can be delusional and think their particular pet technologies are the only ones in the world and that *everyone* is on board. The target users will be non the wiser. About the only aspect that he calls out that is fairly fixed is the notion that *EVERYTHING* must be http based (which I hate, the http protocol was designed around certain usage scenarios and it is atrocious for a lot of uses but it gets shoehorned into them anyway).
Meanwhile, on the client side, if you do want to hit 100% of the market and you have a moderately complex client to do, you may have to do IOS, Android, several different set top boxes (e.g. Roku), game consoles (PS3, Xbox), and Windows (to use netflix as an example).
So gamers get a small boost to their gaming rigs, but that's not *really* the goal for AMD.
The real goal is that AMD demonstrably lags Intel in *CPU* performance, but not GPU. OpenGL/Direct3D implementations cause that to matter, meaning AMD's cpu business gets dinged as a valid component in a configuration that will do some gaming. Mantel diminishes the importance of the CPU to most gaming, therefore their weak CPU offering is made workable to sell their APU based systems. It can do so cheaper than Intel+Discrete GPU while still reaping a tidy profit.
We are talking about a real time application, so even without 100% load over a relatively large sampling interval, performance can be degraded.
Let's assume that you have 2 sequential things that cannot be overlapped. CPU setup and GPU processing. You cannot begin CPU setup of next frame until GPU is done with current frame (gross oversimplification, but there are sequencies that bear some resemblence to this).
So a hypothetical CPU takes 1 ms to setup a frame, and then the hypothetical GPU then takes 4 ms to render it. There's 20% usage CPU wise reported on average over as small a sampling interval as 5 ms, and a throughput of 200 frames per second.
Let's say that the CPU now takes 10 times less time, and takes 100 us to setup a frame, and then the GPU still takes 4 ms to render it. You have gotten about a 20% speedup. Even though the CPU was not fully utililized, it did represent a throttling factor in FPS.
No we don't. We have pretty good rendering, but it is not photo realistic. Show anyone a photograph and a game engine attempt to recreate the scene and there is no engine that could fool anyone right now. But that's not so critical.
very high DPI screens
Very much true for everything *except* strapping it to your head and magnifying the display. Again, we are certainly in the 'good enough to make a go of it' realm.
dirt cheap high accuracy sensing.
Actually, we didn't (well, not at the requisite latency) and that is really the vast majority of Oculus effort was centered around. Working out full motion tracking with a latency acceptable for the application.
But I agree with you, get crystal cove out ASAP...
Then implement an alternative runtime. If that gets backlash and an attempt to subvert the standards to do your bidding also gets backlash, then maybe, just maybe, it's the wrong thing to do. If it is the right thing to do, people will run with it.
The fixation on HTML, CSS, Javascript, and HTTP is unreasonable. In the mobile space, people have returned to applications as a very viable approach. This is the answer to people who want application platforms, use something designed from the ground up to be an application platform rather than a platform that was designed as a hypermedia implementation with goodies for application development grafted on.
Yes, bellyaching about CSS region support was the wrong track. This certainly points to a larger problem. Building an 'application platform' is not what I wanted in a browser.
Just saying that it isn't as 'take your ball and go home' as the writeup sounded.
Of course, just because something is 'standard' doesn't mean it's useful. MS historically was subject to ridicule for discarding a standard and then going on their own and implementing the same functionality in an incompatible way. Here, Google's saying that they don't want to implement any alternative scheme to the same end, just not implement the capability at all. The open source world rarely fully implements any standard (for good reason, many parts of standards are impractical, unused, or in some cases some loophole demanded by a proprietary vendor to be able to declare support for the 'standard' without having to make a lot of effort on their part.
The writeup was intended to disparage Google's decision as going off the rails and abandoning an otherwise widely supported standard feature. That image would have been significantly impaired if it made clear that firefox never supported it in the first place, meaning only Apple and Microsoft really bothered. That fact changes things from 'Google is breaking the web by ignoring widely adopted standards' to 'Google abandons obscure function that not many people can use already'.
The 'standard' is in a non-sabotaged state already. 'Open'Compute was mostly Facebook saying 'this is the right way to address the only requirements that matter (Facebook's). Now MS managed to get their word in and it just gets slipped in, without the slightest hint of trying to reach a consensus on anything.
OpenCompute has been full of either things uselessly specific to one user's needs or alternatively useless problem statements that are blatantly obvious without a hint of a proposed solution.
Basically, vendors and purchasers are probably about as dysfunctional as they ever have been when it comes to standards, no matter what the words 'Open' imply.
Facebook didn't manage to 'get rid of the rest of the hardware' market, and an incompatible Microsoft addition to it won't. The specifications in this case are pretty damn tightly coupled to microsoft (an x86 SoC to run windows in an embedded context, active directory being a hard requirement, and others).
Now that IBM just bailed out of the x86 server market, HP is pretty much the only vendor left making decent hardware for non-cloud applications.
They sold it to Lenovo. IBM's PC share at the time of sale to lenovo was trivial. Lenovo turned that business around to dramatic effect. As much as some people bitch and moan and look for fault, Lenovo has preserved the quality in T and X series thinkpads (which were the only two decent lines at the time of sale). They have recently messed with things, but not to reduce quality but because they think it makes sense from the perspective of following trends. If anything, you will likely be able to more easily get the same servers as before at a lower price target, since IBM is delusional about reasonable margins in the market, and be able to get them faster because IBM hasn't significantly overhauled supply chain/procurement in 15 years, despite overwhelming evidence of the need.
So many to choose from. On the hardware side, they didn't like the current hardware design that Facebook liked (with good reason) and so provided an entirely different set of design sensibilities. This isn't about enhanced standardization, this is about a nice-sounding venue by which to deliver requirements to bidders for MS datacenter equipment. I will say at first glance, I like MS's requirements better than Facebook requirements. The points that I'd worry about would be firmware requirements (MS tends to get insane with network protocols) and the unique IO design which limits the market of compliant equipment (basically, the same that can be said of IBM bladecenter, flex, Dell M1000, etc etc).
On the software side, you'll note that it's in.Net. It's very much not in the realm of typical open source datacenter operations projects. MS once again is stuck having to build the infrastructure themselves for lack of a wider community using their tooling for the purposes MS needs. Of course, MS has historically impressed me with how well they manage to do while being a 'lone wolf'.
If it has an x86 chip, it's going. Period. This includes everything from their tower servers, to 1u/2u dual socket servers, to NextScale, to Flex, all the way up to their Xeon EX based servers. For BladeCenter and Flex (where the enclosures can hold both POWER and x86 systems), Lenovo also gets the enclosure, partner relationships, and IBM OEMs the enclosure back for use in selling POWER blades. HMC hardware appliances will be sourced from lenovo.
If you really have your heart set on *IBM*, then you have to get i, p, or z systems now.
Of course, all the people that are actually behind the qualities sought after in IBM hardware go with the sale. History suggests that those people will largely be left intact since that's what happened to the PC business.
Service is a question, since those people were tasked with servicing all the server hardware. That hasn't been perfectly clarified. It sounded most like the intent is that IBM keeps the technicians, but they will be required to service Lenovo as well as IBM equipment (presumably Lenovo ongoing pays something for the privilege). Perhaps someone familiar with Lenovo desktop experience can speak to how that panned out (all of the laptop vendors I deal with now just ship a loaner laptop and I ship it back instead of sending out a technician).
Slashdot Mirror
systemd versus upstart is mostly anti-canonical sentiment coming home to roost. Canonical has made it clear they don't want to play nice with the wider non-canonical community, and now that's going reciprocal. In a way, systemd and Wayland should be grateful. A non trivial amount of the increased urgency behind migration to those schemes are driven by a distaste for canonical as they push upstart and Mir.
systemd versus sysv init most visibly leads to faster boot (by providing a richer dependency model and avoiding spawning as many processes through skipping shell scripts a lot). The downside should be clear in general, the philosophy leaning more toward compiled modules over shell scripts means it's harder for a lay person to dig in and follow things and understand how they work. If you dig deeper you'll notice that the number of getty processes is lower for most people by skipping spawning such things until the VC is active and other similar things. These are things that really don't meaningfully add to the experience in 99.999% of cases, but it's the sorts of little awkward/arbitrary things that systemd aspires to be a bit more fancy about managing. If a distribution fully embraces systemd philosophy (e.g. Fedora), no more plaintext logfile to peruse. You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.
I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible (ambition to replace at, cron, change from running static number of getty on VC specified by inittab to on demand spawning of getty as auto detected). It's clear they regard users valuing plain text data with some disdain. There is plenty of opportunity to achieve the gains whilst concurrently providing a plain text stream to peruse natively, but they have *zero* interest in trying to pursue such paths.
This is also the brainchild of Lennart Poettering, who has had a track record of getting stuff widely into distribution critical usage path before it's ready (avahi and pulseaudio have given me lots of headaches). Also trying to get DBus into the kernel, which seems absolutely bonkers.
In general, distributions embracing this become increasingly opaque to admins. Distribution behavior flows through an increasingly complex labyrinth of crap that it approaches Microsoft level BS. I'm somewhat disheartened at the possibilities here.
The point being that if you have a cell phone, you have the means of verifying things without need for a physical currency. If you don't have a means of verifying that currency, a 'bitcoin' currency is no more counterfeit resistant than any other currency.
He makes the case for the currency over purely electronic by saying that 3rd world countries won't tolerate cell phones as it's too expensive. At the same time, he wants to trivialize that requirement when it comes to supporting his point of adding value to such a currency since 'anyone with an NFC equipped cellphone' can verify the currency. He comes right back to the same requirement that non-physical bitcoin has, with dramatic differences of opinion of how onerous it is depending on whether he's talking about non-physical or physical medium of exchange.
So for the article, either such infrastructure is out of reach of those markets and thus the physical currency is not inherently more counterfeit proof than anything else, or it is in reach at which point the physicality of the currency is utterly pointless.
Even if you think bitcoin is a reasonable path (I personally don't), this concept is pretty bonkers.
It goes on and on about how the there is no number that can be easily faked. Fiat currency counterfeiters with plain old serial numbers can copy a valid serial number and someone bothering to lookup the serial number could be fooled, not so with Bitcoin. Point taken, but the thing is before that has any value, the recipient of the currency must actually verify that data. There is no point in conveying that info in an expensive physical coin, because such infrastructure could just as easily be fed the data by electronic means or even a printed slip of paper. The physical coin aspect of it becomes the tail wagging the dog, an overpriced way of conveying the counterfeit resistant data. If the data is not actually envisioned to be verified at time of transaction, then it's as useless as the serial number on a dollar.
The only thing holding Bitcoin from exploding in many markets is a lack of a physical incarnation.
Incredibly wishful thinking there. Bitcoin has a lot more problems than lack of a physical incarnation. Being outlawed by major governments, at the mercy of speculators without any regulation, and downright vulnerable to an attack by a critical mass of mining resources working together.
rural farmers in 3rd world countries are not going to get a smartphone and a $100/month data plan just so they can accept Bitcoin.
Exactly! But just a few sentences above it says:
anyone with an NFC equipped cellphone can check if a coin is counterfeit.
You've come round full circle to the problem in the first place: You need functioning internet infrastructure (and a long time) to validate a transaction in the secure way. Without that, you could counterfeit any 'bitcoin' based currency just as easily as any other currency.
A viable alternative currency for micro-nations and dictatorships with hyper-inflation."
Another foolish statement. Again, people are incorrectly assuming there is a technological solution to a socioeconomic problem. The failure of such currencies are a symptom, not a root cause. If it were as simple as all that, the citizens could just as easily move around some stable foreign currency. You can't do a safe, 'sneaky' end run around the force that governs a citizenry. So long as they are empowered to prosecute, shut down internet infrastructure, or just send soldiers into the street, no currency trick is going to work in the face of the fundamental problem.
I think for me the short message is that the X protocol as a remote display protocol no longer provides the optimal remote experience even amongst *nix applications. The solutions that make it workable really involve having an X server running on the same endpoint as the application and picking their favorite protocol to talk back to the client (NX uses X, Xpra uses something else). In the NX case, for whatever reason, they have not delivered a very reliable solution and manage not to convey some key WM hints, so using X as the protocol doesn't seem to make it magically that easy. With that in mind, the question I think moves toward whether or not it makes sense for X11 to define the primary interface between applications running on the same system. I don't really have as much of a horse in that race.
I just think Wayland faces unfair criticism that it doesn't do 'network transparency'. 'Network transparency' refers to the fact that application relationship to the drawing engine is defined in terms where that can be sent over the network directly. People don't really need *that* per se, they need quality seamless remote application support. In Wayland, the relationship between clients and the compositor is decoupled from how the clients are actually displayed. Xpra shows how the COMPOSITE extension in X11 provides the same decoupling and what you can get out of that. The emphasis for those defending Wayland should be "It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor." using Xpra as an example of how that already can be done today. Leading their answer to that with "No, that is outside the scope of Wayland" just pisses people off and gives them the wrong idea (they don't mean to dismiss the scenario, they literally mean that the Wayland specification does not say *anything* about the relationship between compositor and eyeballs, which could be remote, local, who knows, not their problem). So instead of having a 'remote wayland client', you have a 'remote client'.
I know Xpra, it is nice, although I don't need it. But I don't get your point, it uses 'ssh -X'.
No it doesn't. It can tunnel over ssh much like X11 can, but it does not speak X at all between the remote system and local system.
But Xpra speaks X on both sides!
It doesn't though. One one side it talks as a compositor and ICCCM to clients that are going to be displayed elsewhere. The X clients talk X to a dummy X server that runs on the 'remote' end. Then it has it's own protocol to convey encoded graphical content and contextual data gleaned from being the compositor and ICCCM. The client (there's your first clue, the piece that is actually showing the content to someone is indeed a *client*, not a server) talks to the server using that protocol. It then *can* be an X11 client to a local running X server (because in order to be a GUI application in Linux it's pretty much required), but it also can render content on a client with no X server at al (e.g. running on windows without requiring nor including an X server). Xpra acheives great result precisely by avoiding use of X *at all* for network transparency. It is able then to get away with a *much simpler* protocol, trivially provide session persistence, and beat the pants off of ssh -X performance wise to boot.
Which of course leads me to a point of some heresy. I don't know if it's worth it to replace X as the protocol between graphical clients and servers, but I for one think it *is* very much worth it to stop thinking of the X protocol as the best means of providing network transparent remote application access. Yes, RDP doesn't do the job as implemented by microsoft (the per application mode is still not seamless), but Xpra has demonstrated precisely how good remote seamless applications can be in a world without using X as the transport.
Ask the question in text? Even if you made a video asking the question, you'd still be vocalizing the request.
Simply put, when it gets down to it, words are the only thing we can wrap our minds around to convey most concepts. Sure, sometimes a diagram comes into play, but overwhelmingly text is the tool. Same goes for programming. Tools exist to help build UI elements, but the logic is textual. There have been tools to help visualize the relationships in code, but the usage that has persisted is mostly about profiling (I've seen people advocate for other things being visualized, but generally other applications to non-GUI code visualization get old real quick by adding no value but being more cumbersome to wrangle.
That may be beyond the point of diminishing returns. It's true that GTK or QT has the best opportunity to have good primitives for a network connection and provides the ability for remote applications to appear even more seamless with local applications in cases of theme differences, but the work would be a lot more complicated than it was implementing the X primitives that were relevant in the 80s. On addition to being very difficult, the coupling between client and server would be tighter (if application goes to render a widget the display doesn't have due to version mismatch, that could be a problem).
On the otherhand, realtime encode of desktop display is actually pretty serviceable nowadays. You still want the ability to recognize very high level elements for what they are to provide the goodness of network transparency (this is a 'window', a 'dialog', a 'tray icon'), but perhaps not require that the display understand what region of a displayed window is a button versus something else.
I will suggest looking into Xpra. I'm personally wary of RDP as the specific solution unless it deviates from MS design significantly, but Xpra at least seems to me a proof point that the 'ssh -X' way is no longer the only way.
Xpra acheives everything I like about ssh -X, but it performs way better and sessions are not hopelessly broken if the connection is lost. It manages to acheive this by sitting between X server and clients as the window manager/compositor rather than actually using the X protocol to acheive it.
Of course I'm not convinced there is such a dire need to replace X at all, but at least I'm open to the possibility that there is a nice and clean mechanism to add X level network transparency by way of the compositor/window manager rather than the relationship between applications and the display server.
Like many people, my chief concern over Wayland is 'network transparency. Unlike some others, I'm willing to believe there is a light at the end of the tunnel.
Specifically, with X based systems, X remoting is no longer the way I use X remotely, I use xpra as it delivers me a better experience. Unlike something like NX, Xpra does not try to extend or enhance X based protocols, but instead gets content by setting itself as the compositor, knowing things like window relationships to each other and being able to do things like recognizing a tray icon for what it is.
My question is if the same sort of thing would be possible with Wayland today and if people are doing it.
I am entirely amateur hour at this and may have mischaracterized, but I'm willing to hold out hope that the one major fundamental downside of Wayland could be overcome in the same way that Xpra makes X better.
On the one hand, layoffs are frequently considered a 'good thing' by investors, if they believe the company may still be capable of functioning afterward. I don't think Dell is in this boat, but layoffs have upon occasion been taken as a sign of the end times for a particular enterprise.
As to your point about taking it in a new direction as fast as he can, away from a commodity business; the challenge is Dell has yet to show capability in any candidate market. Investors eat up announcements by IBM for decreasing stake in the hardware business because they have shown data that they have already established themselves in other markets. Contrast to when Apotheker announced an intent for him to take HP away from hardware and be a software company. HP's stock took a nosedive because they were not seen as a credible software company, but giving up on their bread and butter to chase a dream. Even if that hardware business isn't as profitable, it's better than nothing.
It's not to say it's a bad thing to reduce needless CPU activity, I was just explaining how this particularly was a strategic move for AMD. The GP was saying 'it's pointless because gamers buy power CPUs', I was simply pointing out that's not what AMD would currently want, since beefy CPU means Intel at this particular point (and really most points since Nehalem came out).
I will say it *could* be a bad thing if it leads to Mantle-exclusive games that are unable to support other GPUs at all (Intel, nVidia, etc).
A server developer can be delusional and think their particular pet technologies are the only ones in the world and that *everyone* is on board. The target users will be non the wiser. About the only aspect that he calls out that is fairly fixed is the notion that *EVERYTHING* must be http based (which I hate, the http protocol was designed around certain usage scenarios and it is atrocious for a lot of uses but it gets shoehorned into them anyway).
Meanwhile, on the client side, if you do want to hit 100% of the market and you have a moderately complex client to do, you may have to do IOS, Android, several different set top boxes (e.g. Roku), game consoles (PS3, Xbox), and Windows (to use netflix as an example).
So gamers get a small boost to their gaming rigs, but that's not *really* the goal for AMD.
The real goal is that AMD demonstrably lags Intel in *CPU* performance, but not GPU. OpenGL/Direct3D implementations cause that to matter, meaning AMD's cpu business gets dinged as a valid component in a configuration that will do some gaming. Mantel diminishes the importance of the CPU to most gaming, therefore their weak CPU offering is made workable to sell their APU based systems. It can do so cheaper than Intel+Discrete GPU while still reaping a tidy profit.
We are talking about a real time application, so even without 100% load over a relatively large sampling interval, performance can be degraded.
Let's assume that you have 2 sequential things that cannot be overlapped. CPU setup and GPU processing. You cannot begin CPU setup of next frame until GPU is done with current frame (gross oversimplification, but there are sequencies that bear some resemblence to this).
So a hypothetical CPU takes 1 ms to setup a frame, and then the hypothetical GPU then takes 4 ms to render it. There's 20% usage CPU wise reported on average over as small a sampling interval as 5 ms, and a throughput of 200 frames per second.
Let's say that the CPU now takes 10 times less time, and takes 100 us to setup a frame, and then the GPU still takes 4 ms to render it. You have gotten about a 20% speedup. Even though the CPU was not fully utililized, it did represent a throttling factor in FPS.
we have photo realistic rendering
No we don't. We have pretty good rendering, but it is not photo realistic. Show anyone a photograph and a game engine attempt to recreate the scene and there is no engine that could fool anyone right now. But that's not so critical.
very high DPI screens
Very much true for everything *except* strapping it to your head and magnifying the display. Again, we are certainly in the 'good enough to make a go of it' realm.
dirt cheap high accuracy sensing.
Actually, we didn't (well, not at the requisite latency) and that is really the vast majority of Oculus effort was centered around. Working out full motion tracking with a latency acceptable for the application.
But I agree with you, get crystal cove out ASAP...
Then implement an alternative runtime. If that gets backlash and an attempt to subvert the standards to do your bidding also gets backlash, then maybe, just maybe, it's the wrong thing to do. If it is the right thing to do, people will run with it.
The fixation on HTML, CSS, Javascript, and HTTP is unreasonable. In the mobile space, people have returned to applications as a very viable approach. This is the answer to people who want application platforms, use something designed from the ground up to be an application platform rather than a platform that was designed as a hypermedia implementation with goodies for application development grafted on.
Yes, bellyaching about CSS region support was the wrong track. This certainly points to a larger problem. Building an 'application platform' is not what I wanted in a browser.
Just saying that it isn't as 'take your ball and go home' as the writeup sounded.
Of course, just because something is 'standard' doesn't mean it's useful. MS historically was subject to ridicule for discarding a standard and then going on their own and implementing the same functionality in an incompatible way. Here, Google's saying that they don't want to implement any alternative scheme to the same end, just not implement the capability at all. The open source world rarely fully implements any standard (for good reason, many parts of standards are impractical, unused, or in some cases some loophole demanded by a proprietary vendor to be able to declare support for the 'standard' without having to make a lot of effort on their part.
The writeup was intended to disparage Google's decision as going off the rails and abandoning an otherwise widely supported standard feature. That image would have been significantly impaired if it made clear that firefox never supported it in the first place, meaning only Apple and Microsoft really bothered. That fact changes things from 'Google is breaking the web by ignoring widely adopted standards' to 'Google abandons obscure function that not many people can use already'.
Is that the current controller of N is legitimate, and *this* story is the social engineering attack to get control of it.
The 'standard' is in a non-sabotaged state already. 'Open'Compute was mostly Facebook saying 'this is the right way to address the only requirements that matter (Facebook's). Now MS managed to get their word in and it just gets slipped in, without the slightest hint of trying to reach a consensus on anything.
OpenCompute has been full of either things uselessly specific to one user's needs or alternatively useless problem statements that are blatantly obvious without a hint of a proposed solution.
Basically, vendors and purchasers are probably about as dysfunctional as they ever have been when it comes to standards, no matter what the words 'Open' imply.
Facebook didn't manage to 'get rid of the rest of the hardware' market, and an incompatible Microsoft addition to it won't. The specifications in this case are pretty damn tightly coupled to microsoft (an x86 SoC to run windows in an embedded context, active directory being a hard requirement, and others).
Now that IBM just bailed out of the x86 server market, HP is pretty much the only vendor left making decent hardware for non-cloud applications.
They sold it to Lenovo. IBM's PC share at the time of sale to lenovo was trivial. Lenovo turned that business around to dramatic effect. As much as some people bitch and moan and look for fault, Lenovo has preserved the quality in T and X series thinkpads (which were the only two decent lines at the time of sale). They have recently messed with things, but not to reduce quality but because they think it makes sense from the perspective of following trends. If anything, you will likely be able to more easily get the same servers as before at a lower price target, since IBM is delusional about reasonable margins in the market, and be able to get them faster because IBM hasn't significantly overhauled supply chain/procurement in 15 years, despite overwhelming evidence of the need.
So many to choose from. On the hardware side, they didn't like the current hardware design that Facebook liked (with good reason) and so provided an entirely different set of design sensibilities. This isn't about enhanced standardization, this is about a nice-sounding venue by which to deliver requirements to bidders for MS datacenter equipment. I will say at first glance, I like MS's requirements better than Facebook requirements. The points that I'd worry about would be firmware requirements (MS tends to get insane with network protocols) and the unique IO design which limits the market of compliant equipment (basically, the same that can be said of IBM bladecenter, flex, Dell M1000, etc etc).
On the software side, you'll note that it's in .Net. It's very much not in the realm of typical open source datacenter operations projects. MS once again is stuck having to build the infrastructure themselves for lack of a wider community using their tooling for the purposes MS needs. Of course, MS has historically impressed me with how well they manage to do while being a 'lone wolf'.
If it has an x86 chip, it's going. Period. This includes everything from their tower servers, to 1u/2u dual socket servers, to NextScale, to Flex, all the way up to their Xeon EX based servers. For BladeCenter and Flex (where the enclosures can hold both POWER and x86 systems), Lenovo also gets the enclosure, partner relationships, and IBM OEMs the enclosure back for use in selling POWER blades. HMC hardware appliances will be sourced from lenovo.
If you really have your heart set on *IBM*, then you have to get i, p, or z systems now.
Of course, all the people that are actually behind the qualities sought after in IBM hardware go with the sale. History suggests that those people will largely be left intact since that's what happened to the PC business.
Service is a question, since those people were tasked with servicing all the server hardware. That hasn't been perfectly clarified. It sounded most like the intent is that IBM keeps the technicians, but they will be required to service Lenovo as well as IBM equipment (presumably Lenovo ongoing pays something for the privilege). Perhaps someone familiar with Lenovo desktop experience can speak to how that panned out (all of the laptop vendors I deal with now just ship a loaner laptop and I ship it back instead of sending out a technician).