It sounds like you're just allergic to the excipient (aka the stuff used to bind a drug into a pill) and not the *cillin itself. So if you were to take, say, amoxicillin in liquid form I'm guessing you'd be fine--no puking. So if you've taken amoxicillin in the past and had serious nausea/vomiting as a result I'd investigate the following inactive ingredients:
Magnesium Stearate (E572) Silica Colloidal Anhydrous Capsule shell components: Body: Iron Oxide Red (E172) Iron Oxide Yellow (E172) Titanium Dioxide (El71) To 100% Gelatin Cap: Indigo Carmine (E132) Erythrosine (E127) Titanium Dioxide (E171) To 100% Gelatin Composition of Ink Shellac Dehydrated Alcohol Isopropyl Alcohol Butyl Alcohol Propylene Glycol Strong Ammonia Solution Potassium Hydroxide Black Iron Oxide (E172)
My money is on magnesium stearate (the white stuff pills are made out of)... It's made from various animal products and vegetable oil. I have no idea how pure it has to be for pill manufacture but I wouldn't be surprised if just a trace amount of something you're severely allergic to (in your gut anyway) could set off the vomit storm.
It could also be a combination of things that your gut just doesn't like to be together. For example, if you ate some rust (iron oxide) combined with shellac that might invoke a response related to a bad (gut) experience you had as a child when you ate a bug that crawled out of a rusty old metal thing.
Whoah there! Don't confuse "in the browser" with "in Internet Explorer."
2012 was the first year that Chrome was successfully exploited and Firefox has done fairly well every year. At the 2013 event the Chrome exploit only worked in Windows!
Oh that's unaccelerated, man! For whatever reason my laptop's Intel video doesn't get 2d accelerated canvas (probably a driver bug). On my wife'x iMac the CPU utilization hovers around 10% playing the same video.
Just wait until I get it working with a 3d WebGL context. Then it will be using hardly any CPU at all!
Gate One's X11 app already supports sharing of individual windows or whole desktops. I haven't implemented a GUI for it yet but that's just one of many TODO items I'm working through before the beta.
You'll love Gate One's X11 app then. With WebP encoding the bandwidth utilization playing back that Big Buck Bunny video hovers around ~700kbits/sec. With the default JPEG encoding it hovers around 1Mbits/sec (that's what you see in the Youtube video).
Even full-screen video playback never goes above 1.5Mbits/sec in my testing. That's with a 1366x768 display. Testing with JPEG encoding has it averaging out around 1.2Mbits/sec most of the time with peaks at 1.5MBits/sec here and there.
That's exactly how Gate One's X11 app works. Well, it can't buffer video in any significant way without adding non-trivial delays to interactivity but it does keep independent caches for each window on the screen and each gets their own encoding/quality strategy based on how often updates occur (bandwidth utilization isn't taken into account yet).
So that terminal running in the background will have nice and crisp, PNG-rendered text while the video playing in the forground will utilize JPEG (or WebP) encoding to reduce bandwidth (and CPU consumption on the server). If you look closely you can see this in the video.
Real-time encoding of desktop apps using h.264 is a bad idea. Text will look awful.
Gate One defaults to PNG encoding of screen/window/region captures and switches automatically to JPEG if updates start happening fast enough (because JPEG is much less CPU overhead than PNG). Its a threshold thing.
The quality can be adjusted on-the-fly as well. WebP support is there too but I'm torn as to whether to use it by default or not (if the browser supports it) because the CPU utilization is on par with PNG yet it is lossy (lossless works too but is too slow to encode to be realistic). The only benefit with WebP is reduced bandwidth... Admittedly it is a non-trivial amount (probably about half as much as JPEG at equivalent quality levels).
Once the beta is out I'll probably have more data to make a better decision about WebP.
How many submissions have you made? I didn't pay anything to get this posted. I just typed it up into the submission form earlier today and about an hour and a half later it appeared on the front page. I've done that 5 times now (not just for Gate One) with 6 attempts (I ended up having to re-submit something once =). So an accept/submit ratio of 5/6--not bad.
I personally think xpra is awesome. When searching for examples of XCB use in Python it came up in a number of results. My only issue with it is that it requires a client be installed.
Clients have to be deployed to every desktop and you have to re-deploy every time there's an update. I've been in IT long enough that I am absolutely sick of that. Web apps are the way to go. Deploy once to the web server(s) and you're done. No need to push out updates to clients.
Great: So now the computer manufacturers are going to point the finger to ME and say, "You're the reason why millenials aren't buying computers anymore!"
I really like the idea of using a fresnel lens over a smartphone to turn it into a larger desktop! I'm going to try that (I happen to have a big collection of fresnel lenses--don't ask =).
I'm going to do everything in my power to make sure your use case works because I want to be able to do that too! I also want to be able to pick up where I left off if I have to work on something while I'm out & about. Just whip out my Chromebook and I'm coding using the desktop (or just the app) I left behind.
So yeah, I just gave away an interesting feature: If you're using a Linux desktop (like I do) and you fire up Gate One it can connect to the existing X11 display and forward just the app you want it to. It doesn't have to be the entire desktop.
Reading your comment makes me think you'll love Gate One's ability to resume your session--even after restarting the process. I'll give you a hypothetical example:
1) I connect to https://gateone.mycompany.com/ and open up LibreOffice Calc. 2) I connect to the server running Gate One via SSH and run "/etc/init.d/gateone stop" 3) The web page reports it has been disconnected but it will retry connecting every five seconds. 4) I run "/etc/init.d/gateone start" 5) The web page reconnects to the Gate One server and my spreadsheet is back in front of me--right where i left it.
That works with terminals too if you install the dtach command. Everything will resume right where you left off even after killing and restarting the gateone.py process. This makes upgrading Gate One about as easy as can be; users will experience ~5 seconds of down time while the upgrade takes place and the process is restarted.
Because it's not a video player. It's a remote desktop/X11 tool. The video is merely an acid test demonstrating how fast/efficient it is. If it is fast enough to play back a video surely it's fast enough to use a spreadsheet or a text editor, right?
That won't work so well since this doesn't currently support audio. It's in the TODO list though:)
Also, if you're playing back a video you're much better off just playing it directly in the browser. You can even re-encode videos in real-time to be played back with whatever codecs Chromecast supports (if necessary).
I don't know about that. When I think to myself, "What has an imperial fucktonne of exploits?" here's what comes to mind:
* Windows (and Microsoft software in general) * Java (and especially the use of Java inside browsers) * Flash * PDFs * Loads of other proprietary software/solutions
Exploiting the browser these days is very difficult and browser vendors are doing a really good job with competitions/incentives to uncover vulnerabilities before they become a problem. Using the browser has the distinct advantage of *not* having the same problems of the proprietary products I enumerated above. You get whole new ones! But at least they're manageable and (mostly) predictable.
The more apps that are available in browsers the better. They're as cross-platform as you can get right now and if you host them yourself you can avoid the spying problem.
You're completely missing the point: Video playback over a remote desktop connection is merely an acid test. If it can play back a video that means the rate at which it can capture screenshots and send them to you is reasonably high. It's also an indication of how efficient it is.
Gate One's X11 feature isn't made for video it is merely efficient/fast enough to handle it. If I can open VLC and play back a video in my browser surely I can get reasonable responsiveness from something like a spreadsheet or IDE.
What is the CPU load while watching a video over RDP? I'm genuinely curious.
For reference, the gateone.py process(es) hover around 5% utilization when playing back a video @30fps (~720p resolution). Here's what it's doing while a video is playing back:
1) Capture the screenshot of the changed region on the X11 display. It can do this every 33ms (a capped equivalent to 30fps). It only needs to take screenshots when there's a change but in the case of a video it happens very fast, hence the 33ms cap. 2) Convert the raw captured image to selected format (JPEG for this example). It also makes a hash of the image that's used by both the server and client JS for caching purposes. 3) Transmit the image to the browser. If the image has recently been sent to the client it will be aware of this and will only send the hash. This transmission occurs in binary mode over the WebSocket (it's complicated).
From that point it's up to the client-side JavaScript to handle displaying the raw JPEG data. It is quite CPU-intensive if your hardware doesn't accelerate 2d canvas elements but not too bad (Chrome will hog around 50-80% of a single core while the video plays). Everything will remain responsive regardless.
For reference, I've done extensive benchmarking of the browser-side CPU utilization and Chrome's developer tools will report 81% idle even when the actual CPU consumption of the process is nearing 80%. That means that all the overhead is inside the code that renders canvas elements; which is good because it means my JavaScript is not a bottleneck.
That's what it is right now. Soon it will be so much more.
X11 is just the start. I also have File Transfer and other apps in the works. The File Transfer app will be interesting... It will be more than just an, "SFTP client." It will allow you to fetch a file from just about any URL (back-end is already written and supports ftp:// sftp://, ftps://, magnet://, and even dns://, dict:// and other obscure things which I think makes it all that more interesting/useful) and deliver it to any number of destinations you like. Even if the destination uses a different protocol.
So for example, if you wanted to download a magnet/bittorrent URL and have it automatically delivered to your home theater PC, your phone, and your brother's computer when complete you could do that.
I hear what you're saying and I agree that network latency is one of the biggest problems. Having said that, I have performed testing with my home Comcast Internet connection with Gate One running on a Rackspace cloud instance (512MB). The latency is negligible. My ping time to that server was a pretty steady ~50ms and apps like Chrome (yes, Chrome inside Chrome), LibreOffice (Calc/Writer), Sublime Text 2, kate, etc worked very well.
You're right: It doesn't need any proprietary software or proprietary protocols. It "just works" (in your browser).
I honestly have no idea if it's the fastest protocol. I do know that it's an order of magnitude less bandwidth than noVNC and similar web-based remote desktop products.
Yes but it depends on the game. I wouldn't play an FPS but an RTS would be fine. I dare say that playing Solitaire would be so good you wouldn't even notice it was a remote desktop:)
Well, up until recently that was pretty much what the Federal government did... It would bundle up the laws and regulations of various states and make them obsolete by passing a universally-agreed-to version of a given law. It used to work fine because lawmakers considered it their jobs to, you know, write laws and resolve differences between the states.
These days lawmakers full-time job is to raise money. The whole "let's work on the laws thing" is just something they do on the side.
Another problem is partisan politics: You'd think that changing a law in regards to the possession of feathers would be a non-partisan thing but this is impossible today. If a bill is introduced by a Democrat--and Republicans were not intimately involved in its writing--it will be immediately opposed by Republicans. This problem works in both directions (Republican introducing a bill will be opposed by Democrats).
This leads to "negotiations" where none are necessary. Also, in order to actually fix laws like this politicians have to essentially bribe "the opposing isle" in order to allow it to be voted on. Absolutely nothing is presented before going through a rigorous process of political bargaining.
A bill could have absolutely no ideological opposition and be non-controversial in any way but will still be blocked unless those putting it forward are willing to trade something for the privilege.
Slashdot Mirror
Oh I'm sure the AIs will be *much* easier to blame
It sounds like you're just allergic to the excipient (aka the stuff used to bind a drug into a pill) and not the *cillin itself. So if you were to take, say, amoxicillin in liquid form I'm guessing you'd be fine--no puking. So if you've taken amoxicillin in the past and had serious nausea/vomiting as a result I'd investigate the following inactive ingredients:
From: https://www.medicines.org.uk/e...
Magnesium Stearate (E572)
Silica Colloidal Anhydrous
Capsule shell components:
Body:
Iron Oxide Red (E172)
Iron Oxide Yellow (E172)
Titanium Dioxide (El71)
To 100% Gelatin
Cap:
Indigo Carmine (E132)
Erythrosine (E127)
Titanium Dioxide (E171)
To 100% Gelatin
Composition of Ink
Shellac
Dehydrated Alcohol
Isopropyl Alcohol
Butyl Alcohol
Propylene Glycol
Strong Ammonia Solution
Potassium Hydroxide
Black Iron Oxide (E172)
My money is on magnesium stearate (the white stuff pills are made out of)... It's made from various animal products and vegetable oil. I have no idea how pure it has to be for pill manufacture but I wouldn't be surprised if just a trace amount of something you're severely allergic to (in your gut anyway) could set off the vomit storm.
It could also be a combination of things that your gut just doesn't like to be together. For example, if you ate some rust (iron oxide) combined with shellac that might invoke a response related to a bad (gut) experience you had as a child when you ate a bug that crawled out of a rusty old metal thing.
Whoah there! Don't confuse "in the browser" with "in Internet Explorer."
2012 was the first year that Chrome was successfully exploited and Firefox has done fairly well every year. At the 2013 event the Chrome exploit only worked in Windows!
Oh that's unaccelerated, man! For whatever reason my laptop's Intel video doesn't get 2d accelerated canvas (probably a driver bug). On my wife'x iMac the CPU utilization hovers around 10% playing the same video.
Just wait until I get it working with a 3d WebGL context. Then it will be using hardly any CPU at all!
Gate One's X11 app already supports sharing of individual windows or whole desktops. I haven't implemented a GUI for it yet but that's just one of many TODO items I'm working through before the beta.
Actually the demo uses smplayer.
But whatever, details. Who cares, right? ;D
You'll love Gate One's X11 app then. With WebP encoding the bandwidth utilization playing back that Big Buck Bunny video hovers around ~700kbits/sec. With the default JPEG encoding it hovers around 1Mbits/sec (that's what you see in the Youtube video).
Even full-screen video playback never goes above 1.5Mbits/sec in my testing. That's with a 1366x768 display. Testing with JPEG encoding has it averaging out around 1.2Mbits/sec most of the time with peaks at 1.5MBits/sec here and there.
That's exactly how Gate One's X11 app works. Well, it can't buffer video in any significant way without adding non-trivial delays to interactivity but it does keep independent caches for each window on the screen and each gets their own encoding/quality strategy based on how often updates occur (bandwidth utilization isn't taken into account yet).
So that terminal running in the background will have nice and crisp, PNG-rendered text while the video playing in the forground will utilize JPEG (or WebP) encoding to reduce bandwidth (and CPU consumption on the server). If you look closely you can see this in the video.
Real-time encoding of desktop apps using h.264 is a bad idea. Text will look awful.
Gate One defaults to PNG encoding of screen/window/region captures and switches automatically to JPEG if updates start happening fast enough (because JPEG is much less CPU overhead than PNG). Its a threshold thing.
The quality can be adjusted on-the-fly as well. WebP support is there too but I'm torn as to whether to use it by default or not (if the browser supports it) because the CPU utilization is on par with PNG yet it is lossy (lossless works too but is too slow to encode to be realistic). The only benefit with WebP is reduced bandwidth... Admittedly it is a non-trivial amount (probably about half as much as JPEG at equivalent quality levels).
Once the beta is out I'll probably have more data to make a better decision about WebP.
How many submissions have you made? I didn't pay anything to get this posted. I just typed it up into the submission form earlier today and about an hour and a half later it appeared on the front page. I've done that 5 times now (not just for Gate One) with 6 attempts (I ended up having to re-submit something once =). So an accept/submit ratio of 5/6--not bad.
I personally think xpra is awesome. When searching for examples of XCB use in Python it came up in a number of results. My only issue with it is that it requires a client be installed.
Clients have to be deployed to every desktop and you have to re-deploy every time there's an update. I've been in IT long enough that I am absolutely sick of that. Web apps are the way to go. Deploy once to the web server(s) and you're done. No need to push out updates to clients.
You know, if Wayland has Python bindings and an API akin to XCB (or Xlib) I can make it work with that too. Wouldn't even take much effort!
Great: So now the computer manufacturers are going to point the finger to ME and say, "You're the reason why millenials aren't buying computers anymore!"
I really like the idea of using a fresnel lens over a smartphone to turn it into a larger desktop! I'm going to try that (I happen to have a big collection of fresnel lenses--don't ask =).
I'm going to do everything in my power to make sure your use case works because I want to be able to do that too! I also want to be able to pick up where I left off if I have to work on something while I'm out & about. Just whip out my Chromebook and I'm coding using the desktop (or just the app) I left behind.
So yeah, I just gave away an interesting feature: If you're using a Linux desktop (like I do) and you fire up Gate One it can connect to the existing X11 display and forward just the app you want it to. It doesn't have to be the entire desktop.
Reading your comment makes me think you'll love Gate One's ability to resume your session--even after restarting the process. I'll give you a hypothetical example:
1) I connect to https://gateone.mycompany.com/ and open up LibreOffice Calc.
2) I connect to the server running Gate One via SSH and run "/etc/init.d/gateone stop"
3) The web page reports it has been disconnected but it will retry connecting every five seconds.
4) I run "/etc/init.d/gateone start"
5) The web page reconnects to the Gate One server and my spreadsheet is back in front of me--right where i left it.
That works with terminals too if you install the dtach command. Everything will resume right where you left off even after killing and restarting the gateone.py process. This makes upgrading Gate One about as easy as can be; users will experience ~5 seconds of down time while the upgrade takes place and the process is restarted.
Because it's not a video player. It's a remote desktop/X11 tool. The video is merely an acid test demonstrating how fast/efficient it is. If it is fast enough to play back a video surely it's fast enough to use a spreadsheet or a text editor, right?
That won't work so well since this doesn't currently support audio. It's in the TODO list though :)
Also, if you're playing back a video you're much better off just playing it directly in the browser. You can even re-encode videos in real-time to be played back with whatever codecs Chromecast supports (if necessary).
I don't know about that. When I think to myself, "What has an imperial fucktonne of exploits?" here's what comes to mind:
* Windows (and Microsoft software in general)
* Java (and especially the use of Java inside browsers)
* Flash
* PDFs
* Loads of other proprietary software/solutions
Exploiting the browser these days is very difficult and browser vendors are doing a really good job with competitions/incentives to uncover vulnerabilities before they become a problem. Using the browser has the distinct advantage of *not* having the same problems of the proprietary products I enumerated above. You get whole new ones! But at least they're manageable and (mostly) predictable.
The more apps that are available in browsers the better. They're as cross-platform as you can get right now and if you host them yourself you can avoid the spying problem.
You're completely missing the point: Video playback over a remote desktop connection is merely an acid test. If it can play back a video that means the rate at which it can capture screenshots and send them to you is reasonably high. It's also an indication of how efficient it is.
Gate One's X11 feature isn't made for video it is merely efficient/fast enough to handle it. If I can open VLC and play back a video in my browser surely I can get reasonable responsiveness from something like a spreadsheet or IDE.
What is the CPU load while watching a video over RDP? I'm genuinely curious.
For reference, the gateone.py process(es) hover around 5% utilization when playing back a video @30fps (~720p resolution). Here's what it's doing while a video is playing back:
1) Capture the screenshot of the changed region on the X11 display. It can do this every 33ms (a capped equivalent to 30fps). It only needs to take screenshots when there's a change but in the case of a video it happens very fast, hence the 33ms cap.
2) Convert the raw captured image to selected format (JPEG for this example). It also makes a hash of the image that's used by both the server and client JS for caching purposes.
3) Transmit the image to the browser. If the image has recently been sent to the client it will be aware of this and will only send the hash. This transmission occurs in binary mode over the WebSocket (it's complicated).
From that point it's up to the client-side JavaScript to handle displaying the raw JPEG data. It is quite CPU-intensive if your hardware doesn't accelerate 2d canvas elements but not too bad (Chrome will hog around 50-80% of a single core while the video plays). Everything will remain responsive regardless.
For reference, I've done extensive benchmarking of the browser-side CPU utilization and Chrome's developer tools will report 81% idle even when the actual CPU consumption of the process is nearing 80%. That means that all the overhead is inside the code that renders canvas elements; which is good because it means my JavaScript is not a bottleneck.
That's what it is right now. Soon it will be so much more.
X11 is just the start. I also have File Transfer and other apps in the works. The File Transfer app will be interesting... It will be more than just an, "SFTP client." It will allow you to fetch a file from just about any URL (back-end is already written and supports ftp:// sftp://, ftps://, magnet://, and even dns://, dict:// and other obscure things which I think makes it all that more interesting/useful) and deliver it to any number of destinations you like. Even if the destination uses a different protocol.
So for example, if you wanted to download a magnet/bittorrent URL and have it automatically delivered to your home theater PC, your phone, and your brother's computer when complete you could do that.
I hear what you're saying and I agree that network latency is one of the biggest problems. Having said that, I have performed testing with my home Comcast Internet connection with Gate One running on a Rackspace cloud instance (512MB). The latency is negligible. My ping time to that server was a pretty steady ~50ms and apps like Chrome (yes, Chrome inside Chrome), LibreOffice (Calc/Writer), Sublime Text 2, kate, etc worked very well.
You're right: It doesn't need any proprietary software or proprietary protocols. It "just works" (in your browser).
I honestly have no idea if it's the fastest protocol. I do know that it's an order of magnitude less bandwidth than noVNC and similar web-based remote desktop products.
Yes, that will work. By default I have the xorg.conf listening only on localhost but you could easily change it. X11 forwarding over SSH also works.
Yes but it depends on the game. I wouldn't play an FPS but an RTS would be fine. I dare say that playing Solitaire would be so good you wouldn't even notice it was a remote desktop :)
Well, up until recently that was pretty much what the Federal government did... It would bundle up the laws and regulations of various states and make them obsolete by passing a universally-agreed-to version of a given law. It used to work fine because lawmakers considered it their jobs to, you know, write laws and resolve differences between the states.
These days lawmakers full-time job is to raise money. The whole "let's work on the laws thing" is just something they do on the side.
Another problem is partisan politics: You'd think that changing a law in regards to the possession of feathers would be a non-partisan thing but this is impossible today. If a bill is introduced by a Democrat--and Republicans were not intimately involved in its writing--it will be immediately opposed by Republicans. This problem works in both directions (Republican introducing a bill will be opposed by Democrats).
This leads to "negotiations" where none are necessary. Also, in order to actually fix laws like this politicians have to essentially bribe "the opposing isle" in order to allow it to be voted on. Absolutely nothing is presented before going through a rigorous process of political bargaining.
A bill could have absolutely no ideological opposition and be non-controversial in any way but will still be blocked unless those putting it forward are willing to trade something for the privilege.