We're always recommending to our users to use one of the supported installation methods such as owncloud.org/install where we even provide our own repositories for most distributions.
I understand why, but that goes against the whole philosophy of distributions. From your perspective it obviously makes things easy. From the user's perspective you are one of a 100 packages that wants to install and be configured in specialized ways. And then of course this introduces complexity in both directions. For distribution packages which want features of OwnCloud they are going to pull down the Ubuntu package possibly crewing up the custom distribution. For OwnCloud packages that want dependency they aren't going to pull in the right things from the Ubuntu distribution or link to them properly. A total mess.
Really there is no good solution then there existing a package maintainer for the major distributions. owncloud.com has to decide if making owncloud.org's product work well/safely on Ubuntu is good or bad for the business. I can easily see either being the case. Ubuntu has to decide if owncloud.org's product is worth them supporting and right now they've decided no. If both decide no, and no individual steps up then... well there is a problem and owncloud will be iffy on Ubuntu.
That bar graph of a spike starting in 2007 would more likely be related to the release of the iPhone.
Except for the fact that the spike starts in 2004. Its an exponential graph.
Without the development of the iPhone it is hard to see an particular strong reason for Mac marketshare to start growing
OSX Version 10.3: "Panther". At that point OSX is far ahead feature wise of Microsoft's offerings, the complexity that existed 10.0-10.2 is over, the huge markup is over and the ease of use is high. Longhorn which will later be scaled back and released as Vista is years away. There is just no comparing the two systems in terms of what you get.
Second, hardware quality starts to fall through the floor on the PC side. The drop off in sales after 2000 had PC manufacturers cutting R&D, cutting parts quality and going into a spiral of chasing each other to the bottom in terms of build quality. The public had broadly realized this, while liking the lower prices. Apple's quality differences became well known.
The selection of software on a Mac is okish today, but in 2007 it was downright terrible
Nonsense. The selection was quite good. The Apple commercial market had recovered and the open source desktop market offered a nice collection of applications that as well. And for that matter Microsoft Office for Mac was quite good.
When it comes to telco it isn't nearly twice as expensive to hit every house as it is to hit every other house. It is much cheaper to have government organizing the digging up of streets and private property than to negotiate with the private and public landholders. Government can cut the cost per user enormously if they engage. I think the article is BS but your refutation is as well.
and our cities are plenty dense enough to support fiber to the home
That's fine. And if you wanted internet within cities then that wouldn't be a problem. But most people want to get to websites and internet services outside their cities. Which means they need to be using national bandwidth. If 100k people are consuming 1gbs of bandwith that's 100tbs going into the city often over hundreds of miles. So say 5 fiber links out 20-40tbs of capacity for often hundreds of miles. Then that gets intermixed with what the city itself is consuming.
We don't remotely have the technology to support that much bandwidth. So sure. You want to file share with the guy down the block the local cable company could put in fiber. But you want to gigabit+ bandwidth to everyhome that's unthinkably expensive.
But we don't, because lobbyists.
Yeah that must be it. The evil telcos don't want you to buy more of their product. The same banana importers are lobbying to block grocery stores from selling bananas by the bunch.
Because US population density looks more like Africa than it does like Europe and East Asia. We spread ourselves out which drives the cost of providing telco services through the roof.
Mostly never. Apple customers were happy with Apple's position that Bluetooth did well what NFC did poorly. Android people were very upset that Apple people didn't have NFC.
RHEL 6 (and its CentOS variants) are upstart, not systemd.
RHEL 7 is systemd though. Which means Cent is going to switch. And that means Facebook is going to switch.
Just admit you were wrong about them using it.
I know for a fact they are using it. They are using it for a backend I'm working with. Though it isn't terribly consequential to anything so it isn't a great piece of evidence, the system its on would run fine on Xenix.
"on hardware certified by RedHat Labs " Also, Facebook's been rolling its own hardware for quite a while now, dude.
I included the quote. You missed the part where I said they were rolling their own hardware and the key point of who certifies it.
The point is that if you knew engineers working at those companies out here, you could have found out what they were actually running on by asking rather than making claims you can't back up.
Your claim from the start has been that systemd is unsuitable for server. Though your claim below is much weaker and something I would mostly agree with. So in terms of not backing it up you are disambiguating. You picked Facebook from my list:
a) They run CentOS. Cent OS is switching b) They get their hardware certified by RedHat who is the single largest proponent of systemd.
I would say that's not opposite. But most importantly if you read the context I gave Facebook as someone advocating PaaS not someone advocating systemd. The PaaS vendors are the ones who care (and should care) about OS level components like systemd. I don't think clients like change.org should be concerned with the infrastructure at all. That's the whole point of DevOps it helps to further break the accidental bleed over between platform specifics and higher level software, which is what the whole enterprise Java movement was attempting to do for client / server.
Hi. I'm Jeff. My LinkedIn is the Homepage link next to my name. My apologies for not having it there previously.
Fair enough. Change.org DevOps architect is legit experience.
Well, we've already established that you've been lax about doing your research before making claims.
I think that's unfair and untrue. We just disagree about what constitutes a reliable source. I'm mainly interested in vendors because they have breadth you are mainly interested in engineers because they see things up close. The way you are phrasing it is unnecessarily harsh.
From my experience, given that for many of my jobs I've been the guy hired to clean up after a "systems integrator" with a cost sheet full of buzzwords and marketing woo came in and sold some magic beans to bigwigs who didn't listen to their engineers, your line of work tends to over-engineer a "solution", under-calculate cost of operations, and end up leaving a company with severe vendor lock-in disease and an engineering staff with a new solution that's outside of the team's core expertise, which leads to staff churn, high retraining costs for those that do stay, and dissatisfaction all around.
That's not about systemd but just to defend our guys:
a) I'd love to do accurate cost assessments where IT companies use a sane rate of interest and depreciate their IT infrastructure over 10-20 years. We aren't the ones who force companies to do ROI accounting as if their depreciation / cost of borrowing / interest rate were 400%. That's not the engineers either (they are mainly on our side about that one). Blame your finance guys not us. But ultimately if the customer is mainly focused on the 1 year or 3 year cost, then we build a solution to keep the 1 or 3 year cost low and often by letting it explode in the out years.
b) In terms of staff churn often the point of an integrated solution is to prompt
Facebook most definitely does not use a single distro in production that uses systemd.
Facebook had been on a CentOS variant running on hardware certified by RedHat Labs for years. RHEL is systemd. Whether they have switched yet or not I don't know, but by 2018 or earlier they will be on systemd. If it isn't in production, it isn't in production yet.
You don't work out here. I do. It's not that big of an industry when it comes to systems administration and DevOps out here.
I don't work out there. Absolutely not. But PaaS is much bigger than the Valley. The ideas and technologies developed for DevOps are being deployed much more broadly
Don't make claims that anyone with a LinkedIn worth a damn can debunk with a few messages.
Maybe time to use your real name if you are going to play that game.
I've been very clear about the gripes I have about it.
No you haven't. You've said that you have to change stuff you do for an existing infrastructure. That's about it. Lots of hyperbole and nonsense claims about desktop.
You don't administer systems. You don't design the internals of system architecture
I don't administer systems. I most certainly do design the internals of system architectures. What do you think happens when you sell a solution that you put together random parts without thinking about how they work? I've done the specialist job when you knew every little detail of a system, and I went through large scale changes before as an engineer. I remember when I was an engineer people like you gripping about the change over from DECnet to IP and how the sky would fall. I was intimately involved in the migration of working systems from Metacode to Postscript and AFP. The systems are far better today for progress.
I can't even tell from your LinkedIn (we're third degree contacts) that you've touched a Linux system in your life.
I have, Unix since 1988, Linux since 1995. I've also touched a wide range of the big box Unixes, zSeries, iSeries and VMS. Which gives some perspective on having seen styles of solutions for process management over the years. I'm certainly not a Linux specialist. I rely on Linux specialists.
You've been management for over a decade.
Yep. What do you think management does?
You seriously don't think the same infrastructure that some shops you namedrop are -the- solution for every use case, especially out here, do you? Especially when they don't even use what you're advocating for?
I don't use PaaS? Really? You tell me what am I using for the clients we are deploying too?
I don't know about every client out there. I do know that the claim that you were making that systemd was for desktop and didn't have support for server is BS. I talk to far too many vendors who sell server solutions to believe that. I talk to far too many people system admin cloud or colos admins who see hundreds of clients to not know if systemd were causing problems to any significant fraction. I work with one of the research groups that publishes studies on this collecting the data.
So sure you are an admin in the valley. So what? You aren't the only place doing DevOps, though you guys do invent many of the best ideas.. Its gone mainstream. And believe it or not, people on opposite coast do talk to one another.
Google, IBM, Facebook, Netflix, Random House, GE... Those are complex server installations. Your side hasn't said much of anything. Mainframes, minis, bigbox Unix have had monolithic systems for decades. I'm presenting evidence you aren't presenting any well known vendor who disagrees.
>>And it sucks for that your use case tramples their use case. These things are symmetrical. There are choices. Some are helped and some are harmed.
Bull!
You can't run around claiming you don't want to talk about internals and then just make statements like that. You don't know what you are talking about. The fact that you don't like reality doesn't mean it isn't reality. Yes there are choices in life. Not everyone gets to have everything. Do you really think that the debates regarding network transparency for the last four decades were because of spite and that: Microsoft, Apple, Commodore, Digital, NVidia, Intel, IBM, Sun, SGI, the current X-Windows team... are just wrong while your "I don't like it, so it isn't true" is right. Grow up!
This is/. Stop cursing. Start thinking about these problems from the developer's end. Either the application and graphical buffer is shared or it is separate. Either the network protocol is intelligently decomposing graphical objects or it is oblivious to them and just passes buffers around. No you cannot have both.
If supporting the X protocol means someone else's video doesn't play right then fine, don't support the X protocol. (makes no sense to me, I can play videos all day long with seeing tearing, what ever the hell that is). Just make sure it still has the possibllity to do somethign that works like an X terminal but uses RDP or VNC or whatever protocol makes you happy.
That's what it does. There is no reason you can't build a VNC client that boots instantly on bad hardware. The VNC use case is covered by Wayland today. But that is not network transparency.
So? The least common automatically gets no support?
No. But it a well designed system when there are tradeoffs that's the group that is disadvantaged.
Somebody always must be descriminated against? Where is the logic in that?
The logic of that is we live in the real world.
I'm sure there are many others using LAN support. So what if it's the least common. It's still common enough to be important!
No it isn't. And we know that because we have data. NEC didn't leave the XTerm industry 15 years ago because sales were too strong to keep up. SunRay are selling for less than the case it worth on ebay, that's not a sign of strong demand. It is time to deal with reality. Your use case is a tiny niche. A well supported niche and one likely to continue to be supported in a limited fashion for decades. But you aren't under 2%, not 90% anymore.
Even if systemd is a clear upgrade over every single component it has its tentacles in (for the sake of argument), it isn't enough to justify refactoring a working infrastructure on a DevOps team that's already understaffed as it is.
So don't use it. But that's very different than claiming it is only for desktop and not for server. Which both of you tried and which is provably false given that the most complex server installations are pushing systemd. Devops BTW being one of the its best use cases.
Well yes. The claim these guys keep throwing around is it is "desktop only". When in reality the most complex server installation are finding it solving their problems. They are just peddling a myth because the earliest success were for desktop.
As far as the init system goes, the vast majority of packages are not daemons. Only daemons require init support.
I agree. Most packages aren't a problem. But many packages depend directly on indirectly on daemons. Which is how chains of dependencies form.
But the task of maintaining a couple hundred init scripts wouldn't be hard for a small committee of volunteers.
That's easy. But that's not the task. systemd does process monitoring. Systemd has ties to PaaS. Systemd handles power management and alerting applications to be responsible regarding their power usage... All that code needs to be maintained. This is where it gets to be serious programming.
For the non-init stuff, the trick is to convince upstream developers to support diversity, which can be done by continuing to embrace open standards and APIs.
How? The fact that upstream developers liked the features of systemd and kept wanting to use them is what drove Debian to feel that they had to make the switch in the first place. Sure if the world were different Debian would have made other choices. But how do you convince developers to embrace "open standards". Especially since FreeDesktop has put out a systemd spec, there exists a systembsd which is implementing this spec so systemd is arguably an open standard.
So somebody else's problem with X11 means that my own use case gets trampled? That really sucks.
And it sucks for that your use case tramples their use case. These things are symmetrical. There are choices. Some are helped and some are harmed.
. I'm sure I'm not alone here in using network transparency.
You aren't. But you are of the 3 main cases (local, LAN, WAN) the least common.
If you want Windows Remote Desktop why not just use Windows?
They could say the same thing to you. If you want 1990 Unix why not use a 1990 Unix?
What I do really really care about in Ratpoison is the tiling I like... Can tiling be done with Wayland?
There are tiling compositors for Wayland since 2012. The algorithms for tiling are standard programming exercises there are easy to implement so they should be in the major compositors once larger issues get resolved.
Let's ignore the issue of whether the fork is a good idea. How are they going to accomplish this? Debian has thousands of packages. Upstream developers mostly like systemd. At least a few dozen packages are becoming hard dependent on systemd. Assume this number doubles every year (not unlikely). What is the Debian fork going to do? Assume that about 200 or so already have reduced functionality without systemd, again let that go up 50% per year for the next few years. How are they going to fix this?
This sounds like hundreds or not many thousands of man years of work per year every year trying to keep up. How is the Debian fork possibly going to make it? The best they can do is release a traditionalist subdistribution which uses init. OK that's easy, but that's not a fork. And frankly if they start patching a few things, why not just roll those patches either upstream or into Debian?
How is this fork going to work and what are they going to do?
Linux works out of the box in the same way that MacOS or Windows does.
Not really. It is has gotten worse at this in the last decade. 10 years ago I'd say Linux is likely easer to install on random hardware. Today the relentless desire to hack up drivers has dried up (understandably a ton of work that never stops). The better desktop distributions went broke. Mandrake is gone. Caldera (pre SCO) is gone. RedHat makes a server but not an OS. YellowDog (PPC) gone.... Xandros gone. It is getting harder and harder to get Linux to install and work on the desktop.
I was using XTerms (the real thing not emulators) starting in 1988, and was using as my primary computer by late 1992. I know what XTerms are. The LTSP was just a way in the early 1990s to get Linux boxes, primarily cheap old PCs that couldn't run Windows 3.1 / 95 anymore to run XTerms. I've been familiar with that project for two decades. I'm not failing to understand you. But you were being a bit unclear about what you wanted before.
Check out the Linux Terminal Server Project ltsp.org. Can something like that be implemented in Wayland?
If by that you mean a dumb system giving you near real time performance, no it can't. That's what network transparency means, and that's what Wayland doesn't support.
X-terminal can be a truly cut down device with little more than a kernel and X. Boot time is super fast because all you are loading is a kernel plus X.
It doesn't even really need anything as complex as a Windows kernel. You can cut it way below that. X11 ran on DOS. You can easily create a dumb X-term which would be done booting before you could move your arm from the power switch to the keyboard. The NCR used an 88100 @ 20MHz and could boot in under 5 seconds.
By X11 having that do you mean PulseAudio?
There are lots of solutions. The X11 protocol is extendable one extensions that's been implemented multiple times is sound. Anyway to setup Pulse Audio: http://www.freedesktop.org/wik...
I want a terminal that is basically a dedicated second head to the main machine.
That Wayland doesn't do. You have your choice: smart networking or application and video card on the same bus. Someone might figure out some way to get that to work by running virtual machines on either side and hacking together a virtual bus that is running over the network but what you want is what X11 is optimized for. Keep running X11 as long as you can and see where the world is in 2030 or so.
See, that's my point. Wayland is taking away something that was core to X11. Wayland is a regression.
No. Wayland is a different architecture and for some use cases that different architecture is worse. For most it is better. Given any two reasonable architectural choices A and B there must be definition of reasonable be cases X where A is better and cases Y where B is better. The set of cases where Wayland is better is much larger than the set of cases where X11 is better. Remote over a LAN (lots of bandwidth, around 1ms latency) is what X11 is designed for, X11 is much better in the case it was designed for.
Your specific case, of two machines in your home will be worse with Wayland. Your either going to have to boost the other machine up to being a full desktop or accept an experience which won't be much different from what you would have over a WAN.
I'm using Ratpoison. I like frames.
Ratpoison is an X11 Windows Manager. For a lightweight window manager changing this architecture is close to a rewrite from scratch. I'd assume Ratpoison will likely never be ported to Wayland. But if you like X11 Window managers Enlightenment has ported over to being a Wayland compositor.
No, don' t try to tell me that X is too bloated to run on an embedded device.
It's not. X11 works wonderfully on mode on X-terms which had 8mb of RAM and CPUs under 100mhz. The problem with X11 is latency due to round trips not resource usage. The CPU / memory resource usage is too low to compensate for network complications the problem is not that it is too high.
That means that sooner or later I and every other Linux user will have to switch! The only thing left for disagreement is when.
Yep. Exactly.
Also, X as a Wayland client might be useful for running an individual application remotely. I like to run the whole desktop remotely, from xdm to the window manager.
Well the RDP mode of Wayland will work for Wayland applications that aren't using X11, and of course X11 will still work for those that are using X11. The RDP stuff might work for the X11 applications making it seamless or it might not, I'd assume it won't and you'll have two networking sessions.
How will something like LTSP exist with Wayland?
You mentioned you liked VNC. VNC works. But excluding VNC something like LTSP won't work. Wayland demands a smart client it won't use a dumb client. And the reason for that is because you and everyone else who does X11 in 2014 are sitting at a smart client using it as if it were a dumb client. You aren't sitting at a dumb X-term, you are sitting at a computer with lots of CPU, RAM and HD. So Wayland takes advantage of that. your computer will have to do some of the rendering. This means your computer will need graphical objects that correspond to GUI you are running. So for example if you are running KDE5 (or 6 or whatever) remotely you will need a at least KDElibs on the local machine. Otherwise you can use something like VNC (which you said you liked).
Meanwhile all the various editorials make it sound like Wayland's replacement of X is right around the corner.
It depends on the use case. For Tizen applications (smart watches, appliance terminals..) it already is in use. Moving up complexity it is being used in a high end mobile phone for the Kazakhstan market (i.e. better performance allowing saving money on hardware...) I'm thinking 2016 is when early adopter end users (on desktop) will be trying it out for daily use rather than something to screw around with. By 2020 absolutely the switch will happen, but not next week.
I know X will still be around for a while but chosing the non-default option on something that fundamental to a distro will probably suck.
Remember you won't really have to. Wayland runs X11 now. I think this transition is going to be rather smooth. It is being planned well upstream getting everything coordinated. Mostly desktop is going late because with the exception of gaming their isn't much urgent need. It is when applications switch from being X11 on Wayland to directly on Wayland that new bugs get introduced and you'll notice. But then you will still be able to run the application either way (for a short period of time till they drop support for X11).
What I (and I think other people who are concerned about having remote display) am interested in is knowing I will be able to keep doing what I do now in the future but still with future, upgraded tools. For example, 10 years from now I am not going to want to run a 8 year old web browser because 2 years from now the last ever version to support X is released. You can increase/decrease those numbers as much as you want to make it fit your guess of reality. Also, even if main, important tools are available for X forever, surely there will be some developers that chose to only support X. How do we run those applications remotely? Will we get a Wayland server that runs as an X client?
This isn't a will you. This is a right now. Today the Wayland client supports connecting to an X11 server and that's embedded by default. How long Wayland maintains an X is unclear but I'd assume well over an additional decade for compatibility. In fact what I would assume is going to happen very shortly is the hardware vendors are going to stop working with the X11 team on updates. So say by 2019 or so, Wayland is going to be the only way in any practical sense to get even halfway decent performance on X11.So your X11 applications will be find.
Now the rest of this is about a browser. I think you have the situation backwards. 10 years from now the browser is likely to be Wayland only with no X11 support. If you are running a browser that you want to run this remotely you would be using Wayland's RDP remote features. X11 wouldn't be anymore involved than Amiga Workbench
I want something where I can get a remote login and once loged in I see the remote desktop as though it were local. I also want the ability to run a service which allows me to connect from various remote devices to a persistant session. (Like VNC today).
That's super easy. You like VNC, RealVNC already supports Wayland. A VNC is merged into the Wayland. That full desktop experience is getting better with the RDP.
I rarely display an individual application remotely but I bet someone does. That ability should exist too or it's a regression.
That's what the RDP does.
On my X terminal there is no noticeable performance hit at all!
I doubt that if you are on a WAN. Open up some graphics remotely and start rapidly shifting the location of your terminal and over the graphics forcing redraws. You'll see visible tearing
Unless Wayland is somehow going to get us remote audio too
X11 already has that. Wayland has enhanced video so that gets better.
Slashdot Mirror
I understand why, but that goes against the whole philosophy of distributions. From your perspective it obviously makes things easy. From the user's perspective you are one of a 100 packages that wants to install and be configured in specialized ways. And then of course this introduces complexity in both directions. For distribution packages which want features of OwnCloud they are going to pull down the Ubuntu package possibly crewing up the custom distribution. For OwnCloud packages that want dependency they aren't going to pull in the right things from the Ubuntu distribution or link to them properly. A total mess.
Really there is no good solution then there existing a package maintainer for the major distributions. owncloud.com has to decide if making owncloud.org's product work well/safely on Ubuntu is good or bad for the business. I can easily see either being the case. Ubuntu has to decide if owncloud.org's product is worth them supporting and right now they've decided no. If both decide no, and no individual steps up then... well there is a problem and owncloud will be iffy on Ubuntu.
That's a great comic! If only people checked that the phrase being used were unconnected with them far far better system.
Except for the fact that the spike starts in 2004. Its an exponential graph.
OSX Version 10.3: "Panther". At that point OSX is far ahead feature wise of Microsoft's offerings, the complexity that existed 10.0-10.2 is over, the huge markup is over and the ease of use is high. Longhorn which will later be scaled back and released as Vista is years away. There is just no comparing the two systems in terms of what you get.
Second, hardware quality starts to fall through the floor on the PC side. The drop off in sales after 2000 had PC manufacturers cutting R&D, cutting parts quality and going into a spiral of chasing each other to the bottom in terms of build quality. The public had broadly realized this, while liking the lower prices. Apple's quality differences became well known.
Nonsense. The selection was quite good. The Apple commercial market had recovered and the open source desktop market offered a nice collection of applications that as well. And for that matter Microsoft Office for Mac was quite good.
When it comes to telco it isn't nearly twice as expensive to hit every house as it is to hit every other house. It is much cheaper to have government organizing the digging up of streets and private property than to negotiate with the private and public landholders. Government can cut the cost per user enormously if they engage. I think the article is BS but your refutation is as well.
What makes you think fiber is cheap?
That's fine. And if you wanted internet within cities then that wouldn't be a problem. But most people want to get to websites and internet services outside their cities. Which means they need to be using national bandwidth. If 100k people are consuming 1gbs of bandwith that's 100tbs going into the city often over hundreds of miles. So say 5 fiber links out 20-40tbs of capacity for often hundreds of miles. Then that gets intermixed with what the city itself is consuming.
We don't remotely have the technology to support that much bandwidth. So sure. You want to file share with the guy down the block the local cable company could put in fiber. But you want to gigabit+ bandwidth to everyhome that's unthinkably expensive.
Yeah that must be it. The evil telcos don't want you to buy more of their product. The same banana importers are lobbying to block grocery stores from selling bananas by the bunch.
Because US population density looks more like Africa than it does like Europe and East Asia. We spread ourselves out which drives the cost of providing telco services through the roof.
Mostly never. Apple customers were happy with Apple's position that Bluetooth did well what NFC did poorly. Android people were very upset that Apple people didn't have NFC.
RHEL 7 is systemd though. Which means Cent is going to switch. And that means Facebook is going to switch.
I know for a fact they are using it. They are using it for a backend I'm working with. Though it isn't terribly consequential to anything so it isn't a great piece of evidence, the system its on would run fine on Xenix.
I included the quote. You missed the part where I said they were rolling their own hardware and the key point of who certifies it.
Your claim from the start has been that systemd is unsuitable for server. Though your claim below is much weaker and something I would mostly agree with. So in terms of not backing it up you are disambiguating. You picked Facebook from my list:
a) They run CentOS. Cent OS is switching
b) They get their hardware certified by RedHat who is the single largest proponent of systemd.
I would say that's not opposite. But most importantly if you read the context I gave Facebook as someone advocating PaaS not someone advocating systemd. The PaaS vendors are the ones who care (and should care) about OS level components like systemd. I don't think clients like change.org should be concerned with the infrastructure at all. That's the whole point of DevOps it helps to further break the accidental bleed over between platform specifics and higher level software, which is what the whole enterprise Java movement was attempting to do for client / server.
Fair enough. Change.org DevOps architect is legit experience.
I think that's unfair and untrue. We just disagree about what constitutes a reliable source. I'm mainly interested in vendors because they have breadth you are mainly interested in engineers because they see things up close. The way you are phrasing it is unnecessarily harsh.
That's not about systemd but just to defend our guys:
a) I'd love to do accurate cost assessments where IT companies use a sane rate of interest and depreciate their IT infrastructure over 10-20 years. We aren't the ones who force companies to do ROI accounting as if their depreciation / cost of borrowing / interest rate were 400%. That's not the engineers either (they are mainly on our side about that one). Blame your finance guys not us. But ultimately if the customer is mainly focused on the 1 year or 3 year cost, then we build a solution to keep the 1 or 3 year cost low and often by letting it explode in the out years.
b) In terms of staff churn often the point of an integrated solution is to prompt
Facebook had been on a CentOS variant running on hardware certified by RedHat Labs for years. RHEL is systemd. Whether they have switched yet or not I don't know, but by 2018 or earlier they will be on systemd. If it isn't in production, it isn't in production yet.
I don't work out there. Absolutely not. But PaaS is much bigger than the Valley. The ideas and technologies developed for DevOps are being deployed much more broadly
Maybe time to use your real name if you are going to play that game.
No you haven't. You've said that you have to change stuff you do for an existing infrastructure. That's about it. Lots of hyperbole and nonsense claims about desktop.
I don't administer systems. I most certainly do design the internals of system architectures. What do you think happens when you sell a solution that you put together random parts without thinking about how they work? I've done the specialist job when you knew every little detail of a system, and I went through large scale changes before as an engineer. I remember when I was an engineer people like you gripping about the change over from DECnet to IP and how the sky would fall. I was intimately involved in the migration of working systems from Metacode to Postscript and AFP. The systems are far better today for progress.
I have, Unix since 1988, Linux since 1995. I've also touched a wide range of the big box Unixes, zSeries, iSeries and VMS. Which gives some perspective on having seen styles of solutions for process management over the years. I'm certainly not a Linux specialist. I rely on Linux specialists.
Yep. What do you think management does?
I don't use PaaS? Really? You tell me what am I using for the clients we are deploying too?
I don't know about every client out there. I do know that the claim that you were making that systemd was for desktop and didn't have support for server is BS. I talk to far too many vendors who sell server solutions to believe that. I talk to far too many people system admin cloud or colos admins who see hundreds of clients to not know if systemd were causing problems to any significant fraction. I work with one of the research groups that publishes studies on this collecting the data.
So sure you are an admin in the valley. So what? You aren't the only place doing DevOps, though you guys do invent many of the best ideas.. Its gone mainstream. And believe it or not, people on opposite coast do talk to one another.
Google, IBM, Facebook, Netflix, Random House, GE... Those are complex server installations. Your side hasn't said much of anything. Mainframes, minis, bigbox Unix have had monolithic systems for decades. I'm presenting evidence you aren't presenting any well known vendor who disagrees.
You can't run around claiming you don't want to talk about internals and then just make statements like that. You don't know what you are talking about. The fact that you don't like reality doesn't mean it isn't reality. Yes there are choices in life. Not everyone gets to have everything. Do you really think that the debates regarding network transparency for the last four decades were because of spite and that: Microsoft, Apple, Commodore, Digital, NVidia, Intel, IBM, Sun, SGI, the current X-Windows team... are just wrong while your "I don't like it, so it isn't true" is right. Grow up!
This is /. Stop cursing. Start thinking about these problems from the developer's end. Either the application and graphical buffer is shared or it is separate. Either the network protocol is intelligently decomposing graphical objects or it is oblivious to them and just passes buffers around. No you cannot have both.
That's what it does. There is no reason you can't build a VNC client that boots instantly on bad hardware. The VNC use case is covered by Wayland today. But that is not network transparency.
No. But it a well designed system when there are tradeoffs that's the group that is disadvantaged.
The logic of that is we live in the real world.
No it isn't. And we know that because we have data. NEC didn't leave the XTerm industry 15 years ago because sales were too strong to keep up. SunRay are selling for less than the case it worth on ebay, that's not a sign of strong demand. It is time to deal with reality. Your use case is a tiny niche. A well supported niche and one likely to continue to be supported in a limited fashion for decades. But you aren't under 2%, not 90% anymore.
So don't use it. But that's very different than claiming it is only for desktop and not for server. Which both of you tried and which is provably false given that the most complex server installations are pushing systemd. Devops BTW being one of the its best use cases.
Well yes. The claim these guys keep throwing around is it is "desktop only". When in reality the most complex server installation are finding it solving their problems. They are just peddling a myth because the earliest success were for desktop.
I agree. Most packages aren't a problem. But many packages depend directly on indirectly on daemons. Which is how chains of dependencies form.
That's easy. But that's not the task. systemd does process monitoring. Systemd has ties to PaaS. Systemd handles power management and alerting applications to be responsible regarding their power usage... All that code needs to be maintained. This is where it gets to be serious programming.
How? The fact that upstream developers liked the features of systemd and kept wanting to use them is what drove Debian to feel that they had to make the switch in the first place. Sure if the world were different Debian would have made other choices. But how do you convince developers to embrace "open standards". Especially since FreeDesktop has put out a systemd spec, there exists a systembsd which is implementing this spec so systemd is arguably an open standard.
True. But the claim was, "Systemd may be fine for a desktop, but not fine for a server". Obviously the PaaS vendors are doing server.
Which PaaS vendor has come out against systemd?
And it sucks for that your use case tramples their use case. These things are symmetrical. There are choices. Some are helped and some are harmed.
You aren't. But you are of the 3 main cases (local, LAN, WAN) the least common.
They could say the same thing to you. If you want 1990 Unix why not use a 1990 Unix?
There are tiling compositors for Wayland since 2012. The algorithms for tiling are standard programming exercises there are easy to implement so they should be in the major compositors once larger issues get resolved.
Let's ignore the issue of whether the fork is a good idea. How are they going to accomplish this? Debian has thousands of packages. Upstream developers mostly like systemd. At least a few dozen packages are becoming hard dependent on systemd. Assume this number doubles every year (not unlikely). What is the Debian fork going to do? Assume that about 200 or so already have reduced functionality without systemd, again let that go up 50% per year for the next few years. How are they going to fix this?
This sounds like hundreds or not many thousands of man years of work per year every year trying to keep up. How is the Debian fork possibly going to make it? The best they can do is release a traditionalist subdistribution which uses init. OK that's easy, but that's not a fork. And frankly if they start patching a few things, why not just roll those patches either upstream or into Debian?
How is this fork going to work and what are they going to do?
The weird thing about this is that Ubuntu threw in the towel on systemd themselves. They realized they are behind and Upstart can't catch up.
The PaaS vendors are all excited about systemd. So that's just simply false. It is better for server.
Not really. It is has gotten worse at this in the last decade. 10 years ago I'd say Linux is likely easer to install on random hardware. Today the relentless desire to hack up drivers has dried up (understandably a ton of work that never stops). The better desktop distributions went broke. Mandrake is gone. Caldera (pre SCO) is gone. RedHat makes a server but not an OS. YellowDog (PPC) gone.... Xandros gone. It is getting harder and harder to get Linux to install and work on the desktop.
I was using XTerms (the real thing not emulators) starting in 1988, and was using as my primary computer by late 1992. I know what XTerms are. The LTSP was just a way in the early 1990s to get Linux boxes, primarily cheap old PCs that couldn't run Windows 3.1 / 95 anymore to run XTerms. I've been familiar with that project for two decades. I'm not failing to understand you. But you were being a bit unclear about what you wanted before.
If by that you mean a dumb system giving you near real time performance, no it can't. That's what network transparency means, and that's what Wayland doesn't support.
It doesn't even really need anything as complex as a Windows kernel. You can cut it way below that. X11 ran on DOS. You can easily create a dumb X-term which would be done booting before you could move your arm from the power switch to the keyboard. The NCR used an 88100 @ 20MHz and could boot in under 5 seconds.
There are lots of solutions. The X11 protocol is extendable one extensions that's been implemented multiple times is sound. Anyway to setup Pulse Audio: http://www.freedesktop.org/wik...
That Wayland doesn't do. You have your choice: smart networking or application and video card on the same bus. Someone might figure out some way to get that to work by running virtual machines on either side and hacking together a virtual bus that is running over the network but what you want is what X11 is optimized for. Keep running X11 as long as you can and see where the world is in 2030 or so.
No. Wayland is a different architecture and for some use cases that different architecture is worse. For most it is better. Given any two reasonable architectural choices A and B there must be definition of reasonable be cases X where A is better and cases Y where B is better. The set of cases where Wayland is better is much larger than the set of cases where X11 is better. Remote over a LAN (lots of bandwidth, around 1ms latency) is what X11 is designed for, X11 is much better in the case it was designed for.
Your specific case, of two machines in your home will be worse with Wayland. Your either going to have to boost the other machine up to being a full desktop or accept an experience which won't be much different from what you would have over a WAN.
Ratpoison is an X11 Windows Manager. For a lightweight window manager changing this architecture is close to a rewrite from scratch. I'd assume Ratpoison will likely never be ported to Wayland. But if you like X11 Window managers Enlightenment has ported over to being a Wayland compositor.
It's not. X11 works wonderfully on mode on X-terms which had 8mb of RAM and CPUs under 100mhz. The problem with X11 is latency due to round trips not resource usage. The CPU / memory resource usage is too low to compensate for network complications the problem is not that it is too high.
Yep. Exactly.
Well the RDP mode of Wayland will work for Wayland applications that aren't using X11, and of course X11 will still work for those that are using X11. The RDP stuff might work for the X11 applications making it seamless or it might not, I'd assume it won't and you'll have two networking sessions.
You mentioned you liked VNC. VNC works. But excluding VNC something like LTSP won't work. Wayland demands a smart client it won't use a dumb client. And the reason for that is because you and everyone else who does X11 in 2014 are sitting at a smart client using it as if it were a dumb client. You aren't sitting at a dumb X-term, you are sitting at a computer with lots of CPU, RAM and HD. So Wayland takes advantage of that. your computer will have to do some of the rendering. This means your computer will need graphical objects that correspond to GUI you are running. So for example if you are running KDE5 (or 6 or whatever) remotely you will need a at least KDElibs on the local machine. Otherwise you can use something like VNC (which you said you liked).
It depends on the use case. For Tizen applications (smart watches, appliance terminals..) it already is in use. Moving up complexity it is being used in a high end mobile phone for the Kazakhstan market (i.e. better performance allowing saving money on hardware...) I'm thinking 2016 is when early adopter end users (on desktop) will be trying it out for daily use rather than something to screw around with. By 2020 absolutely the switch will happen, but not next week.
Remember you won't really have to. Wayland runs X11 now. I think this transition is going to be rather smooth. It is being planned well upstream getting everything coordinated. Mostly desktop is going late because with the exception of gaming their isn't much urgent need. It is when applications switch from being X11 on Wayland to directly on Wayland that new bugs get introduced and you'll notice. But then you will still be able to run the application either way (for a short period of time till they drop support for X11).
This isn't a will you. This is a right now. Today the Wayland client supports connecting to an X11 server and that's embedded by default. How long Wayland maintains an X is unclear but I'd assume well over an additional decade for compatibility. In fact what I would assume is going to happen very shortly is the hardware vendors are going to stop working with the X11 team on updates. So say by 2019 or so, Wayland is going to be the only way in any practical sense to get even halfway decent performance on X11.So your X11 applications will be find.
Now the rest of this is about a browser. I think you have the situation backwards. 10 years from now the browser is likely to be Wayland only with no X11 support. If you are running a browser that you want to run this remotely you would be using Wayland's RDP remote features. X11 wouldn't be anymore involved than Amiga Workbench
That's super easy. You like VNC, RealVNC already supports Wayland. A VNC is merged into the Wayland. That full desktop experience is getting better with the RDP.
That's what the RDP does.
I doubt that if you are on a WAN. Open up some graphics remotely and start rapidly shifting the location of your terminal and over the graphics forcing redraws. You'll see visible tearing
X11 already has that. Wayland has enhanced video so that gets better.