An easy boot BSD sounds like a good idea. I think over the next 15 year or so BSD is eventually going to have to create their own systemd emulator (which is going to be a high privilege process capable of manipulating daemons i.e. effectively a new init) or just add those Linux kernel features to their kernel and use actual systemd. Systemd of course also introduces a license problem in addition to technical problems, an emulator is going to get ever more difficult as systemd incorporates PaaS features.
This is the problem with legacy software. There is a window of time where crossover is supported and once that window starts to close crossing over quickly gets more and more complex. We are just slightly after the crossover point.
if I want PaaS functionality, I've got Docker and/or Elastic Beanstalk for the simpler applications
And those Docker containers have to be running inside an infastructure.
But a data warehouse isn't going there.
Why not? Data warehouse seems perfect of a PaaS. I've got ETLs running constantly and I'd like to break them clean of my computational nodes. I have queries that are hitting or not hitting various tables so I want to associate and disassociate CPU from.... Seems like an excellent application of PaaS. And BTW both Oracle, IBM and EnterpriseDB (Postgres) agree with me on this.
Log analysis isn't happening there, as much as I'd ike to outsource that, but the expense is ridiculous,
Log analysis has always been one of the core applications of big data systems. Of course that's happening there. They are way way ahead of traditional infrastructure.
Those options (sans Heroku) are great if you're trying to get a proof-of-concept off the ground, or you've got high enough margins going that you can eat the pain when the cost of outsourcing so much of your infrastructure catches up with you. Thise "good problems to have" aren't so good to have as people think.
Large in-house systems should also be running PaaS. I don't agree with you on the outsourcing infrastructure question but even if you were right that's irrelevant to whether you in-sourced infrastructure should be a PaaS.
If this is a big deal you can have systemd write an additional plaintext log. Binary only is an option.
Of course it is an issue. All sorts of things in life have some negatives and some positives, you weigh them accept the negatives of your choice and move on. In this case you get better seeking and indexing.
I suspect if it were easy the OpenRC guys would have done it since this is by their own admission the main thing that people wanted systemd for. Upstart does do this and it also ends up being designed a lot like systemd, except that Upstart uses plaintext configs.
X can't do direct rendering. An application buffer is distinct from a graphical buffer.
(b) is still very common and I use X over such a network every day. In fact (b) is much more common now than when X11 was designed because we have much better networks now and a good wireless network falls into this category.
It is not more common. How many people share applications across a wireless? Servers are generally over a WAN not a LAN. Even when it is a WAN there are few reasons to not just have the client render (i.e. client-server)...
But even there Wayland does not offer any advantage with its RDP: You can use RDP with X as well.
X graphical libraries aren't designed for RDP and remote rendering. The whole approach RDP violates network transparency.
Will users of other init systems be treated as second-class citizens.
Yes. Once applications can freely have long chains of cross-service dependencies which they are assured will be kept functional by the init system they will be written to require this. Debian can't do anything about that. It is already happening at the IaaS and PaaS level. The alternative is going to be you run Debian but all your applications run inside some micro-PaaS that has these functions anyway.
If you just want a sysinitv2 for things like cross-service dependencies/events OpenRC is that. It has started. It works. But OpenRC can't keep daemons alive. That's the big trade off.
There are 3 situations involving applications, networking and graphics a) Running an application on a machine sharing ram with the video card. b) Running applications on a machine close enough to the video card that the latency between them is lowish and the bandwidth is plentiful and performance is irrelevant. c) Running applications on a machine where either the latency is high or the bandwidth is limited X11 does terrific for (b) in exchange for damaging (a) and (c). X11 was designed in a world where (b) is common. In today's world (b) is uncommon.
Other issues:
1. The mixing of signed and unsigned coordinates causes problems both in the protocol, where 3/4 of the coordinate space is often unrepresentable, and in the C language bindings. 2. The X protocol is asynchronous for efficiency: in general, neither the server nor clients wait for replies. But the protocol’s synchronization mechanisms are insufficient, and leave many unavoidable race conditions. 3. The X protocol attempts to be policy-free and tries not to dictate any particular style of window management. However, some desirable window manager features cannot be implemented correctly, because there are window attributes which the window manager can neither fetch nor monitor. 4. The X protocol provides visibility notification events so that clients can avoid computation of obscured window contents. However, this notification doesn’t work well for nested windows or for windows with backing store. 5. None of the several ways that an application can implement interactive mouse tracking of crosshairs, bounding boxes, etc., allow both efficiency and correctness. 6. Popping up menus and dialog boxes is slow because it requires too many round trips and generates too many events. Repainting when portions of a window become visible is often slow. 7. Exceptional conditions are poorly handled. Faulty programs can freeze the server, and clients cannot kill queued requests if the user doesn’t want to wait for the server to finish servicing them.
Wine doesn't add anything here. These servers have license for the Microsoft binaries. They don't need to translate Windows API calls into POSIX calls you can just execute against the Windows API.
If the host OS is compromised all the containers are compromised. But remember this was a Linux solution so the host OS is Linux. So the problem is the same with or without Docker.
I'm not a security expert, I'm parroting so with that disclaimer YMMV.
There are many parts of the Linux kernel that don't understand the UID/GID on containers. So essentially you pass a UID to LXC and run some kernel code you shouldn't have have access to. This is being cleaned up but there are still hundreds of holes. Some of these holes are well known and document though not yet fixed. The way it is being fixed is by trying to limit some of the system calls but that of course breaks compatibility.
LXC doesn't protect against buffer overflows and lots of stuff in the root of the system is readable (see for example vmsplice exploit). It is easy for a container to write to ram and then get the main kernel to execute instructions. Containers can be set to only run code that was loaded (i.e. execution space is read only) but that breaks many applications.
Physical devices are another problem. If a container can access a physical device then it can pass code back to the kernel. Device are not virtualized. (BTW this won't be a problem for your use case of Windows since all device drivers are virtualized unlike Linux).
The second issue is the containers while chrooted can have access to the filesystem the way any chroot program can. There are lots of exploits if one can write to arbitrary files to get privilege escalation.
If I can make a suggestion: http://www.activestate.com/sta... is a terrific way for you to start playing with containers. It is a mini PaaS that runs in a VM based on Docker containers and it is free for small usages.
Remember Docker isn't secure. Process that want to escape can escape. So you still want Docker containers running in a VM not against bare metal. There is no reason that couldn't be the case say 2020 when people are tightly tied to Azure. Docker is usually deployed in PaaS environments so it would your server user space.
What you might want is a Windows VM (or more than one) inside your Windows that you use for Internet downloads.
Docker has lower cost per service and worse security. So the same hardware can run many many more times as many docker containers as VMs. This encourages designs that cut services into more parts. So while a typical large applications might run on 1 or 2 VMs a typical large Docker application might make use of a dozen or more containers. Docker thus plays the same role of a Linux distribution in that it designs hundreds or thousands of pieces of software to work together, but in a way that allows for specialization so small companies can work on their containers in isolation.
If you are a developer I'd try it. It is pretty cool running essentially the same setup I'd be running in a large server cluster production environment on a small VM on my laptop. It is also excellent for productivity that you have your own mini copy of "prod".
Forgot to mention registry. What I suspect is a mini registry is universally shared with file locations and settings another program that allows small writes to individual entries. So a registry lookup hits two databases not just one.
Many of Apple's users depended upon that software. Me in particular. I have thousands of dollars invested in PPC software. I can't use it past 10.6. Apple is rich as Croesus. When they decided it was ok to abandon the PPC hardware because they had a path for PPC software, they should have made sure they had what they needed into the future. At this point, they should probably just buy IBM to get it back. But, no, it's "fuck you, users." Assholes.
Your claim was arbitrary. This wasn't arbitrary. Faced with a high cost of supporting PPC indefinitely they said no. The guy below commented on your laptop. Apple expects regular upgrades. They patch OS bugs often through OS replacement, they aren't failing to bugfix you are failing to upgrade.
Now I get you have reasons. But you should accurately characterize Apple's actions. Your reasons for not wanting to do what they want doesn't mean they aren't doing things. Frankly it doesn't sound like you should be on Apple at all. Linux still exists for PPC and IBM Power systems are pretty nice boxes if you want to stay with PPC.
I suspect it is classic cross platform porting. Platform X provides Y service. Platform A provides services B and C which are like Y so make the changes to the code to support the B/C combination. Windows clearly has a layered kernel and VM technologies. Azure has many of the services of OpenStack. It probably is a complex project but two digit number of man years, nothing outside the realm of what Microsoft can afford.
Docker isn't niche. It is one of the core technologies for DevOps which is designing application infrastructures where IT provides a platform for in-house and integrate micro-services rather than providing monolithic applications to departments. Many PaaS systems are based on Docker particularly Helion (HP), CenturyLink, Rackspace its a big player for AWS...
Docker containers are like VM's but smaller. I think what it means is that a Windows server / VM will be able to run dozens-hundreds of Windows micro-services inside a Docker for Windows infrastructure. Or basically once finished you as a developer can now write Windows apps that don't need to install and will run on any Windows, no more version dependencies! Just like Docker is doing for Linux today.
Take another look at the SCO bankruptcy. Caldera bough SCO Unix and continued to sell it for several years. The customers were able to buy licenses and receive some levels of support. Additionally Caldera products were supported and transitioned off to vendors like RedHat that had shifted towards an enterprise focus. At the time SCO finally shut down all together they were nothing but a patent troll and there was nothing technical to preserve. It would be like preserving a corpse that died from disease because it used to be healthy.
Slashdot Mirror
An easy boot BSD sounds like a good idea. I think over the next 15 year or so BSD is eventually going to have to create their own systemd emulator (which is going to be a high privilege process capable of manipulating daemons i.e. effectively a new init) or just add those Linux kernel features to their kernel and use actual systemd. Systemd of course also introduces a license problem in addition to technical problems, an emulator is going to get ever more difficult as systemd incorporates PaaS features.
This is the problem with legacy software. There is a window of time where crossover is supported and once that window starts to close crossing over quickly gets more and more complex. We are just slightly after the crossover point.
And those Docker containers have to be running inside an infastructure.
Why not? Data warehouse seems perfect of a PaaS. I've got ETLs running constantly and I'd like to break them clean of my computational nodes. I have queries that are hitting or not hitting various tables so I want to associate and disassociate CPU from.... Seems like an excellent application of PaaS. And BTW both Oracle, IBM and EnterpriseDB (Postgres) agree with me on this.
Log analysis has always been one of the core applications of big data systems. Of course that's happening there. They are way way ahead of traditional infrastructure.
Large in-house systems should also be running PaaS. I don't agree with you on the outsourcing infrastructure question but even if you were right that's irrelevant to whether you in-sourced infrastructure should be a PaaS.
If this is a big deal you can have systemd write an additional plaintext log. Binary only is an option.
Of course it is an issue. All sorts of things in life have some negatives and some positives, you weigh them accept the negatives of your choice and move on. In this case you get better seeking and indexing.
They want you moving towards a PaaS type infrastructure. https://www.openshift.com/ https://www.heroku.com/ http://www.activestate.com/sta... ... So yes an entirely new stack but one that is already well tested and in use. The entire concept of how you do internal tooling should be changing.
I suspect if it were easy the OpenRC guys would have done it since this is by their own admission the main thing that people wanted systemd for. Upstart does do this and it also ends up being designed a lot like systemd, except that Upstart uses plaintext configs.
X can't do direct rendering. An application buffer is distinct from a graphical buffer.
It is not more common. How many people share applications across a wireless? Servers are generally over a WAN not a LAN. Even when it is a WAN there are few reasons to not just have the client render (i.e. client-server)...
X graphical libraries aren't designed for RDP and remote rendering. The whole approach RDP violates network transparency.
As for 1990s the problems with X are still there.
Hawaii desktop on Arch which runs Wayland: https://www.youtube.com/watch?...
Yes. Once applications can freely have long chains of cross-service dependencies which they are assured will be kept functional by the init system they will be written to require this. Debian can't do anything about that. It is already happening at the IaaS and PaaS level. The alternative is going to be you run Debian but all your applications run inside some micro-PaaS that has these functions anyway.
If you just want a sysinitv2 for things like cross-service dependencies/events OpenRC is that. It has started. It works. But OpenRC can't keep daemons alive. That's the big trade off.
Wayland includes a remote protocol. For an application programmer you'll use a graphical widget set and that will display remotely fine.
There are 3 situations involving applications, networking and graphics
a) Running an application on a machine sharing ram with the video card.
b) Running applications on a machine close enough to the video card that the latency between them is lowish and the bandwidth is plentiful and performance is irrelevant.
c) Running applications on a machine where either the latency is high or the bandwidth is limited
X11 does terrific for (b) in exchange for damaging (a) and (c). X11 was designed in a world where (b) is common. In today's world (b) is uncommon.
Other issues:
1. The mixing of signed and unsigned coordinates causes problems both in the protocol, where 3/4 of the coordinate space is often unrepresentable, and in the C language bindings.
2. The X protocol is asynchronous for efficiency: in general, neither the server nor clients wait for replies. But the protocol’s synchronization mechanisms are insufficient, and leave many unavoidable race conditions.
3. The X protocol attempts to be policy-free and tries not to dictate any particular style of window management. However, some desirable window manager features cannot be implemented correctly, because there are window attributes which the window manager can neither fetch nor monitor.
4. The X protocol provides visibility notification events so that clients can avoid computation of obscured window contents. However, this notification doesn’t work well for nested windows or for windows with backing store.
5. None of the several ways that an application can implement interactive mouse tracking of crosshairs, bounding boxes, etc., allow both efficiency and correctness.
6. Popping up menus and dialog boxes is slow because it requires too many round trips and generates too many events. Repainting when portions of a window become visible is often slow.
7. Exceptional conditions are poorly handled. Faulty programs can freeze the server, and clients cannot kill queued requests if the user doesn’t want to wait for the server to finish servicing them.
Wine doesn't add anything here. These servers have license for the Microsoft binaries. They don't need to translate Windows API calls into POSIX calls you can just execute against the Windows API.
If the host OS is compromised all the containers are compromised. But remember this was a Linux solution so the host OS is Linux. So the problem is the same with or without Docker.
So App-V is a lot like Docker. It wouldn't shock me if Docker / Windows ends up being a mixture of the two code bases. Very good point.
I'm not a security expert, I'm parroting so with that disclaimer YMMV.
There are many parts of the Linux kernel that don't understand the UID/GID on containers. So essentially you pass a UID to LXC and run some kernel code you shouldn't have have access to. This is being cleaned up but there are still hundreds of holes. Some of these holes are well known and document though not yet fixed. The way it is being fixed is by trying to limit some of the system calls but that of course breaks compatibility.
LXC doesn't protect against buffer overflows and lots of stuff in the root of the system is readable (see for example vmsplice exploit). It is easy for a container to write to ram and then get the main kernel to execute instructions. Containers can be set to only run code that was loaded (i.e. execution space is read only) but that breaks many applications.
Physical devices are another problem. If a container can access a physical device then it can pass code back to the kernel. Device are not virtualized. (BTW this won't be a problem for your use case of Windows since all device drivers are virtualized unlike Linux).
The second issue is the containers while chrooted can have access to the filesystem the way any chroot program can. There are lots of exploits if one can write to arbitrary files to get privilege escalation.
You sound like you are interested.
If I can make a suggestion: http://www.activestate.com/sta... is a terrific way for you to start playing with containers. It is a mini PaaS that runs in a VM based on Docker containers and it is free for small usages.
Remember Docker isn't secure. Process that want to escape can escape. So you still want Docker containers running in a VM not against bare metal. There is no reason that couldn't be the case say 2020 when people are tightly tied to Azure. Docker is usually deployed in PaaS environments so it would your server user space.
What you might want is a Windows VM (or more than one) inside your Windows that you use for Internet downloads.
Docker has lower cost per service and worse security. So the same hardware can run many many more times as many docker containers as VMs. This encourages designs that cut services into more parts. So while a typical large applications might run on 1 or 2 VMs a typical large Docker application might make use of a dozen or more containers. Docker thus plays the same role of a Linux distribution in that it designs hundreds or thousands of pieces of software to work together, but in a way that allows for specialization so small companies can work on their containers in isolation.
If you are a developer I'd try it. It is pretty cool running essentially the same setup I'd be running in a large server cluster production environment on a small VM on my laptop. It is also excellent for productivity that you have your own mini copy of "prod".
Forgot to mention registry. What I suspect is a mini registry is universally shared with file locations and settings another program that allows small writes to individual entries. So a registry lookup hits two databases not just one.
Your claim was arbitrary. This wasn't arbitrary. Faced with a high cost of supporting PPC indefinitely they said no. The guy below commented on your laptop. Apple expects regular upgrades. They patch OS bugs often through OS replacement, they aren't failing to bugfix you are failing to upgrade.
Now I get you have reasons. But you should accurately characterize Apple's actions. Your reasons for not wanting to do what they want doesn't mean they aren't doing things. Frankly it doesn't sound like you should be on Apple at all. Linux still exists for PPC and IBM Power systems are pretty nice boxes if you want to stay with PPC.
I suspect it is classic cross platform porting. Platform X provides Y service. Platform A provides services B and C which are like Y so make the changes to the code to support the B/C combination. Windows clearly has a layered kernel and VM technologies. Azure has many of the services of OpenStack. It probably is a complex project but two digit number of man years, nothing outside the realm of what Microsoft can afford.
Maybe. But PaaS certainly isn't.
Docker isn't niche. It is one of the core technologies for DevOps which is designing application infrastructures where IT provides a platform for in-house and integrate micro-services rather than providing monolithic applications to departments. Many PaaS systems are based on Docker particularly Helion (HP), CenturyLink, Rackspace its a big player for AWS...
Docker containers are like VM's but smaller. I think what it means is that a Windows server / VM will be able to run dozens-hundreds of Windows micro-services inside a Docker for Windows infrastructure. Or basically once finished you as a developer can now write Windows apps that don't need to install and will run on any Windows, no more version dependencies! Just like Docker is doing for Linux today.
Take another look at the SCO bankruptcy. Caldera bough SCO Unix and continued to sell it for several years. The customers were able to buy licenses and receive some levels of support. Additionally Caldera products were supported and transitioned off to vendors like RedHat that had shifted towards an enterprise focus. At the time SCO finally shut down all together they were nothing but a patent troll and there was nothing technical to preserve. It would be like preserving a corpse that died from disease because it used to be healthy.